CMS Upgrades in 2026: Choosing PHP for WordPress and Drupal

By Greg Nowak. Updated 25 July 2026.

If your website generates leads, processes payments, publishes time-sensitive content or supports internal operations, a PHP upgrade is not routine server housekeeping. It is a change to the runtime underneath your CMS, extensions, custom code, scheduled jobs and deployment tools.

The business objective is therefore not simply to install the newest PHP release. It is to choose a supported destination that fits the CMS, identify blockers before production and protect the workflows that make the site valuable.

The PHP clock is already running

PHP 8.1 and earlier are outside upstream support. PHP 8.2 receives critical security fixes only until 31 December 2026, so it is now a short-term holding position rather than a sensible destination. PHP 8.3 is also in security-only support. PHP 8.4 receives security coverage through 2028, while PHP 8.5 has active support through 2027 and security coverage through 2029.

That does not make PHP 8.5 the automatic answer. Your CMS version, plugins, modules, Composer packages, hosting platform and custom integrations must all support the target. The best destination is the newest version the complete production stack can run reliably—not merely the newest option in a hosting control panel.

Site position	Likely planning target	Important qualification
WordPress 6.8 or later	PHP 8.4	Confirm the active theme, plugins and custom code
WordPress 6.9 or 7.0	PHP 8.5	Use staging to test the complete extension stack
Drupal 10	PHP 8.4	Drupal 10 does not officially support PHP 8.5
Drupal 11.3	PHP 8.4 or 8.5	Choose in the context of the Drupal 12 roadmap
Drupal 12 plan	PHP 8.5	Also check database, Composer and hosting requirements

A planning matrix for selecting a PHP target. It is a starting point, not a substitute for testing the individual site.

WordPress and Drupal need different decisions

WordPress recommends PHP 8.3 or newer. Its current compatibility guidance documents full PHP 8.4 support for WordPress 6.8 onward and full PHP 8.5 support for WordPress 6.9 and 7.0. Core support is reassuring, but it says nothing definitive about an old page builder, an abandoned payment plugin or bespoke theme code.

For a maintained WordPress 6.8 site, PHP 8.4 is a pragmatic target with a useful support runway. PHP 8.5 deserves consideration when the site runs WordPress 6.9 or 7.0 and its extensions have been verified. Avoid using WordPress’s broad minimum-version support as an operational recommendation: the project retains compatibility with some PHP releases that upstream PHP no longer maintains.

Drupal has tighter version combinations. Drupal 10 supports PHP through 8.4, while Drupal 11.3 adds PHP 8.5 support. Drupal 12 requires PHP 8.5 and raises some database minimums, including MariaDB 10.11 and PostgreSQL 18. A Drupal 12 project should consequently be treated as a platform upgrade, not scheduled as an isolated CMS deployment.

Audit what is actually running

Production, staging, command-line tools and the web server can quietly use different PHP binaries or configuration files. Collect evidence from each environment before choosing the target. These commands provide a useful first pass:

php -v
php -m | egrep 'curl|dom|gd|imagick|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 --tree
composer prohibits php 8.5 --tree
composer check-platform-reqs

Composer’s prohibits command identifies packages whose constraints block a target PHP version. Its answer is diagnostic, not permission to force an update. Review the dependency, available releases and application compatibility rather than bypassing platform requirements.

For WordPress, inventory must-use plugins, custom themes, forms, checkout, search, page builders, filesystem operations and external API integrations. For Drupal, include contributed and custom modules, Composer constraints, required PHP extensions, deprecations and database requirements. Validate changed server configuration with nginx -t or apachectl -t before any reload.

Test the business paths, not just the homepage

A cached homepage is weak evidence that an upgrade succeeded. Build or refresh staging so its PHP extensions, database, configuration and deployment process resemble production. Then test the actions whose failure would create calls, lost revenue or manual cleanup:

Lead forms, confirmations and outbound email
Authentication, password resets and user permissions
Checkout, payment callbacks and subscription events
Search, redirects, sitemaps and structured data
Scheduled publishing, imports, exports and cron jobs
Media uploads, image processing and document generation
Editor, moderation and approval workflows

Check application, PHP-FPM and web-server logs during testing. Test both uncached and cached responses, because an edge cache can conceal an error or keep an old response alive after deployment.

Make production deployment reversible

Agree on the release window, responsibilities, acceptance checks and rollback trigger before work starts. Record the database backup or snapshot, previous runtime setting, package lock file and deployable application version. After release, verify the important workflows in production, inspect queues and scheduled jobs, and monitor logs rather than waiting for users to report failures.

For owners and agency leads, the useful planning deliverable is a short decision record: current stack, recommended target, known blockers, remediation owners, test scope, deployment sequence and rollback method. It makes estimates comparable and prevents hosting, development and content teams from assuming somebody else owns the risky part.

Need someone to coordinate the moving parts?

Greg can turn an uncertain PHP or CMS upgrade into a staged technical plan, coordinate developers and hosting providers, and keep testing, deployment and rollback tied to business priorities. Talk with Greg about planning your CMS upgrade.

Related on GrN.dk

Need help with this kind of work?

Plan your CMS upgrade with Greg Get in touch with Greg.

Sources

Last modified

2026-08-11