PHP 8.2 reaches end of life on December 31, 2026, and managed WordPress hosts are already scheduling the move to newer versions.
For a well-maintained site, the move is routine infrastructure work. For a site where plugin compatibility, custom code, and staging have gone unchecked, the host’s upgrade date is when those gaps reach production.
Below, we explain where PHP upgrades break WordPress sites, what to do before the date, what the upgrade reveals about your maintenance coverage, and the questions to put to your host before the cutover.
PHP 8.2 end of life: the dates that matter
Every PHP release branch follows a published schedule. The PHP project gives each branch two years of active support after its initial stable release, followed by two years of fixes for critical security issues only.
When those four years end, the branch reaches end of life and receives no patches of any kind. PHP 8.1 reached that point at the end of 2025. PHP 8.2 reaches it on December 31, 2026.
Managed hosts plan their platform schedules around those dates, and some retire a version shortly before the PHP project stops supporting it. WP Cloud, for example, has published December 15, 2026 as the date PHP 8.2 comes off its platform.
Site owners usually hear about this through an email from their host that names a date and a target version and says that sites still on the old version will be moved.
The timing of this cycle deserves attention. Patchstack’s State of WordPress Security in 2026 report includes server-level malware data from Monarx, which found that malicious file uploads nearly tripled during November and December of 2025. A version change scheduled for mid-December falls inside that window, at a time when many internal teams are working with reduced holiday staffing.
The target version matters as much as the date. As of October 2026, PHP 8.3 receives security fixes through December 31, 2027, PHP 8.4 through December 31, 2028, and PHP 8.5 through December 31, 2029. A move from 8.2 to 8.3 buys one year before the next retirement notice, and a move to 8.4 or 8.5 buys two or three, as long as the site’s plugins and custom code support the newer version.
We saw this play out over the summer. One managed host notified us that sites still on PHP 8.1 would be moved to PHP 8.2, starting with staging environments in mid-August and live sites two weeks later, without a specific date or time for any individual site.
The same notice moved PHP 8.1 to a long-term support option for sites that opted in. Sites that took the default upgrade landed on a version with about four months of security support left.
Where PHP upgrades break WordPress sites
A current version of WordPress core keeps pace with new PHP releases. According to the WordPress core handbook, core fully supports PHP 8.3 from WordPress 6.4 onward, PHP 8.4 from 6.7, and PHP 8.5 from 6.9. Sites running older core releases need a core update before the PHP change, and that update can introduce compatibility questions of its own.
Most of the breakage we see comes from the code around core, meaning plugins, themes, and custom functionality written against an older version of the language.
Each PHP release deprecates or removes older functions and tightens how the language handles types. Code that only produced deprecation warnings on the old version can throw fatal errors on the new one.
When a fatal error hits the homepage, someone notices within minutes. The harder cases are failures in places nobody checks on the day of the change. These include a checkout step, a form submission handler, a scheduled import, and an integration that runs overnight. The site appears normal, and the problem surfaces days later as missing orders or missing leads.
Much of the risk depends on whether each plugin is still maintained. Developers who are still working on a plugin generally ship compatibility updates ahead of a PHP end-of-life date. Plugins whose developers have moved on do not receive them.
Patchstack’s 2026 report found that 46% of WordPress vulnerabilities disclosed in 2025 had no developer fix in time for public disclosure, and an abandoned plugin will never receive one.
Hidden dependencies cause much of the remaining trouble. During a hosting migration earlier this year, we traced a broken site to a plugin bundled inside the theme. That plugin stopped working once it was running without an active license, which is a requirement our team rarely sees in bundled components.
On another site, a product customization tool failed on file uploads because the hosting environment lacked the image-processing libraries the tool depended on. We determined that moving that site to a host that supports those libraries would be a smaller fix than rebuilding the tool. Commercial plugins distributed in encoded form create a similar dependency, since only the vendor can issue a build that runs on the new version.
A PHP version change can expose all of these at once, because the extensions and libraries available on one PHP build may not carry over to the next.
What to do before your host’s date
Before anything changes, record a baseline of the numbers that matter to the business, such as weekly form submissions, completed orders, and outbound email volume. A failure in a path nobody tested usually shows up first as a drop in one of those numbers, and a baseline is what makes the drop visible.
Next, take a complete backup of files and database. Confirm which PHP version each environment is running. The Site Health screen in WordPress reports it, and so does your hosting control panel.
Check for anything that pins a version outside the panel, because an .htaccess handler, a cron command that calls a specific PHP binary, or a deployment script with a hard-coded path will keep using the old version after the panel says otherwise.
Then run a static compatibility scan of your plugins, themes, and custom code against the target version. This produces a list of removed functions and incompatible syntax before anything runs.
Before trusting a staging test, confirm that staging runs the same WordPress, plugin, and PHP versions as production. While debugging a site that worked on staging and failed in production, the first difference we found was that production had already received a newer core release.
Once the versions match, switch the staging copy to the target version with debug logging enabled. Work through the parts of the site that do not run during ordinary browsing. These include a complete checkout, every form that sends email, image uploads, scheduled tasks, and any import or export. Expect the log to fill with deprecation notices, which are worth fixing over time. The fatal errors are the ones that must be resolved before the switch.
When a site is several versions behind, moving one version at a time keeps each failure traceable to a specific change. After the production switch, someone should watch the error log during the first hours of live traffic, since some code paths only run when a particular visitor or external service calls them. Compare the following week’s numbers against your baseline.
Newer PHP versions also run faster, since PHP 8 brought significant performance improvements over earlier releases. For most of the organizations we work with, the security support is the deciding factor.
What a forced migration shows about your maintenance coverage
Hosting and maintenance cover different layers of the same stack. The host keeps the server and the PHP runtime current, and maintenance keeps the site’s own code compatible with that runtime. A host-scheduled upgrade tests whether that second layer has an owner.
Hosts say as much in their own notices. After a recent automatic WordPress core upgrade, the confirmation we received stated that the host had verified the upgrade completed but does not test specific site functionality, and it recommended reviewing each site manually.
On one occasion we received two notices back to back, the first listing several environments as upgraded and the second listing the same environments as failed. We verify each site directly for that reason.
When a PHP change breaks a site, the cause usually traces back to a gap in that ownership. Sometimes plugin updates were applied on a schedule with no review of which plugins are still supported.
In other cases, custom themes and plugins sat outside the maintenance agreement, and nobody has touched that code since it was written. Many sites have no staging environment that matches production, which makes the live site the first place the new version runs. Often, nobody is assigned to verify forms, checkout, and integrations after the change goes in.
Automatic updates do not close these gaps on their own. Andrew Engstrom, our WordPress Practice Lead, flagged that repository auto-updates are unreliable for plugins that have been disconnected from the WordPress.org repository or are no longer supported. He recommended a vulnerability scan after every maintenance cycle as part of our standard checklist.
The longer these gaps go unaddressed, the more the eventual fix costs. Great News Life, a Midwest media organization, came to us with a WordPress multisite network that had grown too outdated to upgrade. Its server environment had been held back on old software on purpose, just to keep the sites running. By that point, an incremental PHP upgrade was off the table.
We rebuilt the platform as a single WordPress installation and migrated more than 100,000 pieces of content over roughly six months. Each skipped upgrade widens the distance between a site’s code and a supported runtime, and Great News Life shows how far that distance can grow.
Questions to ask your host before the cutover
What date will our site move, and to which PHP version?
Confirm the exact date and target version for every environment you run, including staging and development copies. Hosts can handle sites pinned to a specific version differently from sites on a default setting, so a general announcement may not describe your account. If the host gives a window instead of a date, ask whether you can upgrade on your own schedule before it opens.
Can we run the new version on staging first?
Ask whether you can switch a staging copy to the target version now. Also ask whether that staging environment matches production in PHP extensions, caching, and server configuration. A test on a different stack tells you little about how production will behave.
Which PHP extensions and server libraries are available on the new version?
If your site relies on image processing, PDF generation, specific database drivers, or any other function that depends on a PHP extension, get written confirmation that the extension is installed and enabled on the new version.
What happens if something breaks after the switch?
Ask whether you can temporarily revert to the previous version, how long that option lasts, and how quickly support responds during the migration window. Hosts set their own rollback policies for retiring versions, and it is better to learn yours before the date than during an outage.
Do you offer extended support for the retiring version?
Some organizations need more time than the host’s schedule allows, and some hosts offer long-term support options for retiring versions. Ask whether one exists, what it covers, and when it ends. Treat any extension as time to finish remediation, since the code still has to move.
What does your security layer cover?
Host firewalls and malware scanning protect the server, and they are worth having. They cannot stand in for keeping application code current. In penetration testing published in its 2026 report, Patchstack found that the defenses at the hosting companies it tested blocked only 26% of vulnerability attacks.
Questions to ask whoever maintains your site
The host’s answers cover the server. The rest of the picture comes from your maintenance provider, or from whoever on your team owns the site.
Ask which PHP version the site has been tested against, and when that test took place. Ask whether custom themes and plugins are included in maintenance or handled as separate projects.
Request a list of installed plugins that are no longer actively developed, along with a plan for each one. Then ask what gets checked after the version changes, including forms, checkout, scheduled tasks, and outbound email.
Vague answers are worth resolving before the host’s date, because the upgrade will go ahead either way. If those answers point to gaps in coverage, our WordPress maintenance and support plans are built to close them.
How we handle PHP version changes at Curious Minds Media
Curious Minds Media has been in business since 2004, and our maintenance work is handled in-house by our engineering team. PHP compatibility is part of our onboarding audit.
Our standard onboarding includes an automated static code analysis that scores the codebase and points our developers to the trouble spots. Capturing baseline metrics is now part of the client health checklist we run for every client.
When we brought on a new maintenance client earlier this year, the onboarding audit flagged the PHP upgrade and plugin cleanup as the top priorities. We started the upgrade on a staging copy, with production to follow once testing was complete.
For sites with custom themes, custom plugins, or complex integrations, a PHP upgrade runs in a consistent order. We review installed plugins and themes for compatibility with the target version, then replace components whose developers will not update them.
Next, we bring custom code up to current PHP standards. We test the new version on staging, then switch production during a planned window. Afterward, we verify the site, including forms, checkout flows, integrations, and a test send from the site’s mail configuration.
After maintenance on production, we bring staging and development environments up to the same versions, and we check with the client first in case their team is working in one of them.
When a PHP upgrade needs more time than the maintenance plan covers, we provide an estimate before the work starts. For clients whose hosting we also manage, the same team handles the infrastructure change and the application work.
If your host has sent a PHP retirement notice and you are not sure who is responsible for the site side of it, we are happy to review your site and walk you through what the upgrade will involve. Talk to our team about WordPress maintenance.
