By Greg Nowak. Last updated 2026-06-23.
If your WordPress or Drupal site supports leads, sales, publishing, donations, client portals, or internal operations, a CMS upgrade in 2026 is not just a CMS task. The practical constraint is usually the stack around it: PHP, extensions, Composer packages, WP-CLI or Drush, cron, PHP-FPM, the database, deployment scripts, and caching at the edge.
That is why a homepage can look healthy while the real risk sits in a form handler, scheduled import, checkout callback, image processor, sitemap job, or plugin that has not been tested against the next PHP version. For business owners and agency teams, the goal is not a prettier version number. The goal is fewer surprises when the host, CMS, or security calendar forces the issue.
The 2026 Pressure Points
As of June 23, 2026, PHP 8.1 is already end of life. PHP 8.2 is still receiving security fixes, but only until December 31, 2026. PHP 8.3 is also in security-only support. PHP 8.4 and 8.5 are the versions with active support windows that buy the most planning time.
WordPress currently recommends PHP 8.3 or greater. The WordPress core team also clarified in May 2026 that WordPress 6.8 and later fully support PHP 8.4, while WordPress 6.9 and 7.0 are documented as fully supporting PHP 8.5. That does not mean every theme and plugin is ready. It means the core platform has moved, and your extension stack needs to be checked.
Drupal is pushing in the same direction. Drupal 11.3 supports PHP 8.5, and Drupal 12 requires PHP 8.5. If Drupal 12 is on your roadmap, the PHP work should start before the major CMS upgrade becomes urgent.
| Current situation | What it means operationally | Practical next move |
|---|---|---|
| PHP 8.1 or older | Outside the safe upstream support window | Treat this as a priority audit and plan a staged move |
| PHP 8.2 | Security-only support ends on December 31, 2026 | Start testing PHP 8.4 or 8.5 before the deadline creates pressure |
| WordPress 6.8 or later | Good candidate for PHP 8.4 planning | Test active plugins, theme code, cron, forms, and editor workflows |
| Drupal 11.3 or Drupal 12 roadmap | PHP 8.5 becomes strategically important | Check Composer constraints, custom modules, extensions, and hosting support |
Why It Spreads Beyond The CMS
The risky part is rarely changing PHP itself. The risk is everything that quietly assumed the old runtime would stay in place: a payment plugin, a contributed module, a custom import, a legacy image library, a server package, or a cache rule that hides a failed response long enough for users and search engines to notice.
This is where upgrade debt becomes business debt. Forms stop submitting. Admin screens time out. Scheduled publishing stalls. Redirects and sitemaps fail quietly. A staging test passes because the command line is using one PHP version while PHP-FPM serves another. These are not exotic failures. They are normal outcomes when the upgrade is treated as a switch instead of a project.
A Short Audit Before You Pick A Target
Start by collecting facts from production and staging. Do not assume they match. Run checks in the web-serving context and the CLI context, because WP-CLI, Drush, Composer, and PHP-FPM may not be using the same binary.
php -v
php -m | egrep 'curl|dom|gd|imagick|json|mbstring|openssl|pdo|xml|zip'
php -i | grep 'Loaded Configuration File'
wp core version
wp plugin list --status=active --fields=name,version,update,status
wp theme list
wp cron event list
drush status
composer outdated --direct
composer prohibits php 8.4
composer prohibits php 8.5For WordPress, pay special attention to mu-plugins, custom themes, form plugins, checkout flows, page builders, filesystem access, and any integration that calls an external API. For Drupal, check custom modules, contributed module compatibility, required PHP extensions, Composer constraints, and deprecation warnings before the server cutover. If Nginx or Apache configuration changes are part of the work, validate them with nginx -t or apachectl -t before reload.
What To Target In Practice
For many WordPress sites in mid-2026, PHP 8.4 is a sensible default planning target: it is current enough to extend the runway, and WordPress 6.8 and later document full support for it. PHP 8.5 can be the better target when the site is already aligned with WordPress 6.9 or 7.0 and the active plugin stack has been tested properly.
For Drupal, the decision depends more heavily on the CMS version path. Drupal 10 sites may use PHP 8.4 as an interim step while the Drupal major-version plan is handled. Drupal 11.3 and Drupal 12 planning should include PHP 8.5, plus the database, Composer, and extension requirements that travel with it.
How To Keep The Upgrade Boring
Make the work staged. First inventory the live stack. Then map compatibility before touching production. Build or refresh staging so it resembles production closely enough to be useful. Test the paths that matter to the business: leads, logins, search, checkout, feeds, redirects, scheduled tasks, media handling, editor workflows, emails, and third-party callbacks.
During deployment, keep a rollback path. Know which snapshot, package version, container image, or hosting setting can be restored. Watch logs immediately after release. Purge or bypass edge cache where needed, especially for admin, previews, forms, and error responses. The upgrade is only done when production behavior has been verified, not when the version number changes.
Where Greg Fits
If you need someone to turn a vague PHP upgrade concern into a workable plan, Greg can help scope the stack audit, identify blockers, coordinate developers and hosting providers, and handle implementation across WordPress, Drupal, Linux hosting, deployment tooling, and caching layers.
Plan a staged CMS upgrade with Greg.
Related on GrN.dk
- Drupal 10 Has a December 2026 Deadline, So Upgrade Inventory Has Become a Real Client Project
- MariaDB 10.6's July 2026 end-of-life makes quiet CMS hosting debt a paid database upgrade project
- Why Your Website's Third-Party Stack Needs Operational Ownership
Need help with this kind of work?
Plan a staged CMS upgrade with Greg Get in touch with Greg.