PHP 8.4: New Features, Changes, and a Safe Upgrade Checklist

PHP 8.4 is a major PHP release with language features for cleaner code, stronger access control, and modern APIs. An upgrade can benefit an application, but it should never be treated as safe without compatibility testing.

Important new features

Property hooks

Property hooks let developers define get and set logic directly on a property, reducing repetitive getter and setter methods.

class User {
    public string $name {
        set => trim($value);
    }
}

Asymmetric property visibility

A property can have different read and write visibility. An API may expose a value publicly while restricting who can change it.

class Order {
    public private(set) string $status = 'pending';
}

The #[Deprecated] attribute

Developers can mark functions, methods, and constants as deprecated in a standard way, allowing IDEs and analysis tools to provide useful warnings.

New array functions

array_find(), array_find_key(), array_any(), and array_all() cover common search and condition patterns without extra loops.

Lazy objects and API improvements

PHP 8.4 introduces an official lazy-object API, primarily useful to frameworks and dependency injection systems. It also includes DOM improvements with HTML5 support, an object API for BCMath, driver-specific PDO subclasses, and simplified method calls after new.

Changes for developers

Existing applications do not need to adopt the new syntax immediately. The features can be introduced gradually for clearer domain models and stronger static analysis. Confirm that production runs PHP 8.4 and that the codebase does not need to support older PHP versions before using them.

Deprecations and compatibility

PHP 8.4 emits new deprecation notices. Implicitly nullable parameters should be declared explicitly with ?Type or Type|null. Uses such as E_STRICT, mysqli_ping(), and trigger_error(..., E_USER_ERROR) are also deprecated. A deprecation is not always an immediate fatal error, but identifies code that should be updated before a future major release.

Before upgrading

• Record the current PHP version, extensions, INI settings, and scheduled jobs.
• Create a complete file and database backup and verify restore access.
• Build staging that closely matches production.
• Update the application, WordPress core, WooCommerce, plugins, and themes to supported versions first.
• Review vendor requirements and Composer dependencies.
• Document the previous PHP version and rollback process.

WordPress and WooCommerce

WordPress core compatibility does not guarantee that every plugin or theme is compatible. For WooCommerce, test the catalogue, cart, checkout, payment callbacks, emails, scheduled actions, and integrations. Check vendor compatibility statements and do not rely only on the homepage loading.

Testing on staging

1. Capture a baseline before the change.
2. Change PHP only on staging.
3. Test frontend, admin, login, forms, uploads, cron, and APIs.
4. Enable appropriate error logging and inspect fatal errors, warnings, and deprecations.
5. Test critical business flows and compare performance and TTFB.
6. Deploy to production only after successful testing and during a controlled maintenance window.

Rollback

If errors occur, restore the previous PHP version and use the verified backup if code or data changed. Clear the appropriate caches and recheck the frontend, admin, checkout, and logs.