{"id":267406,"date":"2026-08-27T08:56:39","date_gmt":"2026-08-27T08:56:39","guid":{"rendered":"https:\/\/ded9.com\/?p=267406"},"modified":"2026-08-27T09:20:03","modified_gmt":"2026-08-27T09:20:03","slug":"php-8-4-a-full-review-and-what-it-means-for-wordpress","status":"publish","type":"post","link":"https:\/\/ded9.com\/tr\/php-8-4-a-full-review-and-what-it-means-for-wordpress\/","title":{"rendered":"PHP 8.4: A Full Review and What It Means for WordPress"},"content":{"rendered":"

PHP 8.4 arrived on 21 November 2024. Nearly two years later, it has settled into the role most PHP<\/a> releases eventually take: not the newest branch, not the oldest supported one, but the version a large share of production traffic actually runs on. PHP 8.5 shipped a year behind it and is now the latest stable release, yet PHP\u00a08.4 remains the pragmatic default for most WordPress hosting because it has the longest track record among branches that are still fully patched.<\/p>\n

This review covers what 8.4 changed at the language level, what it changed in practice, and what happens when you point a real WordPress<\/a> site at it.<\/p>\n

\"What<\/p>\n

What PHP 8.4 actually added<\/h2>\n

Property hooks<\/h3>\n

The headline feature. Property hooks let a class define get and set behavior directly on a property, without writing a separate getter-and-setter pair.<\/p>\n

class Product {
\npublic string $slug {
\nget => strtolower(str_replace(' ', '-', $this->name));
\nset (string $value) => $this->slug = trim($value);
\n}
\n}<\/code><\/p>\n

This removes a great deal of boilerplate from model and value-object code. For WordPress specifically, it matters less than it does for Laravel or Symfony, because WordPress core is procedural at heart and most plugin code still leans on arrays and filters. Plugin authors building on modern object-oriented foundations will use it. Theme authors mostly will not notice.<\/p>\n

Asymmetric visibility<\/h3>\n

Related, and arguably more useful day to day. A property can now be readable publicly but writable only from inside the class:<\/p>\n

class Order {<\/code>
\npublic private(set) string $status = 'pending';<\/code>
\n}<\/code><\/p>\n

Before 8.4, this required a private property plus a public getter. Now it is one line, and the type system enforces it.<\/p>\n

Four new array functions<\/h3>\n

array_find()<\/code>, array_find_key()<\/code>, array_any()<\/code> and array_all()<\/code> fill gaps that have forced developers into awkward array_filter()<\/code> plus reset()<\/code> combinations for years. They read the way you would describe the operation out loud, and they short-circuit rather than walking the whole array.<\/p>\n

new<\/code> without parentheses<\/h3>\n

new Request()->getPath()<\/code> now works. Previously you needed (new Request())->getPath()<\/code>. A small change that removes a persistent readability annoyance.<\/p>\n

Lazy objects<\/h3>\n

Objects whose initialization is deferred until first access, exposed through ReflectionClass::newLazyGhost()<\/code> and newLazyProxy()<\/code>. This is infrastructure for dependency injection containers and ORMs rather than something most application code touches directly, but it is why frameworks running on 8.4 boot faster.<\/p>\n

A real HTML5 parser<\/h3>\n

The new \\Dom\\HTMLDocument<\/code> class parses HTML5 to spec. The old DOMDocument<\/code> was built for HTML 4 and mangled modern markup in ways that produced quiet, hard-to-trace bugs. Anything that manipulates post content, rewrites image tags, or processes block markup benefits here.<\/p>\n

Smaller additions<\/h3>\n

The BCMath object API brings arbitrary-precision arithmetic into an BcMath\\Number<\/code> object with operator overloading. PDO gained driver-specific subclasses such as Pdo\\Mysql<\/code> and Pdo\\Sqlite<\/code>. A #[\\Deprecated]<\/code> attribute lets userland code mark its own functions as deprecated. New multibyte string helpers (mb_trim()<\/code>, mb_ucfirst()<\/code>) close longstanding gaps. The JIT was rebuilt on a new intermediate representation framework, which mostly means lower memory use and easier maintenance rather than dramatic speed gains.<\/p>\n

The performance question<\/h2>\n

Here is the part most upgrade guides overstate. PHP 8.4 is not meaningfully faster than 8.3 for standard WordPress workloads. The large jumps happened at 7.0 and again at 8.0. Everything since has been incremental, and the JIT still does very little for typical WordPress request handling, because WordPress is dominated by database queries and I\/O rather than tight computational loops.<\/p>\n

If you are moving from PHP 7.4 to 8.4, expect a substantial improvement. If you are moving from 8.2 or 8.3, expect flat results with slightly better memory behavior. Upgrade for the security runway and the tooling, not for the benchmark.<\/p>\n

\"The<\/h2>\n

This is where WordPress sites get hurt, and one deprecation dominates everything else.<\/p>\n

Implicitly nullable parameter types are deprecated.<\/strong> Code written as function example(string $text = null)<\/code> now emits a deprecation notice on every call. The fix is trivial at the declaration site (?string $text = null<\/code>), but the pattern appears in an enormous volume of legacy PHP, including vendor libraries bundled inside plugins.<\/p>\n

Removed extensions.<\/strong> IMAP, OCI8, PDO_OCI, and pspell moved out of core to PECL. The IMAP removal is the one that catches WordPress sites, since a handful of mail-handling and ticketing plugins depend on it.<\/p>\n

Other deprecations.<\/strong> The E_STRICT<\/code> constant, several session INI directives, and _<\/code> as a class name. Low impact for most sites, but they will show up in logs.<\/p>\n

Where WordPress stands today<\/h2>\n

WordPress core has been clean on PHP 8.4 for some time. Core contributors resolved the implicit nullable issue during the 6.x cycle, and the project has since formalized its position.<\/p>\n

In May 2026, the core team retired the “beta support” label for PHP entirely and applied the change retroactively. WordPress 6.8 and later are now documented as fully supporting PHP 8.4, with no qualifiers attached. The team reasoned that the beta label had become counterproductive: it made hosts hesitant to offer newer PHP versions and gave plugin developers an excuse to delay testing.<\/p>\n

Two numbers are worth keeping straight. WordPress supports PHP 7.4 as an absolute minimum, but the minimum recommended<\/em> version is 8.3. Supported and recommended are different claims, and hosting sales pages routinely blur them.<\/p>\n

What breaks on real sites<\/h2>\n

Core being clean does not mean your site is clean. Failures on PHP 8.4 almost always originate in third-party code, and they cluster in predictable places.<\/p>\n

Abandoned plugins.<\/strong> Anything not updated in two years or more is the primary risk. Deprecation notices are the mild case. Fatal errors from removed functions are the serious ones.<\/p>\n

Bundled vendor libraries.<\/strong> A well-maintained plugin can still ship an outdated Composer dependency that has not been touched since 2019. These are invisible in the plugin’s changelog and only surface under load.<\/p>\n

Custom theme code.<\/strong> functions.php<\/code> Files accumulated over a decade are rarely audited. This is where implicitly nullable declarations hide in quantity.<\/p>\n

Deprecation notices breaking output.<\/strong> The most underrated failure mode. If WP_DEBUG_DISPLAY<\/code> is on in production, a deprecation notice printed before headers are sent will corrupt REST API JSON responses, break admin-ajax.php<\/code> calls, and produce “headers already sent” errors. The site looks broken in ways that have nothing obvious to do with PHP versions. Log deprecations to file, never to screen.<\/p>\n

\"Should<\/h2>\n

The support timeline makes this straightforward. PHP 8.2 reaches end of life on 31 December 2026. PHP 8.3 is already security-only and ends in December 2027. PHP 8.4 leaves active support at the end of 2026 but receives security patches through December 2028. PHP 8.5 runs until December 2029.<\/p>\n

If you are on 8.2, you have a hard deadline in a few months and should be planning now. If you are on 8.3, 8.4 is a lateral move that buys a year of extra runway for very little migration effort. If you are starting fresh on WordPress 6.9 or later, 8.5 is supported and gives the longest window, though 8.4 still has the broader plugin compatibility record.<\/p>\n

A sane upgrade process<\/h2>\n
    \n
  1. Clone to staging.<\/strong> Not a copy of the theme. The full stack, including the plugin set and a representative database.<\/li>\n
  2. Audit before switching.<\/strong> Run PHP_CodeSniffer with the PHPCompatibilityWP ruleset across wp-content<\/code>. Rector can automate most of the nullable-type fixes in code you own.<\/li>\n
  3. Check plugin maintenance status.<\/strong> Last-updated date and recent support threads tell you more than the “Tested up to” field.<\/li>\n
  4. Switch PHP on staging and log everything.<\/strong> Set WP_DEBUG<\/code> true, WP_DEBUG_LOG<\/code> true, WP_DEBUG_DISPLAY<\/code> false. Then exercise the site properly: checkout, forms, email, scheduled tasks, imports, the REST API, and the admin.<\/li>\n
  5. Confirm rollback works<\/strong> before touching production, then switch during low traffic and watch error logs for a full cron cycle.<\/li>\n<\/ol>\n

    Most WordPress sites running current core and maintained plugins move to PHP 8.4 without incident. The ones that break were carrying technical debt that a version bump simply made visible.<\/p>\n

    FAQ<\/h2>\n
    \n
    \n
    \n

    Is PHP 8.4 safe for WordPress?<\/h3>\n
    \n\n

    Yes. WordPress 6.8 and later officially support PHP 8.4 with no exceptions attached. Core compatibility is not the variable; your plugins, theme and custom code are.<\/p>\n\n<\/div>\n<\/div>\n

    \n

    Will PHP 8.4 make my site faster?<\/h3>\n
    \n\n

    Only if you are coming from PHP 7.x, where gains are significant. Moving from 8.2 or 8.3 produces roughly flat performance. Upgrade for the security support window instead.<\/p>\n\n<\/div>\n<\/div>\n

    \n

    Should I skip 8.4 and go straight to PHP 8.5?<\/h3>\n
    \n\n

    If your site runs WordPress 6.9 or later and your plugins test clean, 8.5 gives you until December 2029. PHP 8.4 remains the safer choice if your stack includes older plugins or bundled dependencies.<\/p>\n\n<\/div>\n<\/div>\n<\/div>\n<\/div><\/div>\n","protected":false},"excerpt":{"rendered":"

    PHP 8.4 arrived on 21 November 2024. Nearly two years later, it has settled into the role most PHP releases eventually take: not the newest branch, not the oldest supported one, but the version a large share of production traffic actually runs on. PHP 8.5 shipped a year behind it and is now the latest […]<\/p>\n","protected":false},"author":9,"featured_media":267407,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1088],"tags":[1074,841,929],"class_list":["post-267406","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-php","tag-html","tag-php","tag-wordpress"],"acf":[],"amp_enabled":true,"_links":{"self":[{"href":"https:\/\/ded9.com\/tr\/wp-json\/wp\/v2\/posts\/267406","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/ded9.com\/tr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/ded9.com\/tr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/ded9.com\/tr\/wp-json\/wp\/v2\/users\/9"}],"replies":[{"embeddable":true,"href":"https:\/\/ded9.com\/tr\/wp-json\/wp\/v2\/comments?post=267406"}],"version-history":[{"count":5,"href":"https:\/\/ded9.com\/tr\/wp-json\/wp\/v2\/posts\/267406\/revisions"}],"predecessor-version":[{"id":267423,"href":"https:\/\/ded9.com\/tr\/wp-json\/wp\/v2\/posts\/267406\/revisions\/267423"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/ded9.com\/tr\/wp-json\/wp\/v2\/media\/267407"}],"wp:attachment":[{"href":"https:\/\/ded9.com\/tr\/wp-json\/wp\/v2\/media?parent=267406"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/ded9.com\/tr\/wp-json\/wp\/v2\/categories?post=267406"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/ded9.com\/tr\/wp-json\/wp\/v2\/tags?post=267406"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}