How should you handle PHP end of life across WordPress client sites without breaking a client’s checkout, forms, or integrations? Start with a portfolio inventory, assign risk, test a supported PHP branch on staging, then roll out changes in small batches. The safe target is the supported branch that each site’s software stack passes in testing, not automatically the newest branch.

For example, an agency might manage a brochure site on PHP 7.4, a WooCommerce store on PHP 8.1, and a custom-integration site on PHP 8.2. This example is illustrative, not a reported client result. Those three sites need different test plans even before anyone changes a server setting.

Build a PHP inventory before changing any client site

Changing PHP site by site without an inventory turns a portfolio task into guesswork. The same PHP branch can behave differently because plugins, themes, hosting configurations, and custom code differ.

Create a PHP version inventory with one row per site. Record the domain, owner, host, current PHP version, WordPress version, active theme, active plugins, staging availability, backup status, business-critical features, and preferred maintenance window. Add a status such as inventory, staging test, ready to upgrade, blocked, or complete.

Check each branch against PHP’s supported versions table and unsupported branches list. WordPress.org currently recommends PHP 8.3 or greater, but treat that as the WordPress baseline, not proof that every plugin is ready for it.

A PHP inventory must record business-critical workflows and rollback readiness, not only the version number.

Separate PHP end of life from WordPress compatibility

PHP end of life means the PHP project no longer provides support for a branch. PHP documents two years of active support followed by two years of security support; after that, the branch reaches end of life. Running an unsupported PHP version leaves known bugs and security issues without fixes.

WordPress PHP compatibility is a separate check. WordPress core may run on a target branch while an old plugin, theme, custom snippet, or integration fails. The WordPress Core compatibility reference maps core releases against PHP versions, but it cannot certify every extension installed on a client site.

Use WordPress.org’s current requirements as a baseline. Then choose a currently supported PHP branch that the site passes in staging. Moving every site to the newest branch on the same afternoon is a poor operating rule.

Triage sites by risk before scheduling upgrades

A PHP upgrade WordPress client sites project needs a risk order before it needs a calendar. Score each site using operational factors rather than traffic alone.

  • Unsupported PHP branch or outdated WordPress core.
  • Abandoned plugins, custom code, or an old theme.
  • WooCommerce, membership, forms, bookings, or other public transactions.
  • No staging copy, unreliable backups, or unclear host access.
  • External callbacks, scheduled jobs, payment services, or server extensions.

In the illustrative portfolio, the WooCommerce site comes first because it combines unsupported PHP with orders and payment handoffs. The custom-integration site may rank next. The brochure site could be lower risk, but an old admin-only code path can still fail during updates or scheduled tasks.

WP Triage fits this decision stage: it gives an agency a 0–100 risk score, the top three issues, and a recommended fix order. It is a decision engine, not a firewall, backup tool, remote updater, or replacement for staging tests. The scoring approach here is agency operating guidance, not published PHP statistics.

When not to upgrade PHP immediately

Pause the production change when the site has no verified backup, no rollback access, an active checkout incident, an abandoned plugin that fails staging, or a host that cannot provide a supported interim branch. Escalate the host, replace the extension, or get a client decision before changing production.

Prepare a repeatable pre-upgrade checklist

Preparation prevents a compatibility failure from becoming a recovery exercise. Run the same checklist for every site, then add client-specific tests.

  1. Verify a recent database and file backup by checking that restoration access exists.
  2. Record administrator credentials, host access, the current PHP branch, and rollback steps.
  3. Update WordPress core, plugins, and themes through the normal maintenance process.
  4. Record the resulting versions so an error can be traced to a specific change.
  5. Copy the site to staging when the host supports it.
  6. Write a smoke-test list covering the homepage, forms, login, search, media uploads, key admin screens, cron-dependent features, and client integrations.

Use Tools > Site Health > Status and Info as an audit input. WordPress documents configuration details, active plugins, themes, media handling, server, database, and filesystem information there. Site Health does not detect every PHP compatibility problem, so it cannot replace a staging test.

Inventory field Example entry Why it matters
Business function WooCommerce checkout Defines the smoke test
Rollback readiness Backup verified; host rollback documented Limits recovery uncertainty
Status Staging test Shows the next action

Test the target PHP version on staging, not in production

Change PHP on a staging copy first. The exact control differs by host, so follow the host’s official documentation rather than assuming every dashboard uses the same labels.

After the change, inspect PHP error logs, server responses, plugin notices, scheduled tasks, and Site Health. Then run the smoke-test list. For the illustrative WooCommerce site, test product pages, cart, checkout, payment handoff, order emails, account pages, and webhook callbacks. A homepage check can pass while cron, wp-admin, or payment processing fails.

Treat deprecation notices, warnings, fatal errors, broken redirects, and silent form failures as blockers until you identify the responsible plugin, theme, custom snippet, or host setting. Compare the WordPress release and target PHP branch with the Make WordPress Core compatibility reference, then verify the actual site stack.

A staging pass counts only when the site’s real workflows pass, including scheduled jobs and third-party callbacks.

Resolve failures before moving the production site

Start with the error message and named file. Don’t disable random plugins on production and hope the site settles down.

Use this decision path:

  • Update the failing plugin, theme, or library to a compatible release.
  • Replace it when the maintainer has abandoned it.
  • Remove unused custom code or isolate a failing snippet.
  • Ask the developer for a compatible release when the integration is bespoke.
  • Keep the site on a supported interim branch while remediation finishes.

Possible test failures include deprecated PHP functions, old constructor patterns, stricter type handling, incompatible ionCube or server extensions, and hard-coded assumptions in custom integrations. These are examples of compatibility problems, not claims that WordPress causes every error. Staying indefinitely on an unsupported branch is not a resolution; PHP’s unsupported-branches guidance recommends upgrading because older releases can retain fixed bugs and vulnerabilities.

Roll out upgrades in controlled batches

Batching reduces the chance that one shared plugin or hosting issue affects the whole portfolio. Upgrade one low-risk pilot site, confirm its tests, then handle similar sites in small groups.

Schedule each production change inside an agreed maintenance window. Record the old PHP version, target version, change time, operator, test results, and rollback decision. After the change, check front-end responses, forms, orders, logins, scheduled tasks, and logs before marking the site complete.

Hosts differ in version controls and rollback options. Document the actual method for each host instead of publishing universal dashboard instructions.

Report the result and keep PHP status on the maintenance schedule

Send the client a short WordPress client maintenance report with the previous and current PHP branches, test outcome, unresolved issues, required plugin or theme work, and next review date.

Keep PHP version, WordPress version, plugin status, host notes, backup verification, and test results in the recurring maintenance record. Review the record against PHP’s supported versions page and end-of-life list. WordPress Site Health can supply the configuration snapshot for that record.

A successful PHP upgrade closes one change record; it does not remove the site from future PHP lifecycle reviews.

The next maintenance action is practical: maintain a PHP version inventory, assign each site a risk status, and review it against the official PHP support table before scheduling another upgrade.

References