PHP 8.3 for WordPress Developers: Features You Should Use Today

PHP 8.3 was released in November 2023 and as of 2026 it is the version WordPress developers should be targeting for new projects. The performance gains from PHP 8.x are well documented - PHP 8.3 is roughly twice as fast as PHP 7.4 on WordPress performance on older PHP versions benchmarks. But the language features are equally important and most developers have not explored them fully.

This guide covers the PHP 8.3 features that matter most for WordPress plugin and theme development: typed class constants, the new json_validate() function, Randomizer additions, readonly property amendments, deprecations to watch, and practical compatibility guidance. Code examples are real-world WordPress patterns, not toy examples.

PHP 8.3 Compatibility with WordPress

WordPress core officially supports PHP 8.3 as of WordPress 6.4. Running PHP 8.3 with WordPress 6.4 or later is stable. The main compatibility concerns are third-party plugins and themes - specifically those using deprecated dynamic property creation or passing null to non-nullable parameters.

Check your plugin’s PHP compatibility before upgrading production servers. The PHPCompatibilityWP standard for PHP_CodeSniffer is the fastest way to scan for issues:

Running this on your plugin before deploying PHP 8.3 to production will catch most compatibility issues before they cause fatal errors on live sites.

Typed Class Constants

Before PHP 8.3, class constants could not have explicit type declarations. You could not enforce that a constant always holds an integer or a string. PHP 8.3 adds full type support for constants, including intersection types and union types.

For WordPress plugin development, typed constants are especially useful in settings classes and configuration objects where incorrect types cause subtle bugs that are hard to trace:

Typed constants enforce correctness at definition time. If you try to assign a value that does not match the declared type in a subclass, PHP throws a fatal error immediately. This catches configuration mistakes during development, not production.

Typed class constants bring the same benefits to constants that typed properties brought in PHP 7.4 - explicit contracts enforced by the engine, not just by documentation.

json_validate(): Validate JSON Without Decoding

Before PHP 8.3, validating JSON required calling json_decode() and then checking json_last_error(). This decoded the entire JSON string into memory just to check if it was valid - wasteful for large payloads where you only needed to know if the structure was correct before processing.

PHP 8.3 adds json_validate() which checks JSON validity without decoding:

In WordPress, this is useful when receiving webhook payloads, REST API requests, or stored JSON option values. You can validate the structure before attempting to decode and process - and get a meaningful error if validation fails, via json_last_error_msg() or by passing the JSON to json_decode() only after json_validate() confirms it is well-formed.

Randomizer Additions

PHP 8.2 introduced the Random\Randomizer class as a modern replacement for rand(), mt_rand(), and shuffle(). PHP 8.3 adds two important methods to Randomizer: getBytesFromString() and getFloat() / nextFloat().

getBytesFromString()

This method generates a string of random bytes drawn from a specific character set. For WordPress developers generating tokens, slugs, or temporary passwords, this replaces the common pattern of generating a random string via substr(str_shuffle(...)):

The Randomizer class uses a cryptographically secure random source by default (Random\Engine\Secure). For non-security-sensitive use cases like generating preview slugs or test data, you can pass a seeded engine for reproducible output in tests.

getFloat() and nextFloat()

getFloat() generates a random float between a min and max value with configurable inclusivity of the bounds. nextFloat() returns a float in the [0.0, 1.0) range. These are useful for probabilistic feature flags, A/B test assignment, or any feature that needs controlled random distribution.

Readonly Properties: Amendments in PHP 8.3

PHP 8.1 introduced readonly properties and PHP 8.2 added readonly classes. PHP 8.3 makes a smaller but practically important change: readonly properties can now be reinitialized during cloning via the __clone() magic method.

Before this change, cloning an object with readonly properties was problematic - the clone had the same readonly property values and you could not modify them. This made immutable value objects difficult to use in patterns that require creating modified copies:

This pattern - create a new instance as a modified copy of an existing one - is common in WordPress settings objects, query builder classes, and DTO patterns used in REST API handlers. The PHP 8.3 change makes these patterns work correctly with readonly properties without resorting to reflection hacks.

New #[Override] Attribute

PHP 8.3 adds the #[Override] attribute, which explicitly marks that a method is intended to override a parent class method or interface method. If the parent method does not exist or is renamed, PHP throws a fatal error.

This is directly useful for WordPress plugin development where you extend WP_Widget, WP_REST_Controller, Walker, or other core base classes. If WordPress renames a method in a future release, #[Override] catches the breakage immediately:

Without #[Override], a typo in an overriding method name silently creates a new method instead of overriding the intended one. The bug only surfaces at runtime when the parent class method runs instead of your custom one - often in edge cases that are hard to reproduce.

Deprecations in PHP 8.3 That Affect WordPress Plugins

PHP 8.3 deprecates several patterns that are still common in WordPress plugin codebases. These generate deprecation notices and will become fatal errors in PHP 9.0.

The dynamic properties deprecation is the most impactful. It was added in PHP 8.2 as a deprecation and plugins that have not addressed it will generate notice floods on PHP 8.3. The fix is either to declare all properties explicitly or to add the #[AllowDynamicProperties] attribute to classes that need dynamic properties for legitimate reasons (like generic data containers).

PHP 8.3 Performance: What It Means for WordPress

PHP 8.0 introduced the JIT compiler and PHP 8.x versions have continued improving performance. For WordPress specifically, PHP 8.3 improvements include:

• Faster class constant resolution - relevant for plugin architecture with many constants
• Improved opcache behavior for large codebases
• Reduced memory allocation in some array operations
• Fiber performance improvements - useful for async patterns in WordPress CLI and WordPress automation and AI tooling

On a standard WordPress site with 20-30 active plugins, moving from PHP 7.4 to PHP 8.3 typically reduces server response time by 30-50%. The gains are most visible on sites with heavy database query loads and complex plugin stacks.

Upgrading to PHP 8.3: Practical Steps

1. Run PHPCompatibilityWP scan on your plugin’s codebase
2. Fix dynamic property issues - declare all properties or add #[AllowDynamicProperties]
3. Update null parameter patterns - PHP 8.x no longer silently converts null to the expected type in function calls
4. Test on a staging site with PHP 8.3 before updating production
5. Check your hosting control panel - most managed WordPress hosts let you select PHP version per site
6. Monitor error logs for the first 48 hours after switching

Summary: PHP 8.3 Features Worth Adopting Now

PHP 8.3 is not a revolutionary release but its additions are solidly practical for WordPress development. Typed class constants eliminate a whole class of configuration bugs. json_validate() reduces unnecessary memory allocation in data-handling code. The Randomizer improvements make generating secure tokens and test data cleaner. The readonly property cloning fix unblocks clean immutable object patterns. And #[Override] adds a safety net for extending WordPress core classes.

Run the compatibility scan, fix the deprecations, and target PHP 8.3 for all new WordPress plugin development. The performance gains alone justify the upgrade, and the new language features will improve the maintainability of your code over time.

PHP Version Timeline: When to Upgrade Production

PHP versions follow a predictable support lifecycle. Each version gets two years of active support (bug fixes and security patches) followed by one year of security-only support. After that, the version is end-of-life and receives no patches.

For WordPress sites currently on PHP 7.4 or 8.0, the upgrade is urgent - you are running an unpatched PHP version with known security vulnerabilities. Move to PHP 8.2 minimum, PHP 8.3 preferred. The WordPress Hosting recommendations page recommends PHP 8.0 as a minimum, but this is a floor, not a target.

Fibers in PHP 8.1+ and Their Relevance to WordPress CLI

PHP Fibers (introduced in 8.1, improved in 8.3) are a mechanism for lightweight concurrency - the ability to pause and resume execution within a single thread. WordPress core does not use Fibers in standard web requests, but WordPress CLI (wp-cli) and background processing contexts can benefit from them.

WP-CLI commands that process large datasets - importing products, processing image attachments, syncing user data - traditionally run in a simple loop. With Fibers, you can implement cooperative multitasking where work is interleaved with other tasks in the same process. Third-party async libraries like ReactPHP and Revolt can take advantage of PHP 8.3’s improved Fiber performance.

For standard WordPress plugin development, Fibers are not yet a day-to-day concern. But knowing they exist matters for developers building WP-CLI commands, batch processing tools, or WordPress-based APIs that need to handle concurrent requests efficiently.

Testing PHP 8.3 Compatibility Locally Before Deploying

The safest way to test PHP 8.3 compatibility is a local environment with both PHP versions available. Local by Flywheel and Lando both support switching PHP versions per site. Docker-based setups (10up’s wp-local-docker, Devilbox) make it trivial to spin up a copy of a site under PHP 8.3 without touching production.

• Local by Flywheel: Right-click on a site and change PHP version. Requires Local Pro for multiple PHP versions simultaneously.
• Lando: Update the .lando.yml php version key and run lando rebuild. Fast and clean.
• Herd (macOS): Laravel Herd supports multiple PHP versions side by side. Specify per-site with a .php-version file in the project root.
• WordPress Playground: The browser-based WordPress Playground now supports different PHP versions. Useful for quick compatibility checks without any local setup.

When testing, enable error reporting to see all deprecation notices: set WP_DEBUG and WP_DEBUG_LOG to true in wp-config.php, then review the debug.log file after running through your plugin’s primary user flows. Every E_DEPRECATED notice is a future fatal error in PHP 9.0.

PHP 8.3 on Major WordPress Hosting Platforms

Switching to PHP 8.3 is a hosting control panel change, not a code deployment. All major managed WordPress hosts support PHP 8.3. Here is how to find the setting on each major platform:

• Kinsta: Site Dashboard - Tools - PHP Engine. Dropdown selector per site. Takes effect immediately.
• WP Engine: User Portal - Sites - your site - PHP version. Available under the Overview tab.
• SiteGround: Site Tools - Devs - PHP Manager. Per-domain PHP version selection.
• Cloudways: Server management - Settings and Packages - PHP version. Per-server selection (not per site on shared servers).
• Flywheel / Local: Site overview settings in the Local desktop app. Per-site PHP version.
• Plesk hosts: PHP settings in Domains - your domain - PHP settings. Panel varies by host customization.
• cPanel hosts: MultiPHP Manager under the Software section. Per-domain selection.

After changing the PHP version, immediately check the site for errors. Refresh the homepage, load a few post pages, and check the wp-admin dashboard. Then review the PHP error log (typically at wp-content/debug.log if WP_DEBUG_LOG is enabled) for any deprecation notices or warnings that need addressing before leaving PHP 8.3 in place permanently.

PHP 8.3 Named Arguments in WordPress Plugin Development

Named arguments (introduced in PHP 8.0, available in 8.3) let you pass function arguments by parameter name rather than position. For WordPress plugin development, this improves readability particularly with add_action() and add_filter() calls that have multiple arguments:

Instead of memorizing that the fourth argument to add_filter() is the number of accepted arguments, you can write: add_filter(hook: ‘the_content’, callback: ‘my_function’, priority: 10, accepted_args: 2). Named arguments also let you skip optional parameters, passing only the ones you care about without filling in defaults.

PHP 8.0 introduced named arguments and PHP 8.3 has no breaking changes to them. If you are already on PHP 8.0 or 8.1, your existing named argument usage continues to work on 8.3. The caution: named arguments are tied to parameter names in the PHP standard library. If a built-in function’s parameter is renamed (rare but has happened in PHP 8.x), code using that parameter by name breaks. Use named arguments for your own functions and be conservative with PHP built-ins.