Select a supported runtime compatible with the verified site stack, test a representative isolated environment, prepare coherent recovery and new-data handling, then release within the authorised domain.
Changing PHP changes the runtime that executes WordPress and its extensions. A current WordPress core release can support a PHP branch while an old theme, custom integration or required server extension still fails on that combination.
Plan the upgrade as a controlled compatibility change: identify the actual runtime, test a representative private copy, prepare a recoverable release and verify the site’s important tasks. The aim is a maintained, supported environment with evidence that your own stack works, not the highest number offered in a hosting dropdown.
Separate PHP support from application compatibility
The PHP support calendar distinguishes active support, security-only support and end of life. Check the branch and its remaining support window at the time of the decision. A branch still installed by a host is not automatically maintained upstream.
WordPress’s PHP compatibility matrix is about WordPress core versions. It is not an approval of every plugin, theme or custom snippet. The current matrix also explains that the historic “beta support” label has been retired; old articles using that label may not describe today’s position.
Review the current WordPress requirements, the host’s available supported branches and your components’ documented requirements together. Do not infer whole-site compatibility merely because the installation screen or homepage loads.
Record the real environment and the change boundary
Use the authenticated Site Health information and the host’s scoped configuration to record the runtime serving this site. Include WordPress, theme and plugin versions, relevant extensions and important custom code. Keep technical reports private and redact unnecessary paths or account details.
| Layer | What to record | What it does not prove |
|---|---|---|
| PHP branch and patch | Current and proposed web runtime | Compatibility of the site’s extensions |
| WordPress and components | Exact versions and maintainer requirements | Every feature works on the proposed combination |
| Server configuration | Needed modules, limits and handler context | A command-line result matches web requests |
| Data and integrations | Writes, scheduled tasks and outside effects | Restoring files alone reverses everything |
PHP’s configuration-file documentation explains that configuration loading depends on the execution context. A terminal PHP version can differ from the website’s runtime. Ask the host to confirm the actual domain-level scope, particularly on an account with several unrelated websites.
Resolve prerequisites without combining every change blindly
Check component release notes and requirements for the proposed branch. If prerequisite updates are needed, plan and test them in a known sequence. Keep a record of which change introduces a failure rather than updating everything and losing the ability to identify the responsible step.
WordPress’s PHP-update guidance covers preparation, backups and host-level runtime changes, while acknowledging component compatibility limits. Use the current compatibility matrix and PHP calendar for version decisions rather than relying on old version numbers or generic performance promises in introductory material.
For custom code, review the migration documentation for each relevant version transition. The PHP 8.5 migration guide, for example, links backward-incompatible changes, deprecated behaviour and changed features. It is one transition reference, not evidence that all older jumps or every site’s code have been checked.
Prepare a representative private test environment
A development copy lets you reproduce the site’s actual stack before changing the public runtime. WordPress documents running a development copy; the copy still needs deliberate isolation from the live site’s services and data flows.
Use appropriate access protection and separate configuration. Prevent test orders, contact messages, newsletter sends, payments and webhooks from reaching real customers or modifying live systems. Use supported sandboxes or inert fixtures where necessary. A test site must not share a writable production database simply because the URLs differ.
Match the relevant PHP branch, modules, limits and component versions. Document unavoidable differences, such as hosting cache or an unavailable integration sandbox. The private staging guide covers access and indexing boundaries; noindex alone is not access protection.
Back up the coherent site and define rollback data handling
WordPress’s backup documentation distinguishes files and database data. Prepare a recoverable set for the change and verify how it would be restored. A backup listed in a dashboard is different from a known usable recovery route.
Write two rollback cases. If only the runtime changed and no data migration occurred, the host may be able to restore the previous tested runtime without restoring old data. If a component update changed schema or stored records, returning PHP alone may not restore the earlier application state.
For a dynamic site, define how you will preserve orders, form submissions, account changes or editorial work created after the backup. Restoring an old database over new records can lose them. Coordinate a suitable change window, write restrictions where appropriate and a reconciliation plan rather than promising a one-click rollback with no data impact. The restorable-backup guide covers the separate recovery test.
Exercise tasks that actually run PHP
Start with a baseline on the old test runtime, then switch only the intended environment and repeat the same cases. A cached homepage may avoid important execution paths, so it is an inadequate sole acceptance test.
- Open representative public articles, archives, search and missing-page routes.
- Log in with an appropriate test account; edit, save and reopen a harmless draft.
- Upload and process a sample image where that feature is used.
- Exercise a controlled form and verify the intended stored result and isolated notification route.
- Run approved sandbox purchase or integration cases where the site depends on them.
- Check scheduled tasks and background processing that may run later than the browser visit.
Use the site’s existing update-test workflow rather than creating artificial success conditions. Record omitted journeys and why they could not be tested.
Investigate failures with private, relevant evidence
Record the action, time and corresponding error. A fatal error, a deprecation notice and a missing extension are different findings. A file path in a stack trace is useful evidence for the maintainer, but it is not always proof that the first named plugin owns the underlying cause.
The WordPress debugging guide describes logging and development tools. Use controlled development/staging diagnostics and keep logs private; do not expose detailed errors to public visitors or leave an information-dump page accessible. Do not disable security or hide failures just to make the test appear clean.
If behaviour differs between staging and production, compare actual modules, configuration and integration scope. Send a minimal redacted reproduction to the responsible host or maintainer. A static compatibility scan can help find candidates, but cannot establish the result of every runtime journey.
Release within the authorised domain and verify again
- Confirm the exact domain, environment, proposed runtime and unaffected neighbouring sites.
- Check the current recovery set, rollback owner and new-data handling plan.
- Apply the tested sequence during the agreed window, using the host’s documented controls.
- Verify the actual web runtime and representative public/admin tasks.
- Review logs, controlled integration results and delayed scheduled outcomes.
- Revert or repair according to the prepared plan if a material task fails.
- Record accepted results, known limits and the next support-review date.
A temporary rollback is a recovery measure, not a reason to remain indefinitely on an unsupported branch. Accept the change only with evidence for this site’s required tasks, and treat any claimed speed improvement as something to measure separately.
Sources and verification
Editorial review 2026-10-13. Source check dates are recorded separately. Notes describe what each source supports and its limits.
View sources
- PHP: Supported versionsChecked Active, security-only and end-of-life branch stages guide supported runtime decisions.
Limits: The guide does not freeze a universal target version or assert that a host-installed branch remains supported. - WordPress Core: PHP compatibility matrixChecked Compatibility is version-specific for core; historical beta-support labelling has been retired.
Limits: Core compatibility does not establish theme, plugin, snippet or whole-site compatibility. - WordPress: RequirementsChecked Current host/runtime requirements and recommendations form part of the environment decision.
Limits: Requirements are reviewed together with component and upstream support, not treated as a sole acceptance test. - WordPress: Site Health screenChecked Authenticated configuration information helps record the site's current runtime and component context.
Limits: No actual report was inspected or unredacted technical information published. - PHP Manual: Configuration fileChecked Configuration loading depends on runtime context; command-line and web configuration need not be identical.
Limits: No phpinfo dump, credential/path disclosure or shared-domain configuration change is performed. - WordPress: Update PHPChecked Preparation includes backup, component compatibility consideration and host-level runtime coordination.
Limits: Old version examples and generic speed/ranking promises are not adopted; current matrix/calendar govern version facts. - PHP Manual: Migrating PHP 8.4 to 8.5Checked Migration documentation separates incompatible changes, deprecations and other transition-specific changes.
Limits: This is one transition example; no claim that every older upgrade path or custom code was checked. - WordPress: Running a development copyChecked A separate development environment supports testing before changing the live runtime.
Limits: Isolation of data and outward effects remains a planned responsibility, not something performed here. - WordPress: BackupsChecked Files and database form distinct necessary recovery material.
Limits: The rollback cases are explicit operational analysis; no actual restore, rollback or guaranteed zero-data-loss outcome is claimed. - WordPress: DebuggingChecked Controlled logging and development diagnostics support correlating runtime failures with the responsible action.
Limits: No security bypass, public error disclosure, production debugging or static-scan compatibility guarantee is recommended.