At 9:47 p.m., a client Slack message arrives: “The site is white.” Two hours earlier, the host had automatically moved the server to PHP 8.3. The WordPress installation itself was healthy, but an old custom plugin still called each() on the homepage, and that one fatal error brought down the public site and wp-admin.
That's the part most tutorials miss. Updating PHP on WordPress isn't a control-panel task. It's a compatibility decision followed by a controlled production change. The version you choose, the plugins you test, the backup you can restore, and the rollback path you've prepared matter more than the final click.
The safe process is straightforward: identify the current runtime, choose a supported target, clone the site, update the staging copy, test the workflows that matter, and promote only after the logs and user journeys are clean. For agencies, the same discipline also determines which sites should move first and which ones need refactoring before they move at all.
Table of Contents
- The Real Risk Behind a PHP Update
- Where WordPress Stands on PHP in 2026
- Pre-Flight Checklist Before You Touch Anything
- Updating PHP Through Your Host or WP-CLI
- Testing and Verifying the New Runtime
- Choosing the Right Target Version
- A Repeatable PHP Upgrade Workflow for Portfolios
The Real Risk Behind a PHP Update
PHP upgrades expose code that older environments tolerated. A deprecated function may have sat untouched inside a plugin for years because no one visited the relevant code path under the old runtime. Once PHP changes, the same function can produce a fatal error before WordPress finishes loading.
Legacy calls such as create_function(), each(), ereg(), or mysql_query() are common warning signs in older themes and extensions. Strict typing and changed behavior around comparisons can also expose assumptions that were never tested. The failure may appear on the homepage, during an AJAX request in a page builder, or only when a customer reaches checkout.
Why one extension can take down the whole installation
WordPress loads many components during a normal request. If one active plugin throws an unrecoverable error while WordPress is building the page, the request can return a blank screen or an HTTP 500 response. If the same plugin loads during administration, you may lose access to wp-admin as well.
That cascade changes the recovery plan. You might need to rename the plugin directory through SFTP or a host file manager, switch the active theme by renaming its directory, or inspect wp-content/debug.log before you can log in again. Recovery mode can help, but it shouldn't be your only escape route.
Practical rule: Treat the PHP selector as the final step in a deployment, not as the beginning of troubleshooting.
The most dangerous mistake is choosing a target version because it's the newest option visible in the host panel. A site on an old WordPress branch with a heavily customized theme, a page builder, and commerce extensions may need a staged move. Another site with current software may be ready for a newer runtime immediately.
The triage question
Before changing anything, place every installation into one of three groups:
- Ready to move: Core, theme, and critical plugins have been updated and pass staging tests on the target runtime.
- Move with observation: The site has minor compatibility warnings, but its critical workflows work and rollback is prepared.
- Refactor first: A custom plugin, abandoned extension, or theme produces fatal errors or depends on unsupported PHP behavior.
That classification is more valuable than a generic instruction to “update PHP for speed and security.” It tells you which sites should move now, which should wait, and what work blocks the change.
Where WordPress Stands on PHP in 2026
The WordPress ecosystem has a long tail of older PHP installations. A January 2026 snapshot recorded PHP 8.2 on 27.29% of WordPress sites, PHP 8.3 on 16.74%, PHP 8.4 on 4.90%, and PHP 7.4 on 22.20%, with PHP 7.3 and 7.2 still present at 2.04% and 1.81% respectively, according to the PHP support overview.
That distribution creates two operational problems. First, many sites are still running versions that no longer receive current security coverage. Second, a host-driven upgrade can move a neglected site across several compatibility boundaries at once, turning old technical debt into an outage.
PHP support dates make the planning less abstract. PHP 8.2 reaches the end of security support on 31 December 2026, PHP 8.4 remains supported until 31 December 2028, and PHP 8.5 until 31 December 2029, as listed in the PHP end-of-life timeline. Security-only support means the branch may receive security fixes without receiving the same level of ongoing maintenance or compatibility improvements as a newer branch.
Comparing practical targets
| PHP Branch | Support Status | WP Core Compatible | Recommended For |
|---|---|---|---|
| PHP 7.4 | Outside current WordPress support guidance | Legacy compatibility only | Temporary containment while preparing a migration |
| PHP 8.2 | Security support ends 31 December 2026 | Compatible with current WordPress installations when the site stack is tested | Sites requiring a conservative intermediate target |
| PHP 8.3 | Supported branch with a shorter runway than 8.4 | Compatible when the installed WordPress branch and extensions are validated | Sites whose plugins are ready for 8.3 but not 8.4 |
| PHP 8.4 | Supported through 31 December 2028 | Compatible with appropriate WordPress core versions and tested extensions | Current sites needing a longer support runway |
Choice usually sits between 8.2, 8.3, and 8.4. A legacy site may need 8.2 as a controlled landing point, while a maintained site can often target 8.4 after staging validation. Don't confuse core compatibility with complete site compatibility. WordPress may run correctly while a plugin, theme, or server extension still fails.
The benchmark case for leaving 7.4 behind is measurable. One 2026 benchmark recorded 139.06 requests per second on PHP 7.4, 146.09 on PHP 8.2, and 148.30 on PHP 8.5, representing 5.1% and 6.6% increases against the 7.4 result, as reported by WordPress hosting performance benchmarks. The practical lesson is to prioritize the move off 7.x first. Minor jumps within the 8.x family generally deserve testing, but they're less likely to deliver the same kind of change as leaving a legacy branch.
Pre-Flight Checklist Before You Touch Anything
A production PHP switch should begin with four controls: a recoverable backup, an inventory, a staging clone, and a baseline. If one is missing, the change isn't ready.
1. Create a backup you can restore
Use UpdraftPlus or BlogVault, or create a manual archive and database export over SSH:
- Files:
tar -czf site-files.tar.gz public_html/ - Database:
mysqldump -u DB_USER -p DB_NAME > database.sql
Store the result offsite. Test restoration into a disposable environment. A backup that exists in a dashboard but has never been restored is an assumption, not a rollback plan.
2. Audit the code before changing PHP
Record the active theme, parent theme, custom plugins, page builder, commerce stack, and integrations. Review the plugin's WordPress.org compatibility information, check the PHP Compatibility Checker from WP Engine, and read recent vendor changelogs.
For custom code, search for known legacy calls:
- Deprecated functions:
ereg,each, andcreate_function - Removed database APIs:
mysql_queryand relatedmysql_*calls - Theme risk: direct assumptions about loose comparisons, null values, or old constructor behavior
Automated scanners can miss dynamic calls and vendor libraries, so treat their results as evidence rather than a guarantee. The WordPress PHP version checker guide can also help you establish the current runtime before testing.
3. Clone the site to staging
Create a staging subdomain or use LocalWP, Kinsta staging, or WP Engine's staging environment. Protect the clone from indexing, disable outbound email where possible, and make sure payment gateways remain in a safe test mode.
The recommended order is clone first, update WordPress core, plugins, and themes on staging, then switch staging to the target PHP version. This separates ordinary software updates from runtime incompatibility and gives you a cleaner failure signal.
4. Capture a working baseline
Before the switch, take screenshots of the homepage, key landing pages, login screen, contact form, and checkout. Submit a test form, inspect the browser console, and record the current PHP and WordPress health information.
Enable logging where appropriate, then inspect the logs during representative traffic. Don't leave verbose debugging exposed on a public production site. Your baseline should tell you what “working” means before PHP changes, so you can compare behavior rather than relying on memory.
Updating PHP Through Your Host or WP-CLI
Start by confirming the runtime you're serving, not the version your hosting panel claims to have selected. In WordPress, open Tools, Site Health, Info, Server and inspect the PHP version. Over SSH, use WP-CLI:
wp eval 'echo PHP_VERSION;'
A temporary phpinfo() page can expose server-level details, but remove it immediately after use because it reveals configuration information. The important distinction is between the command-line PHP binary and the PHP handler serving web requests. They may not be the same.
cPanel and Plesk
In cPanel, open MultiPHP Manager, select the domain, choose the target PHP branch, and apply the change. Some servers use a per-domain selector, while others use an .htaccess handler or hosting-specific configuration. After saving, verify the public site and run the PHP version check again.
In Plesk, open the domain or subscription's PHP settings, choose the version, and save. Plesk may expose handler, FPM, and extension options separately. If the panel reports the new version but WordPress still reports the old one, investigate the active PHP handler and any server-level override instead of repeatedly clicking Save.
Managed hosts use their own workflows. WP Engine, Kinsta, and Cloudways provide dashboard controls or support-assisted changes, but the available options and automatic rollout behavior differ by plan and environment. Read the host's current instructions and confirm whether staging and production are being changed independently.
SSH and WP-CLI verification
SSH users should identify the binary and installed packages before switching:
- Locate the CLI binary:
which php - Inspect installed PHP trees:
ls /etc/php/ - Review loaded modules:
php -m - Confirm the web-facing runtime:
wp eval 'echo PHP_VERSION;'
Check that required extensions, including imagick, intl, and sodium, are available to the target environment. On self-managed Debian or Ubuntu systems, update-alternatives can change the CLI default, but it won't necessarily change PHP-FPM or the web server handler. Use the hosting stack's documented selector or service configuration for the web process.
After the change, account for FPM versus mod_php, restart or reload the relevant service when your host requires it, and reset OPcache. A stale FPM worker or cached opcode can make a successful version change look inconsistent across requests. Confirm the runtime from the browser-facing WordPress site, not only from SSH.
WordPress.org explains that PHP is installed on the server, so updating it generally requires host settings or provider assistance rather than a WordPress admin toggle. That distinction is also why a panel change can appear successful while production continues to execute the old handler.
Testing and Verifying the New Runtime
Treat the version switch like a release promotion. Before changing staging, capture Site Health, export the database with wp db export, and record the baseline pages and workflows. After the change, compare behavior and logs rather than relying on the fact that the homepage loaded.
Test the paths that generate revenue or leads
Run checks in a deliberate order:
- Public pages: Load the homepage, a representative post, key landing pages, and the shop archive.
- Commerce flows: Open a variable product, add it to the cart, complete checkout in a safe test mode, and confirm order processing.
- Lead capture: Submit every important contact or quote form and verify delivery or CRM handoff.
- Administration: Open
wp-login.php, edit a post, publish a change, and test the page builder if the site uses one.
Watch for blank screens, HTTP 500 responses, broken AJAX actions, missing images, and PHP deprecation or fatal errors. A page can render correctly while an admin save, scheduled task, or checkout callback fails.
Inspect logs and background processes
Open wp-content/debug.log and the PHP error log in cPanel or the managed host dashboard. Over SSH, a PHP-FPM log may be available through a command such as:
tail -f /var/log/php-fpm/error.log
The exact path varies by distribution and host, so use the provider's log location when that file doesn't exist. Also confirm that plugins and themes remain active:
wp plugin status --porcelain
wp theme list
Use an incognito browser session to bypass your normal object cache, validate the REST API response, and inspect due cron events:
wp cron event list --due-now
A clean staging run should include a Lighthouse pass and a complete transaction test before production promotion. After production cutover, keep an eye on logs and user reports, especially for workflows that don't appear in ordinary browsing.
Choosing the Right Target Version
The useful question isn't “How do I update PHP on WordPress?” It's “Which PHP version does this WordPress branch and plugin stack justify?” Core compatibility is necessary, but it doesn't certify every extension installed on the site.
The WordPress core compatibility handbook records that WordPress 6.4 and later fully support PHP 8.3, while WordPress 6.8 and later support PHP 8.4. Use the official WordPress PHP compatibility reference to check the branch you're running before assigning a target.
A practical compatibility matrix
| WordPress Version | Minimum PHP | Recommended PHP | Officially Tested |
|---|---|---|---|
| WordPress 6.4 and later | PHP 7.4 | PHP 8.1 or newer | PHP 8.3 in 6.4 and later |
| WordPress 6.8 and later | PHP 7.4 | PHP 8.1 or newer | PHP 8.4 in 6.8 and later |
| Older WordPress branches | PHP 7.4 guidance applies to current compatibility discussions | Upgrade core before selecting a newer runtime | Verify against the relevant branch documentation |
The target should be the oldest supported branch that every critical component has tested successfully, not automatically the newest version in the host menu. A site with current core and maintained plugins may be a good candidate for 8.4. A legacy site with a fragile integration may need 8.2 first, followed by another staged move after the vendor confirms compatibility.
Don't assume that a minor PHP jump is harmless. Plugin authors can lag behind core, custom code may depend on removed behavior, and a large fleet can contain exceptions that aren't visible from a single representative site.
For broader planning, the PHP end-of-life guide is useful when you're assigning urgency to installations that remain on unsupported branches. The decision rule stays simple: test the target with the plugin and theme set, document the result, and move only when the rollback path is ready.
A Repeatable PHP Upgrade Workflow for Portfolios
A portfolio rollout works better when sites are ranked before anyone opens a hosting panel. Start with a roster containing each site's WordPress core version, active theme, critical plugins, current PHP branch, commerce status, staging URL, backup location, and assigned target.
A 30-day operating sequence
Days 0 to 2, inventory and classify. Pull the roster, group sites by current PHP branch, and inspect core and plugin readiness against the 8.2, 8.3, and 8.4 targets. Put maintained brochure sites with simple stacks in the low-risk group, and place WooCommerce stores, membership sites, page-builder-heavy builds, and custom integrations into a higher-observation tier.
Days 3 to 7, stage and test. Create fresh clones, verify backups, update core and extensions, and test the assigned target in staging. Record fatal errors, deprecation notices, failed forms, and checkout problems. Push the sites with clean results first, because early rollouts validate the process without exposing the most complicated installations.
Days 8 to 14, promote carefully. Schedule production changes during low-traffic windows, create a final backup, switch the runtime, and repeat the baseline checks. Compare error-log output before and after the change. If a plugin regression appears, preserve the evidence and open a vendor ticket instead of masking the problem with repeated version changes.
Days 15 to 21, handle the middle tier. Move sites with manageable warnings after their critical workflows pass. Don't leap across multiple unsupported assumptions to standardize the spreadsheet. A smaller, verified step is easier to diagnose than a broad change that updates PHP, core, plugins, themes, and server handlers simultaneously.
Days 22 to 30, resolve the long tail. Refactor or replace legacy components, document rollback paths, and return unresolved sites to the queue with a named owner. Update the portfolio record with the tested target, observed issues, vendor responses, and next review date.
A maintained WordPress inventory management workflow makes this process easier to repeat. For teams managing many installs, WP Triage can monitor core, plugin, theme, and PHP versions, detect known vulnerabilities, and turn portfolio findings into a ranked fix sequence. Pair that visibility with weekly PHP support monitoring and plugin changelog reviews, so the next upgrade cycle starts with current evidence instead of emergency triage.
Use this process on one staging clone today, then record the result in your portfolio roster before touching production. If you manage multiple WordPress sites, visit WP Triage to see how its site inventory, PHP monitoring, vulnerability detection, and ranked risk signals can help you decide which upgrade should happen first.