PHP 8.2 Has Six Months Left, and CMS Hosts Need a Plan
By Greg Nowak. Last updated 2026-06-18.
Support calendars are easy to treat as background noise until several of them start pointing at the same quarter. That is where many CMS hosts are now. PHP 8.1 has already reached end of life as of December 31, 2025. PHP 8.2 stays in security support only until December 31, 2026. WordPress now recommends PHP 8.3 or greater. Ubuntu 26.04 arrived in April 2026, and Ubuntu's LTS cycle gives infrastructure teams a natural point to review what should stay in production for years, not months.
On paper, those are separate facts. In practice, they land on the same operational question: do you sort out your PHP estate now, while there is time to test properly, or do you let the second half of 2026 narrow your options for you?
| Signal | What it means in plain terms | Why it matters commercially |
|---|---|---|
| PHP 8.1 is unsupported | Anything still on 8.1 is already beyond routine maintenance. | That work moves from backlog to risk management. |
| PHP 8.2 security support ends December 31, 2026 | As of June 2026, there is still time to migrate cleanly, but not time to keep postponing. | Late-year upgrades cost more attention, more coordination, and usually more disruption. |
| WordPress recommends PHP 8.3+ | For WordPress-heavy estates, 8.2 is no longer a comfortable medium-term landing point. | If you are touching the stack anyway, the target version matters. |
| Ubuntu 26.04 LTS shipped in April 2026 | OS refresh and PHP refresh can be planned together. | One coordinated maintenance cycle is usually cheaper than two separate ones. |
Why this is not just a version upgrade
Most hosting estates are messier than the architecture diagram suggests. There is the public site, of course, but there are also CLI binaries, cron jobs, deployment scripts, extensions, admin tools, and older applications nobody wants to touch until they have to. A mixed CMS estate often adds another layer: WordPress on one stack, Drupal on another, and custom PHP somewhere in between.
That is why the real risk is rarely the version number alone. The bigger problem is discovering too late that one scheduled task still points to an older binary, or one server has a slightly different extension set, or one business-critical site behaves differently under a newer runtime. Those are manageable issues in a staged project. They are expensive issues in a rushed one.
What the dates actually tell you
PHP's support policy is straightforward. Each release gets two years of active support and two years of security-only support. After that, it is end of life. The practical takeaway for hosts is simple: a branch can still be running in production without being a sensible place to stay.
PHP 8.1 is already past that point. If any part of your estate still depends on it, the question is no longer whether an upgrade belongs on the roadmap. It already does.
PHP 8.2 is in a slightly better position, but only slightly. It remains under security support until December 31, 2026. As of June 2026, that gives hosting teams roughly six months. Enough for a planned migration, certainly. Not enough for another round of deferral.
WordPress adds an important bit of context. Its requirements page now recommends PHP 8.3 or greater. That does not mean every site on 8.2 fails tomorrow. It does mean that if you are choosing a destination branch now, aiming for a version that is both supported and aligned with the platform recommendation is usually the more responsible decision.
Why Ubuntu 26.04 changes the timing
Ubuntu 26.04 matters because infrastructure teams rarely upgrade PHP in isolation. Ubuntu says its LTS releases arrive every two years and receive five years of standard security maintenance. That is exactly the kind of cycle production hosting teams plan around.
So if your baseline is already being reviewed because 26.04 shipped in April 2026, PHP should be part of the same conversation. Not because every application must move on the same day, but because this is the moment when package baselines, compatibility expectations, and long-term support windows are already on the table.
For hosts running a shared CMS estate, that matters. WordPress may have one upgrade path. Drupal and custom PHP may have others. The sensible move is to plan across the estate first, then schedule the migrations in stages, instead of handling each site only when the deadline starts to bite.
What hosts should be doing now
The sensible approach is not a blanket announcement that everything will be upgraded immediately. It is a short, disciplined sequence that removes uncertainty.
- Inventory every PHP runtime in use, including web-facing versions, CLI binaries, cron jobs, loaded extensions, and web-server configuration.
- Pick the target branch before testing starts. For WordPress-led estates, the recommendation for PHP 8.3 or greater should shape that choice.
- Test in stages, separating WordPress, Drupal, and custom PHP concerns so compatibility issues show up early and in the right environment.
- Schedule production changes before the year-end squeeze makes every maintenance window harder to negotiate.
None of that is glamorous, which is part of the point. Good upgrade management is usually about making the estate legible early enough that the final cutover feels ordinary.
Where Greg fits
This is a useful place for a freelance operator who is comfortable sitting between infrastructure detail and delivery discipline. Greg can help inventory PHP versions, extensions, cron jobs, and web-server configuration, then run staged upgrade testing across WordPress, Drupal, and custom PHP. The value is not theatrics. It is turning an upgrade that could become a late-year production surprise into a defined piece of engineering work with sequence, scope, and decision points.
For hosts and agencies, that usually matters more than the upgrade itself. Once the estate is clear, the decisions get easier: which sites move first, which dependencies need attention, and whether OS and PHP changes should be bundled into one maintenance plan.
The real decision
The real choice is not whether PHP 8.2 still runs today. It does. The choice is whether you want to handle the second half of 2026 on your own terms.
PHP 8.1 already shows what missed timing looks like. PHP 8.2 has a fixed end date. WordPress has already raised its recommended baseline to PHP 8.3 or greater. Ubuntu 26.04 has already created a natural refresh point. Put together, that makes this a planning problem now, not a December problem later.
Related on GrN.dk
- MariaDB 10.6's July 2026 end-of-life makes quiet CMS hosting debt a paid database upgrade project
- Cloudflare BYOIP customers need a rollback plan, not just trust
- Drupal 10 Has a December 2026 Deadline, So Upgrade Inventory Has Become a Real Client Project
Need help with this kind of work?
Talk to Greg about a staged PHP upgrade plan Get in touch with Greg.