A WordPress site can look healthy while its PHP branch is approaching the end of security support. Pages still render, the dashboard still opens, and the hosting panel still lists the familiar version. None of those observations establishes how long the runtime will receive upstream fixes. PHP lifecycle planning needs a separate check from day-to-day site availability.
The PHP supported-versions page distinguishes active support, security-only support, and end of life. This guide explains the October 2026 snapshot and turns it into a practical hosting upgrade plan. It does not assume that every plugin supports every new PHP branch or recommend changing production before testing recovery.
Read the support categories correctly
PHP’s policy describes two years of active support followed by two additional years for critical security issues only. Active support includes regular bug and security fixes. During security-only support, releases are made as needed. After the support period ends, the upstream branch is no longer maintained under that policy.
Those categories are not interchangeable. A branch receiving only critical security fixes is still supported for that purpose, but it no longer has the same maintenance promise as an actively supported branch. A branch that reached end of life needs a migration decision rather than an assumption that its last release remains adequate indefinitely.
The page’s exact dates are more useful than estimating from an initial release anniversary. Record the branch, current patch release, and published support deadline in your maintenance inventory. Recheck the table periodically because the planning question changes as deadlines approach.
The October 2026 snapshot
At the source check, PHP 8.2’s security support ends on December 31, 2026. PHP 8.3’s security support ends on December 31, 2027. Both branches are beyond the active-support dates shown in the table. Sites relying on them should understand that distinction and plan their next supported branch.
PHP 8.4 is listed with active support through December 31, 2026 and security support through December 31, 2028. PHP 8.5 is listed with active support through December 31, 2027 and security support through December 31, 2029. These are dated upstream statements, not a perpetual recommendation to install a particular branch regardless of compatibility.
A hosting provider may offer additional maintenance arrangements or distribution-specific backports. Ask what that arrangement actually covers and obtain the provider’s documentation. Do not assume a control-panel label proves upstream coverage, and do not automatically dismiss a documented vendor policy simply because its displayed version string is older.
Identify the runtime that serves the site
A host can have several PHP versions installed. The command-line interpreter may differ from the runtime serving web requests or background jobs. Record the configuration for the actual site and any scheduled processes. A successful CLI test alone does not prove that the website is using the same version or extensions.
Use the hosting panel, WordPress’s supported site-information tools, or the provider’s approved diagnostics. Avoid leaving a publicly accessible diagnostic page that exposes detailed environment information. Remove temporary diagnostics after the check and keep sensitive configuration out of screenshots posted to public support channels.
Record important extensions, memory and execution settings, and application-specific requirements. The goal is not to copy every configuration value blindly. It is to understand the settings and dependencies that the site genuinely needs so you can compare the new environment deliberately.
Test the whole site, not just its front page
Create a staging environment with a supported copy of the site and appropriately protected data. Confirm that staging cannot send real customer emails, process real payments, or trigger production integrations during the test. A PHP compatibility exercise should not become an unintended live business operation.
Check the theme, active plugins, custom code, and critical workflows. For a content site, that includes editing and saving posts, media upload, search, feeds, and scheduled publication. For a shop, test the approved sandbox checkout path, account access, tax and shipping logic, and transactional output without placing real orders accidentally.
Review logs for warnings and failures as well as visible page behavior. Some compatibility problems occur in background jobs or less-used administration screens. A rendered homepage is a useful check, but it cannot represent every code path in a complex WordPress installation.
Separate runtime changes from unrelated updates
Where practical, evaluate the PHP branch change separately from a large plugin or theme overhaul. That makes a regression easier to attribute. If a compatibility fix requires updating a dependency, document the relationship and test the resulting combination rather than changing everything at once without a baseline.
Read the migration guidance for the branches involved and the support statements of important vendors. Deprecations, changed behavior, and extension availability deserve specific attention. Do not assume that a plugin’s broad “PHP compatible” label supplies a tested guarantee for your exact version and configuration.
For custom code, have a qualified maintainer review failures instead of suppressing all diagnostics. Turning off error display can protect visitors from internal details, but it does not resolve the underlying issue. Keep private logging enabled according to your operational policy so failures remain observable without being exposed publicly.
Recovery must include database state
Take a current backup of both files and the database before the production change. A runtime switch may be reversible in the hosting panel, but plugin behavior during the test or cutover can also alter data. Know what your backup captures and how you would restore it if the site’s state changes.
Use a maintenance window that matches the site’s activity. For a shop or frequently edited publication, think about orders, comments, and content arriving during the change. A blanket restore to an earlier database can discard legitimate activity after the backup point. Plan how that activity will be protected before declaring rollback easy.
Keep the prior working configuration documented, including the runtime branch and necessary extensions. Do not rely on memory or a screenshot that omits important settings. A recovery procedure should be executable by the authorized person responsible for the site, even if the original tester is unavailable.
Cut over with a short acceptance checklist
After selecting the tested runtime in production, verify that the site reports the intended environment. Repeat the critical workflows, inspect logs, and confirm scheduled tasks. Clear caches only through the supported process, recognizing that cache invalidation can temporarily change load and response times.
Monitor both user-facing errors and background failures for an appropriate period. A site may pass immediate checks and later fail on a scheduled export, backup, or publishing job. Keep the rollout record open until the relevant recurring work has run successfully or been tested in a representative manner.
If a problem appears, use the prepared recovery decision rather than experimenting with progressively broader permissions or disabled protections. Record the symptom and environment so the compatibility issue can be resolved in staging. Repeatedly changing production without a hypothesis can make the incident harder to understand.
Turn the deadline into an owned task
For each site, record an owner, current branch, tested target, deadline, and unresolved dependencies. A runtime approaching security end of life should have a concrete migration ticket. “The host handles it” is only useful if the host’s responsibility and coverage are actually documented.
Review the inventory after the change and remove obsolete exceptions. The purpose is a supported operational state, not merely checking off one upgrade. The next deadline should already be visible enough that maintenance can happen deliberately instead of during an emergency.
The takeaway
PHP support status is a separate property from whether a website currently works. Read the upstream dates, identify the runtime actually serving the site, test real workflows in staging, and prepare data-aware recovery. A planned branch upgrade is safer than waiting until security support has already ended.
Source checked October 8, 2026. Recheck the PHP support table and your host’s documented policy before acting later.
