ThemesCorners
Blog
9 min readby ThemesCorners

PHP 8.4 Features Every WordPress Developer Should Use

Property hooks, asymmetric visibility, and the new array helpers — plus how each one cleans up real WordPress code.

PHP 8.4 has been the most-used PHP version on managed WordPress hosts since late 2025, and 8.5 lands in November 2026. If your composer.json still pins "php": ">=7.4", you are leaving real readability and performance on the table. This post walks through the four 8.4 features that actually change how I write WordPress code day to day.

1. Property hooks (no more boilerplate getters / setters)

In PHP 8.3 you wrote this constantly inside custom post-type classes:

class Product {
    private string $name;
    public function getName(): string { return $this->name; }
    public function setName(string $value): void {
        $this->name = trim($value);
    }
}

In PHP 8.4 it collapses to:

class Product {
    public string $name {
        get => $this->name;
        set(string $value) => trim($value);
    }
}

The hook runs whenever the property is read or written, so you can normalise values (the trim() above), trigger do_action() calls, or fetch from a meta table — without callers ever knowing it's not a plain property.

Why this matters for WordPress: custom post-type and block-attribute objects almost always need normalisation. Property hooks let you drop a whole layer of WP_*_Repository::get_x() helpers.

2. Asymmetric visibility

Closely related, you can now restrict who can write a property without restricting who can read it:

class Order {
    public private(set) string $status = 'pending';
    public function pay(): void { $this->status = 'paid'; }
}

Order::$status is readable from anywhere, writable only from inside the class. That single keyword replaces a dozen getStatus() / private-setter combos.

3. New array helpers — array_find and friends

PHP 8.4 added array_find, array_find_key, array_any, and array_all. The first two are the ones I use weekly:

$adminUser = array_find(
    get_users(['role' => 'administrator']),
    fn (\WP_User $u) => str_ends_with($u->user_email, '@example.com')
);

Before 8.4 this was a foreach with an early return, or a brittle array_filter(...)[0] ?? null. Now it's one line and reads like English.

4. #[\Deprecated] attribute

Marking a helper as deprecated finally has language-level support:

#[\Deprecated(message: 'Use Theme::getPalette() instead', since: '2.0')]
function themescorners_get_colors(): array { /* ... */ }

This emits a real E_USER_DEPRECATED notice, shows up in IDEs, and works with wp_debug_log(). Use it whenever you change a public API — your downstream theme users will thank you.

Migration check list

If you're a theme or plugin author bumping your minimum to PHP 8.4:

  1. Update composer.json: "php": "^8.4".
  2. Update the Requires PHP header in your main style.css / plugin file.
  3. Run composer require --dev rector/rector and apply the PHP 8.4 set — it will rewrite a lot of the above automatically.
  4. Run your PHPUnit suite against 8.4 in CI before shipping; PHPUnit 11 added matching support.
  5. Bump "Tested up to" to the current WordPress release. WordPress 6.8 (April 2026) is the safe target as of writing.

A note on hosting

Almost every managed WordPress host (Kinsta, WP Engine, Pressable, Cloudways, SiteGround) now offers PHP 8.4 and lets you switch with one click. If your host is still on 8.1 or 8.2 in 2026 — switch hosts. The performance difference between 8.1 and 8.4 on real-world WordPress workloads is consistently 8–12% in our benchmarks.

Related articles