WordPress PHP upgrades

Why older WordPress sites need care

Old versions of WordPress itself (the core) don’t run cleanly on PHP 8, so core usually has to be updated first. On a very old site that sometimes means updating in steps rather than one jump, and each step runs its own database update.

Updating core brings its own changes. WordPress 5.0 introduced the block editor. WordPress 5.5 to 5.7 updated jQuery (code that many themes and plugins use for sliders, menus and popups) and phased out the compatibility helper older code relied on (jQuery Migrate). Many older themes and plugins broke at that point, so a site that skipped those versions meets all of it at once.

Plugins and themes that hold a site back

• Abandoned plugins: closed on wordpress.org or not updated for years. No PHP 8 fix will ever come, so they need replacing or patching
• Premium plugins and themes with expired licences can’t update from the dashboard until the licence is renewed or the files are obtained another way
• Plugins bundled inside a theme, such as old page builders and sliders, are often years out of date even when the theme says it is current
• “Nulled” copies (paid plugins downloaded free from unofficial sites) are a security risk and should be replaced with genuine ones
• Customisations in the theme’s functions file (functions.php), child themes, and WooCommerce template overrides that no longer match WooCommerce’s current templates
• Encoded files (ionCube) need a loader that supports the new PHP version, or they stop working entirely

The code changes that bite most

In older plugins and themes, the PHP changes we fix most often are:

• Functions removed in PHP 8 (create_function, each), still found in older plugins
• Warnings that PHP 8 turned into fatal errors, which is how a small notice becomes a blank page
• Comparisons between numbers and text that now give a different answer (0 == "abc" is now false) without any error
• Notices in PHP 8.1 and 8.2 about empty values passed to functions and dynamic properties, which can flood the error log

How we upgrade a WordPress site

• Take a full backup of the files and the database
• Build a private staging copy on the target PHP version, while the live site keeps running untouched
• Scan the code with a checker for known problems (PHPCompatibility), then turn on error logging and work through every error and deprecation notice
• Update core, plugins and themes in a sensible order, and replace abandoned plugins
• Test forms and the emails they send, checkout and payments, logins and member areas, search, image uploads, the admin area and scheduled tasks, and compare key pages side by side with live
• Go live at a quiet time with a rollback plan, since the host’s PHP setting can be switched back quickly if something unexpected appears

Tips and gotchas

• Shops keep taking orders while we work. Never copy the staging database over a live WooCommerce site, or recent orders and customers are lost. We carry the code and settings across instead
• Copying a site to a staging address with a plain find and replace of the domain in the database corrupts WordPress’s stored settings (serialised data). Use a tool that understands that format
• Server settings often don’t carry over to the new PHP version: memory limit, upload size, the timezone (it often defaults to UTC, so dates and times shift) and max_input_vars, which makes long menus and big forms silently lose items
• Some hosts turn off allow_url_fopen on newer PHP versions, which silently breaks code that fetches other web addresses
• Scheduled tasks (cron jobs) on shared hosting often run on a different PHP version from the website, so they can break separately
• Caches (page cache, object cache and OPcache) can hide new errors or keep showing old ones. Clear them while testing
• A site can look fine on the home page while a form, a payment step or an admin screen is broken. Test the paths people take, not just the pages
• Check the error logs for a few days after go live. Some code only runs weekly or monthly