A PHP upgrade changes nothing you can see, which is why it is so easy to underestimate. PHP is the language WordPress and Drupal are written in, and every plugin, module, theme, and custom feature on your site runs on it. When the version changes, all of that code runs on the new version at once. Most of it carries on as before. The parts that do not tend to be the old plugin nobody remembers installing, or the custom feature written years ago, and they fail in front of visitors unless someone tests first.
Why it cannot wait
| PHP version | Security fixes until |
|---|---|
| 8.1 | Ended December 31, 2025 |
| 8.2 | December 31, 2026 |
| 8.3 | December 31, 2027 |
| 8.4 | December 31, 2028 |
| 8.5 | December 31, 2029 |
After its end date, a PHP version gets no fixes for newly found security flaws, which is a finding in most security audits. A site on PHP 8.2 has until the end of 2026.
What your CMS needs
- WordPress recommends PHP 8.3 or newer. WordPress core is fully compatible with PHP 8.3, with beta support for 8.4 and 8.5; your plugins and theme decide how far you can go.
- Drupal 11 requires PHP 8.3 or newer. Drupal 10 sites can move to 8.3 before upgrading to Drupal 11; see the Drupal 11 upgrade checklist.
- Cascade publishes static pages, so PHP matters only if your published site includes PHP scripts or forms handled on your web server.
Find your current version
In WordPress, go to Tools, Site Health, Info, and open the Server section. In Drupal, go to Reports, Status report. Both also warn when the version is out of date. If you see different versions in different places, such as a hosting dashboard and the CMS, report both: the command line and the website can run different versions.
What usually breaks
- Abandoned plugins, modules, and themes that have not been updated in years
- Custom code that uses functions newer PHP versions removed or changed, often in a theme's functions file or a small site-specific plugin or module
- Old copies of libraries bundled inside a plugin or theme
- New warnings that fill error logs, or, on a misconfigured site, appear on the page itself
The upgrade checklist
- Inventory. List every plugin or module and theme, with its last update date. Anything not updated in two years needs a closer look.
- Check compatibility. Look at each one's listed PHP support and changelog. Remove what you no longer use rather than testing it.
- Scan custom code with a compatibility checker such as PHPCompatibility for PHP_CodeSniffer, which reports code that will not run on the target version.
- Test on a copy running the new PHP version, with error logging on: browse key pages, submit forms, run search, sign in, edit and publish, and run scheduled jobs.
- Read the error log after testing. Warnings today often become errors in the next version.
- Schedule the switch for a quiet time, with a tested way back to the previous version.
- Watch the site and logs for a day or two afterwards.
Work back from the deadline
For a site on PHP 8.2, a realistic plan for the December 31 deadline is: inventory and compatibility checks in October, testing and fixes in November, and the production switch in early December, ahead of year-end change freezes and holiday staffing. A plugin that needs replacing can take weeks on its own, so the inventory is the step not to delay.
One caution: the WordPress plugin directory shows the minimum PHP version a plugin needs, not the newest one it has been tested on. A plugin's changelog and support forum are better guides to whether it runs on PHP 8.3 or 8.4.
Skip a version?
If everything you run supports it, moving straight to the newest version your CMS supports fully gives you the longest time before the next upgrade. For most WordPress and Drupal sites in late 2026, that is PHP 8.3 now, with 8.4 once your plugins and modules confirm support.
How eWay handles PHP upgrades
On sites eWay manages, PHP, database, and operating system versions are moved in step with what the CMS supports and validated in a test environment first. Plugins and modules are tracked for compatibility, custom code is reviewed, and every production change has a tested rollback, so a PHP upgrade is a scheduled change rather than a surprise.
What to include in a support ticket
- The site and its current PHP version
- Any custom plugins, modules, or integrations you know of
- Dates to avoid, and who will test
eWay customers can open a ticket in the support portal or email support@ewaycorp.com. Related reading: keeping servers patched and updating WordPress and Drupal safely.
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article