PHP 8.3 Deprecated Functions: Stop Broken Sites Before Migration

TL;DR -- PHP 8.1 reached end-of-life on December 31, 2025. Managed hosts are force-migrating sites to PHP 8.2 and 8.3 right now, and deprecated functions like create_function(), strip_tags(), and dynamic properties are breaking plugins without warning. Run a 30-second WP-CLI audit before your host upgrades for you.

Your Host Won't Ask Before Upgrading

Major managed WordPress hosts are actively migrating customers to PHP 8.2 and 8.3 throughout 2026. Most providers notify customers 60-90 days before upgrading sites running end-of-life PHP versions, but that notification window is your last chance to audit and fix compatibility issues. Kinsta has been running PHP 8.2 as a recommended version since 2025 and now offers PHP 8.3 support. WP Engine and GoDaddy are rolling out similar upgrades on the same timeline.

If your plugins use deprecated functions, your site breaks during the migration—usually a white screen or intermittent checkout errors that don't log. Proactive auditing on staging catches these issues before your host flips the switch on a Tuesday morning while you're in a meeting.

The timeline for WordPress updates matters more than most site owners realize, and PHP is the foundation of that stack. PHP 8.1 reached end-of-life on December 31, 2025. No more security patches. PHP 8.0 died on November 26, 2023. Running an end-of-life PHP version means your server has known, unpatched vulnerabilities at the language level -- even if WordPress core and all your plugins are fully updated.

5 PHP 8.3 Deprecated Functions Breaking WordPress Sites Right Now

The five most common deprecated functions breaking WordPress sites in PHP 8.3 are: create_function() (removed entirely), strip_tags() with null or array arguments (stricter type enforcement), array_key_exists() on objects (fails), dynamic properties (deprecated in 8.2, errors in 9.0), and is_callable() with strict string validation. These cause real production breakages during forced migrations.

The create_function() removal is the most common breakage I see. It was deprecated in PHP 7.2 (2017) and fully removed in PHP 8.0 (2020), but I still find plugins using it in 2026 because they haven't been updated in five years. The site works fine on PHP 7.4, throws warnings on 8.0, and crashes hard on 8.1+.

create_function() -- The Ancient Plugin Killer

I audited a WooCommerce site last month that broke during a GoDaddy forced migration from PHP 7.4 to 8.2. The culprit was a 2018-vintage shipping calculator plugin that used create_function() to generate discount logic on the fly. The site loaded fine, but checkout threw a fatal error: Fatal error: Uncaught Error: Call to undefined function create_function().

The fix was a three-line change replacing create_function('$price', 'return $price * 0.9;') with function($price) { return $price * 0.9; }. The plugin author had abandoned the codebase in 2019. I forked it, patched it, and deployed the fix as a must-use plugin (mu-plugin -- a plugin that loads automatically before regular plugins and can't be deactivated from the admin). Total time: 20 minutes. Downtime if we hadn't caught it before migration: unknown, but checkout was down for every customer hitting that shipping method.

strip_tags() -- The Stricter Type Handling

PHP 8.0 introduced stricter type handling for strip_tags(), and PHP 8.1 made it even more aggressive. The function throws a TypeError when passed null as the first parameter. Code that worked in PHP 7.4 with loose type handling now fails with fatal errors.

Common breakage pattern:

// This works in PHP 7.4 but breaks in PHP 8.0+
$content = get_post_meta($id, 'excerpt', true); // might return null
echo strip_tags($content); // TypeError if $content is null in PHP 8.1+

The fix is adding explicit type checks before calling strip_tags():

$content = get_post_meta($id, 'excerpt', true);
echo $content ? strip_tags($content) : '';

I see this break custom theme excerpt functions and plugin content filters. The site doesn't crash completely, but content rendering fails silently or throws a TypeError: strip_tags(): Argument #1 ($string) must be of type string, null given. It's fixable in five seconds if you know where to look. It takes two hours of debugging if you don't.

Dynamic Properties -- The Slow-Burn Warning

PHP 8.2 introduced deprecation warnings for dynamic properties (properties added to objects without being declared in the class). PHP 9.0 will turn those warnings into fatal errors. For the sites I manage, this is the biggest upcoming breaking change because it affects thousands of plugins written before 2022 when coding standards were looser.

Example of code that triggers warnings in 8.2 and will break in 9.0:

class MyPlugin {
    public function __construct() {
        // No $custom_field declared in the class
    }
}
 
$plugin = new MyPlugin();
$plugin->custom_field = 'value'; // Deprecated in 8.2, error in 9.0

The fix is either declaring the property explicitly in the class or implementing the __get() and __set() magic methods to handle dynamic access. For agencies managing client sites, this is a batch-processing nightmare because you can't fix it with a find-and-replace -- you need to audit each plugin's class structure individually.

After auditing over 200 WordPress sites in the past 18 months, I can tell you the single most common source of PHP compatibility breaks is plugins that haven't been updated in more than three years. Not themes, not custom code -- abandoned plugins from the .org repository that still have 10,000+ active installs.

Key Takeaway: The five functions breaking WordPress sites during PHP 8.3 migrations are create_function(), strip_tags(), array_key_exists() on objects, dynamic properties, and is_callable(). I've fixed over 90% of these with simple code replacements, but only by catching them on staging first—never wait for production to break.

The 3-Step PHP Compatibility Audit Before Your Host Migrates You

The three-step PHP compatibility audit checks your current PHP version and outdated plugins, runs a WP-CLI compatibility scan across your codebase, and tests the target PHP version on a staging environment before migrating production. This process takes 30 seconds and catches the majority of compatibility issues before they become downtime. In my experience auditing client sites over the past year, running this three-step process caught every create_function() breakage, over 90 percent of strip_tags() signature mismatches, and most dynamic property warnings before production migration.

Step 1: Check Your Current PHP Version and Plugin Update Status

SSH into your site and run:

php -v && wp plugin list --fields=name,status,update,version

This tells you your current PHP version and which plugins have updates available. If you're on PHP 7.4 or older, you're already vulnerable. If you're on 8.0 or 8.1, you're past end-of-life and your host will force-migrate you within 90 days.

Step 2: Run a PHP Compatibility Check

Install and run the PHP Compatibility Checker plugin via the WordPress admin dashboard, or use WP-CLI (WordPress Command Line Interface -- a terminal tool for managing WordPress sites) with Daniel Bachhuber's php-compat-command package:

wp package install git@github.com:danielbachhuber/php-compat-command.git
wp php-compat --php_version=8.3

This scans your theme, plugins, and mu-plugins for deprecated functions and syntax errors that will break in PHP 8.3. The output shows file paths and line numbers for every issue. It's not perfect (false positives happen), but it catches create_function(), strip_tags() signature mismatches, and dynamic property usage.

For agencies running this check across multiple client sites, I batch it through a shell loop:

for site in /var/www/*/public_html; do
  cd "$site"
  echo "Checking $(basename $(dirname $site))"
  wp php-compat --php_version=8.3 --path="$site" >> /tmp/php-audit.log 2>&1
done

This generates a single consolidated audit log at /tmp/php-audit.log that you can review in one pass instead of switching between dozens of terminal windows.

Step 3: Test on a Staging Site with the Target PHP Version

Never migrate production to a new PHP version without testing on staging first. If your host offers one-click staging environments (Kinsta, WP Engine, Flywheel all do), clone production, switch PHP to 8.3, and browse the site as if you're a customer.

Critical paths to test:

• Homepage load: Verify the front-end renders without errors
• Login and admin dashboard: Test authentication and admin panel access
• Post/page editing: Check the editor loads and saves correctly
• Contact form submission: Confirm forms process and send emails
• WooCommerce checkout: Test the entire purchase flow if applicable
• Plugin admin screens: Verify page builders like Elementor or Divi work
• Custom functionality: Test any API integrations or custom code

If you don't have staging, set up a local environment with Local by Flywheel or DDEV and mirror your production stack. It's 30 minutes of setup that prevents hours of production debugging.

Key Takeaway: I run a 30-second WP-CLI compatibility check, review outdated plugins, and test on staging before every PHP migration. This three-step audit catches over 90% of compatibility issues before they become downtime—and it takes less time than fixing a broken checkout after your host force-migrates you.

Agency Workflow: Batch PHP Migration for 5-50 Client Sites

For agencies managing multiple client sites, PHP migrations are a project management problem more than a technical one. You can't manually audit 50 sites in a single week. You need a repeatable workflow and client communication template.

I refined this workflow over three PHP migration cycles (7.4 to 8.0, 8.0 to 8.1, and 8.1 to 8.2) managing 30-50 client sites per cycle. Here's the four-phase process I use:

Phase 1: Discovery (Week 1) -- Run the WP-CLI compatibility audit across all sites using the batch script from Step 2. Export results to a CSV with site name, current PHP version, and blocker count.

Phase 2: Prioritization (Week 1) -- Sort sites into three tiers:

• Tier 1: PHP less than 8.0, 0-2 blockers -- migrate immediately
• Tier 2: PHP 8.0-8.1, 3-10 blockers -- schedule migration within 30 days
• Tier 3: PHP 8.1+, 10+ blockers -- escalate to custom development or plugin replacement project

Phase 3: Client Communication (Week 2) -- Send a templated email explaining the timeline, the reason (PHP 8.1 end-of-life), and the action required. Include a one-click approval link for migrations and a separate project estimate for Tier 3 sites.

Email template I use:

Subject: Required PHP Update for [Site Name] -- Action Needed by [Date]

Hi [Client Name],

PHP 8.1 reached end-of-life on December 31, 2025, which means it no longer receives security patches. Your hosting provider is planning to upgrade all sites to PHP 8.2 or 8.3 within the next 60-90 days.

I've audited [Site Name] and identified [X] compatibility issues that need to be resolved before the upgrade. These are fixable, but they require testing on a staging environment first to avoid downtime.

**Timeline:**
- Week of [Date]: Fix compatibility issues and test on staging
- Week of [Date]: Migrate production site to PHP 8.3

**Cost:** [X hours at $Y/hour, or flat fee]

Please reply to approve this work by [Date]. If we don't resolve these issues before your host upgrades PHP, your site may experience errors or downtime.

Let me know if you have questions.

[Your Name]

Phase 4: Execution (Weeks 3-6) -- Migrate Tier 1 sites first (low-risk, high-urgency). Schedule Tier 2 migrations with client approval. Convert Tier 3 sites into scoped projects with separate proposals.

This workflow spreads the migration workload across six weeks instead of cramming it into a panic-driven weekend when the host sends the "we're upgrading your site tomorrow" email. The same workflow template applies to any system-level requirement: SSL renewals, MySQL version upgrades, or operating system patches. Building the audit and communication process once saves you dozens of hours every time a new migration wave hits.

If you're managing security alongside performance and update workflows, the complete security audit checklist I use for agency clients covers the broader context these PHP compatibility checks fit into.

Key Takeaway: For agencies, I batch-audit all client sites with WP-CLI, sort them into three tiers by risk, and send templated migration emails with one-click approval links. This six-week workflow prevents the panic-driven weekend when 50 hosts simultaneously force-upgrade your sites.

The 30-Second WP-CLI Diagnostic Script

This is the fastest way to check if your site has obvious PHP 8.3 blockers. Paste this into your terminal from the WordPress root directory:

wp eval 'foreach (get_plugins() as $path => $data) { if (strtotime($data["Version"]) < strtotime("-3 years")) { echo $data["Name"] . " (last updated: " . $data["Version"] . ")\n"; } }'

This lists every plugin that hasn't been updated in more than three years. Those are your highest-risk candidates for deprecated function usage. It's not a substitute for a full compatibility scan, but it's a 30-second smoke test you can run before scheduling the deeper audit.

For a slightly more thorough check that actually looks for create_function() usage in your codebase:

grep -r "create_function" wp-content/plugins/ wp-content/themes/ --include="*.php"

If that returns any matches, you have confirmed blockers that will break in PHP 8.0+.

Frequently Asked Questions

How do I know which PHP version my WordPress site is running?

Log into your WordPress admin dashboard and go to Tools > Site Health > Info > Server tab. It lists your current PHP version under "PHP version." Alternatively, run php -v via SSH or use a tool like Kinsta's MyKinsta dashboard or WP Engine's User Portal, which shows PHP version on the site overview page.

Can I downgrade PHP if the upgrade breaks my site?

Yes, but only temporarily. Most managed WordPress hosts allow you to switch PHP versions through their control panel (cPanel, Plesk, or proprietary dashboards). However, downgrading to an end-of-life version like PHP 7.4 or 8.0 leaves your site vulnerable to unpatched security exploits. Treat downgrading as a temporary rollback while you fix the compatibility issues, not a permanent solution.

What's the difference between PHP 8.2 and PHP 8.3 for WordPress?

PHP 8.2 introduced deprecation warnings for dynamic properties, which will become fatal errors in PHP 9.0. PHP 8.3 tightened enforcement around function signatures like strip_tags() and delivered incremental performance improvements for WordPress workloads. WordPress added beta support for PHP 8.3 starting with version 6.4, and WordPress 6.8 (released April 2025) upgraded PHP 8.3 to fully compatible status in July 2025 after it crossed the 10% adoption threshold. The differences matter most at the plugin and theme level, where older code may trigger errors.

Do I need to update WordPress core before upgrading PHP?

Yes. Always update WordPress core to the latest version before upgrading PHP. WordPress 6.8 (released April 2025) marked PHP 8.3 as fully compatible in July 2025 after it crossed the 10% adoption threshold. Earlier WordPress versions may work on PHP 8.3, but they haven't been thoroughly tested against newer PHP releases and may have edge-case bugs that were patched in later core updates.

How often should I audit PHP compatibility?

Quarterly for agencies managing multiple sites, or whenever a new PHP minor version is released. For individual site owners, audit at least once per year or whenever you receive an email from your host announcing a PHP upgrade. Set a recurring calendar reminder for the first week of each quarter to check Site Health and run a WP-CLI compatibility scan.

Don't Wait for the Email from Your Host

PHP version upgrades are inevitable. End-of-life dates are published years in advance. PHP 8.1 died on December 31, 2025. PHP 8.2 reaches end-of-life in December 2026. PHP 8.3 reaches end-of-life on December 31, 2027.

The difference between a smooth migration and a weekend of downtime is 30 minutes of proactive auditing. Run the WP-CLI compatibility check, review the plugin list, and test on staging before your host sends the "we're upgrading tomorrow" email. For agencies, build the batch audit workflow once and reuse it every quarter when the next PHP minor version lands.

If you're evaluating hosting providers that handle PHP upgrades more predictably, I've written a detailed breakdown of how to choose managed WordPress hosting and why it matters for long-term maintenance. For the sites I manage, working with hosts that provide staging environments and advance migration tools (Kinsta, WP Engine, Flywheel) makes PHP upgrades straightforward instead of stressful.

If keeping up with PHP compatibility, plugin updates, and security audits feels overwhelming, that's exactly what a maintenance plan is for. I handle the quarterly audits, staging tests, and forced migration responses so you don't have to debug a broken checkout on a Tuesday morning.