PHP 8.3 compatibility checker for WordPress: check before you leave PHP 8.2
Short answer
For a site on PHP 8.2, a PHP 8.3 check looks for four changes, and all four only add deprecation notices: get_class() without arguments, assert_options(), the ASSERT_* and MT_RAND_PHP constants, and built-in methods overridden without the return type PHP 8.3 expects. What can stop code on PHP 8.3 depends on values while the site runs, which no code check sees, so watch the error log after switching. From PHP 7.4, 8.0 or 8.1 the check must also cover every version in between. The free CompatNav plugin does both, on your own server.
Why PHP 8.3, and why now
PHP 8.2 gets security fixes until 31 December 2026; PHP 8.3 until 31 December 2027 (php.net). wordpress.org says: “To run WordPress, it’s recommended your host supports: PHP version 8.3 or greater.” (wordpress.org) So 8.3 is the first candidate for a site leaving 8.2 (PHP 8.2’s end of life).
What a PHP 8.3 checker must find
CompatNav runs 4 checks for PHP 8.3, each one a change from php.net’s list of PHP 8.3 deprecations:
| In the code | On PHP 8.3 |
|---|---|
get_class() or get_parent_class() without arguments | Deprecation notice |
assert_options() | Deprecation notice |
The ASSERT_* constants and MT_RAND_PHP | Deprecation notice |
| Built-in methods overridden without the return type PHP 8.3 expects | Deprecation notice |
None of them stops a page. A typical one, in a class that asks for its own name the old way:
example.php
<?php
class Invoice {
public function describe(): string {
return 'Created by ' . get_class();
}
}
echo (new Invoice())->describe(), "\n";
Created by InvoiceDeprecated: Calling get_class() without arguments is deprecated in /var/www/html/example.php on line 4
Created by InvoiceThe fix is in “Calling get_class() without arguments is deprecated”, and every PHP 8.3 change in plain words in WordPress and PHP 8.3.
What only your error log shows
Three PHP 8.3 changes depend on the data a site handles, so no check that reads code can tell whether they will happen:
DateTime::modify()with a date it can’t read now throws an exception, which stops the page unless the plugin catches it. Before, it gave a warning and returnedfalse.- A list that starts at a negative index continues from it, instead of jumping to 0.
++on an empty or non-alphanumeric string adds a deprecation notice.
All three are explained, with tested examples, in WordPress and PHP 8.3. After switching, keep the error log on for a week (the WordPress debug log).
Coming from an older version
The check must cover every version between yours and 8.3, because each brought its own changes. CompatNav compares the PHP version your site runs today with the one you choose and reports only what changes between the two:
| Your site runs | Checks for a move to 8.3 | Of which can stop code |
|---|---|---|
| PHP 8.2 | 4 | none |
| PHP 8.1 | 9 | none |
| PHP 8.0 | 17 | 3 |
| PHP 7.4 | 36 | 14 |
Whatever the version, it also reports a file that PHP 8.3 can no longer read at all. The PHP 8.0 and 8.1 changes that stop code are in moving from PHP 7.4 to PHP 8 and WordPress and PHP 8.1.
Run the check
- Install CompatNav: Plugins → Add New Plugin, search for CompatNav, install and activate it. It’s free, from wordpress.org.
- Open Tools → CompatNav, and next to Check readiness for, choose PHP 8.3.
- Start the scan, then read the verdict: “Safe to upgrade”, or “Not ready yet” with what to do first.
- Try 8.4 and 8.5 as well. If they come out as clean, you can skip a version and keep security fixes one or two years longer.
The check runs on your own server and only reads files; no code, file names or results are sent anywhere. Getting started shows each screen.
Key takeaways
- PHP 8.2’s security fixes end on 31 December 2026; 8.3 gets them until 31 December 2027, and wordpress.org recommends 8.3 or greater.
- From PHP 8.2, CompatNav runs 4 checks for PHP 8.3, all of them for deprecation notices.
- From PHP 7.4, the checks for 8.0 to 8.3 all apply: 36, of which 14 find code that stops.
- What can stop code on 8.3 depends on values, such as a date
DateTime::modify()can’t read: only the error log shows it. - If 8.3 is clean, check 8.4 and 8.5 too: they get security fixes longer.
Frequently asked questions
Is PHP 8.3 a big change from 8.2?
For plugin code, usually a small one: of CompatNav’s 58 checks, four are for PHP 8.3, and all four find deprecation notices, which don’t stop a page. The bigger jumps come from older versions: 8.0 removed functions, and 8.1 made some code a fatal error.
Should I go to 8.3 or straight to 8.4 or 8.5?
Check each one: it’s one scan each. Take the newest version your plugins, theme and host are ready for: 8.4 gets security fixes a year longer than 8.3, 8.5 two years longer.
Does WordPress itself support PHP 8.3?
Yes. The WordPress core team lists WordPress 6.4 and later as compatible with PHP 8.3, and wordpress.org recommends PHP 8.3 or greater.
Check your own site before you upgrade
CompatNav is a free WordPress plugin. It reads the code of your plugins and themes on your own server and tells you, in plain words, what will break and what will only show notices on the PHP version you choose. It never changes your code. It can’t see problems that only appear while code runs with real data, so a quick check of your site after the upgrade still matters.
Sources
- php.net: Deprecated features in PHP 8.3.x
- php.net: Supported Versions
- wordpress.org: Requirements
- wordpress.org: CompatNav – PHP Upgrade Checker
About the code examples: each output is the real output of the code shown, run with the official PHP builds, without a php.ini, with all errors reported and displayed. Only the file path was replaced by a neutral server path.