PHP 8 compatibility

Not every PHP 8 version is supported

PHP 8.0 stopped getting security fixes on 26 Nov 2023. PHP 8.1 stopped getting security fixes on 31 Dec 2025. So “PHP 8 compatible” on its own is not the goal. The goal is a currently supported version, and the table on this page shows which ones those are today.

What PHP 8.0 changed, in plain words

PHP 8 is stricter. Older versions often carried on when the code was slightly wrong, showing a small warning or nothing at all. PHP 8 stops instead. The changes we fix most often:

• Many old warnings became fatal errors (errors that stop the page). That is how “it used to just show a warning” becomes a blank page
• Built in functions given the wrong kind of value now stop with an error (a TypeError) instead of a warning
• Several older functions are gone completely: create_function, each, money_format and get_magic_quotes_gpc
• Code written in the PHP 4 style (a setup function with the same name as its class) no longer runs as setup, so objects quietly miss it
• Comparing a number with text changed: 0 == "abc" used to be true and is now false. That can change how logins, searches or filters behave without any error at all
• The word “match” became part of the language (a reserved word), so any custom function or class called match breaks
• Names written without quotes where text was meant (bare words) used to be guessed and now stop the page

What PHP 8.1 and 8.2 added, and what it means for plugins

The later PHP 8 versions mostly add warnings (deprecations) about things that will be removed in future. They don’t break the site today, but older plugins can fill the error log with them, which hides the warnings that matter and can slow a site down.

• PHP 8.1: passing an empty value (null) to many built in functions, such as strlen, str_replace and trim
• PHP 8.2: adding properties to an object on the fly (dynamic properties), which is very common in older plugins and themes
• PHP 8.2: the utf8_encode and utf8_decode functions, and writing "${var}" inside text

On WordPress and similar sites most of the code comes from plugins and themes. Ones that are still maintained usually have a PHP 8 version. Abandoned ones, closed or not updated for years, will never get a fix and need replacing or patching. Encoded files (ionCube) also need a loader that supports the new PHP version, or they stop working entirely.

How we test on a copy

We take a full backup, then build a private staging copy of your site on a currently supported PHP 8 version. Your live site keeps running untouched. We scan the code with a checker for known problems (PHPCompatibility), then turn on error logging and work through every error and deprecation notice.

Then we test the site the way your customers and staff use it, because a home page can look fine while a form or payment step is broken:

• Contact forms and the emails they send
• Checkout and payments, logins and member areas
• Search, image uploads and the admin area
• Scheduled tasks (cron jobs), which on shared hosting can run on a different PHP version from the site

We clear caches while testing, because a page cache or PHP’s own cache (OPcache) can hide errors or keep showing old ones. Key pages are compared side by side with the live site.

Going live and keeping the site the same

The switch happens at a quiet time with a rollback plan: the host’s PHP setting can be switched back quickly if something unexpected appears. We watch the error logs for a few days afterwards, because some code only runs weekly or monthly.

Compatibility work is about the code underneath, not a redesign. Your design, content and hosting stay as they are wherever technically feasible. If something cannot sensibly be made compatible, we tell you before any work starts.

PHP versions and their support dates

Bug fixes come first; after that a version gets security fixes only, then nothing at all.

Dates from php.net. Your host may offer only some of these versions.