CMS Upgrades in 2026: Choosing PHP for WordPress and Drupal

Illustrated infographic summarizing: 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

Seneste artikler

Få en ugentlig marketingrapport fra GA4 og Google Ads med kontrollerede beregninger, tydelige dataforbehold og et kort AI-udkast, der hjælper jer på mandagsmødet.

Brug AI til webshoppens alt-tekster med en overskuelig pilot: kortlæg billederne, få danske forslag, og kontrollér resultatet i WordPress og WooCommerce.

AI-baseret ticketanalyse kan afsløre gentagne klager, produktfejl og huller i dokumentationen – uden at virksomheden behøver endnu en chatbot.

OpenSSH 10 fjerner DSA og advarer om nøgleudveksling, der ikke er post-kvantesikker. Her får du en metode til at afgrænse SFTP-oprydningen uden at svække alle SSH-forbindelser.

Botforespørgsler overstiger nu menneskelig webtrafik. Lær at auditere AI-crawlere, fastsætte regler på stiniveau, håndhæve robots.txt og måle det forretningsmæssige afkast.

Cloudflares Tunnel-opdateringer fra 2026 forbedrer kortlægning, overvågning af replikaer, logstreaming og overdragelse – men synliggør samtidig svagt ejerskab og mangelfuld praksis for failover og logging.

Sådan bruger du AI til mødenoter og opfølgning, mens faste regler beskytter CRM-data, kundematch og pipeline mod fejl og forhastede ændringer.

Drupal 10 når end of life den 9. december 2026. Brug denne praktiske kortlægning til at afgrænse arbejdet med Drupal 11-parathed, Composer-efterslæb, moduler og custom code.

Apache 2.4.67 tydeliggjorde risikoen ved overtagne reverse proxies. Læs, hvordan du opgraderer til 2.4.68, gennemgår HTTP/2, AJP og .htaccess og tester ændringerne sikkert.

WooCommerce-blokke er standarden, men ikke alle webshops er klar. Brug denne praktiske gennemgang, testplan og rollback-procedure til at beskytte omsætningen i checkout.