More than 70% of publicly accessible WordPress sites were running outdated PHP in a recent independent analysis using Censys data, with PHP 7.4 among the most common versions observed (GBHackers). That changes the way agencies and WooCommerce teams should think about PHP end of life. This isn't a rare legacy problem affecting one neglected client site. It's a portfolio-management problem that can leave dozens of installations exposed, incompatible, and difficult to upgrade at the same time.
The practical mistake is treating every EOL site identically. Some sites can move to a supported runtime after routine staging tests. Others need plugin replacement, theme remediation, database checks, or a rollback plan before anyone changes production. The work becomes manageable when you rank sites by business impact, technical readiness, and security exposure instead of pressing “upgrade” everywhere at once.
Table of Contents
- Why PHP End of Life Is a Portfolio-Wide Problem
- PHP Version Lifecycle and End of Life Timelines
- Security and Compatibility Risks of Running EOL PHP
- Detecting EOL PHP Across Your WordPress Portfolio
- Prioritized Upgrade Workflow for WordPress Sites
- How WP Triage Surfaces and Prioritizes PHP EOL Risk
- Staying Ahead of the Next PHP End of Life Wave
Why PHP End of Life Is a Portfolio-Wide Problem
PHP end of life means the PHP project has stopped supporting a release branch. After the support window closes, newly discovered vulnerabilities no longer receive upstream security fixes. The application may continue running normally, but the runtime no longer has an official path for correcting future flaws. PHP's official supported-versions schedule documents this lifecycle and the point at which each branch becomes unsupported.
For WordPress operators, the risk extends beyond the PHP interpreter. WordPress sites combine core, plugins, themes, hosting configuration, payment integrations, caching layers, and sometimes custom code. A vulnerable plugin on a supported runtime still needs attention, but an EOL runtime removes one important layer of upstream protection. As the surrounding stack advances, old PHP versions also become less compatible with the updates that site owners need to install.
The scale is visible in WordPress usage data. An independent analysis reported that about 30% of WordPress sites were still on PHP 7.x, and every listed PHP 7.x release had already reached EOL (Roots). The same analysis identified PHP 7.4 at 22.62%, PHP 8.1 at 15.66%, and PHP 8.0 at 5.94% of WordPress sites in its breakdown (Roots). Those figures show why agencies can't rely on memory or occasional client requests. Unsupported PHP is likely distributed throughout a managed portfolio.
Why WordPress portfolios feel the pressure first
A single site can hide its PHP risk for a long time. A portfolio makes the problem visible because every site has a different plugin inventory, traffic pattern, revenue role, maintenance history, and client tolerance for downtime. One brochure site may be technically ready for an upgrade, while a WooCommerce store depends on an abandoned payment extension that fails under a newer runtime.
That's why “upgrade all sites now” usually doesn't work. It creates unnecessary production risk on ready sites and ignores the remediation work required on blocked sites. A useful portfolio process separates security urgency from upgrade readiness, then assigns the right next action to each installation.
PHP Version Lifecycle and End of Life Timelines
PHP uses a predictable support model. Each branch receives two years of active support, followed by two years of security support, then reaches end of life after four total years (PHP supported versions). Active support includes routine maintenance and security fixes. Security support covers a narrower window, and no upstream fixes are provided after that period.
For agencies, these dates belong in the portfolio plan, not just the hosting dashboard. PHP 7.4 reached end of life on 28 November 2022, PHP 8.0 on 26 November 2023, and PHP 8.1 on 31 December 2025, according to the official schedule. PHP 8.2 is expected to reach end of life on 31 December 2026, so sites running it should have a tested migration path before that deadline.
PHP Version End of Life Timeline
| PHP Version | Release Date | Active Support Until | Security Support Until | Status in 2026 |
|---|---|---|---|---|
| PHP 7.4 | 28 November 2019 | 28 November 2021 | 28 November 2022 | EOL |
| PHP 8.0 | 26 November 2020 | 26 November 2022 | 26 November 2023 | EOL |
| PHP 8.1 | 25 November 2021 | 25 November 2023 | 31 December 2025 | EOL |
| PHP 8.2 | 8 December 2022 | 8 December 2024 | 31 December 2026 | Supported, approaching EOL |
| PHP 8.3 | 23 November 2023 | 31 December 2025 | 31 December 2027 | Supported |
| PHP 8.4 | 21 November 2024 | 31 December 2026 | 31 December 2028 | Supported |
| PHP 8.5 | 20 November 2025 | 31 December 2027 | 31 December 2029 | Supported |
How to use the schedule operationally
Record the applicable EOL date beside every site in the maintenance inventory. Do not wait for a host notification. Hosting policies differ, and a forced runtime change can arrive during a campaign, peak sales period, or client blackout window. Review the official schedule during quarterly planning, then assign each site to a migration queue based on runtime age, business impact, and upgrade readiness.
A practical queue separates sites into three groups. Move low-risk sites with current plugins and staging coverage first, schedule testing for stores and high-traffic sites with known dependencies, and assign remediation work to installations blocked by abandoned extensions or custom code. This sequence gives the team early wins without treating every site as equally urgent.
A site is not automatically safe because its branch remains supported. Its PHP version, installed code, staging process, and revenue exposure still determine the right next action.
Security and Compatibility Risks of Running EOL PHP
EOL PHP creates a patch gap that grows with every newly discovered vulnerability. If a flaw is found after a branch reaches end of life, the PHP project won't provide a fix for that branch. The site may have other controls, such as a web application firewall, restricted administrative access, or hardened hosting, but those controls don't restore upstream maintenance.
Security trackers classify PHP 8.1 and below as EOL and identify PHP 8.2, 8.3, 8.4, and 8.5 as supported in 2026 (Is It Patched). That classification gives agencies a simple starting point for inventory work, but it shouldn't be the entire risk assessment. A site with an EOL runtime and an exploitable plugin deserves more attention than a low-impact site with the same PHP version and a tightly controlled attack surface.
Three ways the risk compounds
Unpatched runtime vulnerabilities are the most direct concern. Once upstream support ends, the operator owns the exposure created by later PHP flaws. Waiting doesn't make the issue static. It increases the distance between the production runtime and the supported software ecosystem.
Plugin and theme incompatibility creates a second failure path. Maintainers may stop testing against an old branch, hosting providers may reduce available runtime options, and updates may introduce errors that are difficult to reproduce. Fatal errors are the obvious example, but broken background jobs, checkout behavior, imports, and administrative screens can be just as damaging.
Stack interaction makes diagnosis harder. A vulnerable extension, outdated theme, and EOL runtime can leave fewer hardening and upgrade options than any one issue would create alone. Independent commentary on WordPress EOL PHP describes this as a compatibility and patch-gap problem that becomes more difficult as platforms drop old runtime support (Is It Patched).
Practical rule: Treat EOL PHP as a multiplier in your risk model, not as a standalone checkbox.
For WooCommerce, prioritize the paths that affect orders and customer data. Test product search, cart behavior, checkout, payment callbacks, order emails, refunds, scheduled actions, shipping integrations, and tax logic. Don't declare a store ready because the homepage loads. A successful homepage test says almost nothing about the transaction workflow.
Detecting EOL PHP Across Your WordPress Portfolio
You can't prioritize what you can't see. Start by building an inventory that records the PHP version, WordPress core version, active plugins, active theme, hosting environment, site owner, business role, and last successful backup. Include staging sites where they can influence deployment decisions, but distinguish them clearly from production.
For a small portfolio, WordPress Site Health is a practical first check. The Site Health information screen exposes the server environment, including the PHP version. A controlled phpinfo() check can provide additional server detail, but remove the file after use and don't expose it publicly. For a single site, this is quick. For a large agency portfolio, repeating the process manually creates a visibility problem of its own.
Move from manual checks to portfolio discovery
Hosting panels can provide a faster second layer. Review the PHP version assigned to each account, container, or subscription, then compare that inventory with the version reported inside WordPress. The two values may differ when a host uses separate PHP handlers, containers, or environment-specific settings. Verify the runtime that serves the public site, not just the default account setting.
Agencies should also capture dependency evidence. Record plugin and theme versions, whether updates are available, whether an extension is abandoned, and whether the site has custom snippets or mu-plugins. The PHP number tells you the urgency. The dependency inventory tells you whether an upgrade is likely to be routine or blocked.
For a detailed manual walkthrough, use this guide to check the PHP version of a website.
Build a repeatable audit record
A useful audit row answers five questions:
- What runs here? PHP, WordPress, plugins, themes, and custom components.
- Who depends on it? Client, internal team, store owner, or marketing team.
- What breaks if it fails? Informational pages, lead capture, publishing, checkout, or fulfillment.
- Can you test it safely? Staging quality, backup reliability, and rollback access.
- What blocks the change? Incompatible extensions, unavailable staging, or missing owner approval.
If you manage many installations, automate collection where possible and validate exceptions manually. The output shouldn't be a pile of alerts. It should be a current list that lets a technical lead select the next site without opening every dashboard.
Prioritized Upgrade Workflow for WordPress Sites
A reliable migration starts with sequencing, not with the PHP selector in a hosting panel. Rank each site using three lenses: exposure, business impact, and readiness. EOL status raises exposure. WooCommerce checkout, membership access, lead generation, or publishing workflows raise impact. A clean staging environment, current backups, maintained extensions, and a known rollback path raise readiness.
Use that ranking to create separate queues. Ready, high-impact sites should receive controlled upgrade windows. High-impact sites with blockers need remediation work before the runtime change. Low-impact sites still need a plan, but they shouldn't consume the same emergency effort as a store that processes orders.
Audit before touching production
Begin with a compatibility audit. Update the inventory, identify extensions that haven't been maintained, inspect custom code, and check whether the theme or plugins declare PHP requirements. Don't remove a plugin just because it looks old. Confirm what functionality depends on it, identify a replacement, and test the replacement against real content and workflows.
The WordPress PHP version management guide is useful as a reference during this inventory stage. The key operational question is simple: can this site move after normal testing, or must someone fix a dependency first?
Test the complete customer journey
Create or refresh staging from a recent production copy. Test the public pages, login, forms, editor, scheduled tasks, integrations, and administrative workflows. WooCommerce teams should also test the entire purchase path, including payment confirmation, stock changes, order status transitions, emails, refunds, and any fulfillment handoff.
Run the sequence in a controlled order:
- Back up production: Verify that the backup can be restored, not merely that a backup job completed.
- Update the application stack: Bring WordPress core, plugins, and themes to compatible maintained releases where possible.
- Change PHP in staging: Use the target supported branch and review PHP errors, logs, warnings, and failed requests.
- Exercise business workflows: Test the paths that create revenue, leads, accounts, content, or operational tasks.
- Deploy with a rollback route: Schedule the production change, record the previous runtime setting, and define who can reverse it.
Handle failures without improvising
A failed upgrade often reveals a dependency problem that was already present. Don't hide the error by immediately downgrading and closing the ticket. Capture the failing component, reproduce it on staging, replace or remediate it, and repeat the test. If the site can't be tested reliably, it isn't ready for a production runtime change.
For stores, schedule work when order volume is predictably low and make someone responsible for watching checkout after deployment. Keep the old environment available only as a controlled rollback option, not as permission to postpone the migration indefinitely.
How WP Triage Surfaces and Prioritizes PHP EOL Risk
Portfolio triage needs more than a list of EOL versions. It needs context about what else is installed, how severe the known issues are, and which sites deserve attention first. WP Triage provides a decision-engine layer for this purpose. It captures daily snapshots of WordPress core, plugins, themes, and PHP versions across connected installs, then presents portfolio risk through Safe, At Risk, and Critical bands.
Its risk score runs from 0 to 100 and considers signals such as exploitability, software age, known CVEs, and severity. The score doesn't execute the upgrade and doesn't replace backups, staging, hosting controls, or a malware scanner. Its role is to make the action order clearer when several sites need work at once. See the WordPress risk scoring approach for the product's stated model.
Why a single EOL label isn't enough
Consider two sites on the same unsupported PHP branch. One is a low-change brochure site with maintained plugins and no sensitive workflows. The other is a WooCommerce store with an outdated payment extension, an aging theme, and a history of failed updates. Both need a migration plan, but the second site should rise to the top because its business impact and dependency exposure are higher.
A useful triage output should answer:
- Which sites run an unsupported PHP branch?
- Which of those sites also contain known vulnerable plugins?
- Which sites have the highest business impact?
- Which installations appear ready for staging validation?
- What should the operator fix before changing PHP?
WP Triage's portfolio view is designed to show top signals per site and a ranked sequence of issues. Targeted notifications can flag critical vulnerabilities or sudden score drops, while weekly summaries help teams review portfolio changes without treating every maintenance event as an emergency.
Use scores to assign work, not to avoid judgment
Risk scoring supports a decision. It doesn't replace technical review. A high score should trigger validation of the evidence, confirmation of backups, and a staging plan. A lower score shouldn't excuse an EOL runtime, especially when the site has a contractual, regulatory, or revenue-related reason to remain protected.
For agencies, the practical benefit is consistency. The person managing the portfolio can assign the next three fixes per site, while the person executing the work can inspect the detailed inventory and validate the change in existing tools.
Staying Ahead of the Next PHP End of Life Wave
PHP end of life is recurring maintenance, not a one-time cleanup. PHP 8.2 is scheduled to reach end of life on 31 December 2026, according to the official PHP lifecycle schedule. Teams that wait until the deadline will face the same dependency conflicts, client approvals, staging gaps, and checkout concerns that make current migrations difficult.
Build the process into normal operations. Keep a current PHP inventory, review upcoming lifecycle dates during planning, and maintain a staging method that can reproduce production behavior. Choose plugins and themes whose maintainers publish compatibility information and respond to runtime changes. When an extension blocks an upgrade, record the replacement or remediation plan instead of allowing the exception to disappear into a ticket queue.
Make version drift visible
A portfolio can drift after a successful audit. A new site may be onboarded on an old host default, a staging environment may use a different runtime, or a client may restore an older backup. Continuous monitoring catches those changes earlier than an annual review.
Use a simple operating rhythm:
- Review lifecycle dates: Put known EOL milestones into the agency planning calendar.
- Track exceptions: Give every blocked site an owner, reason, and next review point.
- Test routinely: Treat PHP changes as a normal staging exercise rather than a crisis event.
- Rank by consequence: Prioritize stores, authentication-heavy sites, and high-visibility properties before low-impact installations.
- Close the loop: After deployment, verify logs, workflows, and the recorded runtime version.
The agencies that handle PHP upgrades calmly aren't necessarily the ones with the smallest portfolios. They're the ones that maintain visibility, separate readiness from urgency, and start remediation before a deadline turns into an incident. Audit every managed site's PHP version today, identify the blocked dependencies, and assign a clear next action to each installation.
WP Triage monitors PHP, WordPress core, plugins, themes, and known vulnerabilities across connected sites, then turns those signals into portfolio risk bands and a ranked fix sequence. Visit WP Triage to see how it can help your team identify EOL exposure and decide which site to remediate first.