Mike Lopez

Development

PHP 8.5 for WordPress Developers: Features Worth Using

By Published

PHP 8.5 for WordPress Developers: Features Worth Using

PHP 8.5 for WordPress developers presents an interesting problem. The language has useful new features, but a plugin that supports older PHP versions cannot use PHP 8.5 syntax in files those runtimes parse.

That does not make the release irrelevant. It means we need to separate three questions:

  1. Which features improve PHP code?
  2. Which features are useful inside WordPress?
  3. Which features can a plugin safely require without abandoning users?

PHP 8.5 was released on November 20, 2025. It adds a built-in URI extension, the pipe operator, clone-with support, #[\NoDiscard], persistent cURL share handles, and smaller conveniences such as array_first() and array_last().

Some are immediately valuable in controlled applications. Others belong in the "watch and prepare" category for public WordPress plugins.

Which PHP 8.5 features matter to WordPress developers?

Quick answer: The URI extension is the strongest general-purpose addition. Clone-with and #[\NoDiscard] improve value objects and APIs. The pipe operator can make transformations easier to read. Persistent cURL sharing may help specialized high-volume applications. Public plugins should use these only after intentionally raising their minimum PHP version.

The key phrase is intentionally raising it. A new language feature is not worth a fatal error across thousands of customer sites.

Compatibility comes before clever syntax

WordPress 7.0 supports PHP 7.4 through PHP 8.5, while PHP 8.3 remains the minimum recommended version. That gap matters.

If a public plugin declares PHP 7.4 support, the parser must be able to read every loaded PHP file on 7.4. You cannot hide PHP 8.5 syntax behind this check:

if (PHP_VERSION_ID >= 80500) {
    $slug = $title |> trim(...) |> strtolower(...);
}

PHP parses the file before it executes the condition. On an older runtime, the unsupported syntax can fail before the version check helps.

Your options are:

  • Keep the production code compatible with the declared minimum.
  • Isolate version-specific implementations in files loaded only on supported runtimes.
  • Raise the plugin's minimum PHP requirement and communicate it clearly.
  • Use PHP 8.5 in internal tools, build systems, or applications where you control the server.

I prefer honesty over complicated compatibility tricks. If the business can support PHP 8.5, require it. If it cannot, do not sneak 8.5 syntax into broadly loaded files.

1. The new URI extension solves a real PHP weakness

PHP 8.5 includes an always-available URI extension with separate implementations for RFC 3986 URIs and WHATWG URLs.

use Uri\WhatWg\Url;

$url = new Url('https://example.com/products/?ref=partner');
$host = $url->getAsciiHost();

The WHATWG URL implementation provides getAsciiHost() and getUnicodeHost(). The RFC 3986 implementation uses getHost(), so choose the class and accessor that match the URL standard your code needs.

Historically, PHP developers often reached for parse_url(), string replacements, or third-party packages. Those approaches can work, but URL parsing becomes dangerous when code mixes validation, normalization, display, and security decisions.

For WordPress code, the new extension does not automatically replace functions such as wp_parse_url(), esc_url(), esc_url_raw(), add_query_arg(), and wp_safe_redirect(). Those functions carry WordPress-specific behavior and filters.

The URI extension is most attractive when you need standards-based parsing or transformation outside a WordPress presentation boundary. For example:

  • Normalizing external API endpoints
  • Comparing callback origins
  • Building an integration client shared with non-WordPress PHP code
  • Handling internationalized WHATWG URLs
  • Representing URLs as immutable values

Security still depends on context. Correctly parsing a URL does not prove that redirecting to it is safe or that the current user may access it.

2. The pipe operator makes transformations read forward

The pipe operator passes the result on its left into the callable on its right.

$slug = $title
    |> trim(...)
    |> (fn(string $value): string => str_replace(' ', '-', $value))
    |> strtolower(...);

This is easier to read than deeply nested function calls because the data flows from top to bottom.

It is useful for:

  • Normalization pipelines
  • Small content transformations
  • Mapping immutable values through pure functions
  • Data preparation with obvious stages

It is not a replacement for a well-named domain method. A 15-stage pipe chain containing database writes, logging, remote requests, and state mutation is still difficult code. It only has fashionable punctuation.

For WordPress plugins, I would use the pipe operator where every step is predictable and side effects are minimal. If a transformation needs branching, retries, or detailed error handling, ordinary statements will usually communicate intent better.

3. Clone-with makes immutable objects more practical

PHP 8.5 turns clone into a function form that can update properties during cloning.

readonly class AccessRule
{
    /**
     * Create an access rule.
     */
    public function __construct(
        public int $levelId,
        public bool $enabled,
    ) {
    }

    /**
     * Return a disabled copy of the rule.
     */
    public function disable(): self
    {
        return clone($this, [
            'enabled' => false,
        ]);
    }
}

This fits the "with-er" pattern for readonly value objects. Instead of mutating an existing object, code creates a modified copy.

That can be valuable for settings, access rules, configuration, API request objects, and state passed through several layers. Immutable values reduce the risk that one function unexpectedly changes an object another part of the plugin still holds.

I would not convert every WordPress data structure into a readonly object. Arrays remain appropriate at WordPress boundaries, and WordPress core APIs often return mutable objects. Use value objects where they protect a real domain rule, not to make simple code look enterprise-ready.

4. #[\NoDiscard] makes ignored results visible

Some return values are too important to ignore. A method might return a validation result, a new immutable instance, or an error that determines whether a write succeeded.

PHP 8.5 lets an API communicate that requirement:

/**
 * Validate an access rule.
 */
#[\NoDiscard]
function validate_access_rule(array $rule): ValidationResult
{
    return ValidationResult::fromRule($rule);
}

Calling the function without consuming the result emits a warning. If ignoring the result is intentional, a (void) cast makes that explicit.

This is valuable for internal APIs where a missed return value can silently produce incorrect behavior. It also documents intent for IDEs and static-analysis tools.

Be selective. Marking every getter as #[\NoDiscard] creates noise. Use it where discarding the result is probably a bug.

5. Persistent cURL share handles target specialized workloads

curl_share_init_persistent() lets cURL share state such as DNS and connection information across PHP requests. That can reduce repeated connection setup for applications making frequent requests to the same hosts.

This is not an automatic replacement for the WordPress HTTP API.

WordPress plugins normally benefit from wp_remote_get(), wp_remote_post(), and related functions because they provide a consistent abstraction, filters, proxy behavior, and compatibility across transports. Bypassing that layer changes more than performance.

Persistent cURL sharing is worth investigating when:

  • You control the hosting environment.
  • Profiling shows connection setup is a meaningful bottleneck.
  • The integration makes many requests to a small set of hosts.
  • You own the transport layer and its failure handling.

Do not adopt it because "persistent" sounds faster. Measure the actual workload first.

6. Small additions may deliver the quickest wins

PHP 8.5 also adds array_first() and array_last().

$firstEvent = array_first($events);
$lastEvent  = array_last($events);

These remove common combinations of empty checks, key lookup, and indexing. They are not revolutionary, but good language releases often remove small, repeated friction.

The same compatibility rule applies. If the code must run below PHP 8.5, use an existing compatible helper or a narrowly scoped polyfill rather than calling the functions directly.

My PHP 8.5 adoption strategy

For a WordPress product, I would use four stages.

Stage 1: Test the runtime

Add PHP 8.5 to continuous integration. Find deprecations, changed behavior, dependency failures, and test assumptions before users do.

The official PHP 8.5 migration guide explicitly recommends testing incompatibilities before changing production environments.

Stage 2: Use 8.5 in controlled tooling

Internal scripts, static-analysis containers, and private applications are good places to learn the features when you control their runtime.

Stage 3: Raise the supported version for business reasons

Raise a public plugin's minimum only when security, maintainability, hosting adoption, and support cost justify it. A pipe operator alone is not a migration strategy.

Stage 4: Refactor where a feature removes real complexity

Use the URI extension for standards-based URL work, clone-with for meaningful immutable values, and #[\NoDiscard] for critical results. Leave stable code alone when the new syntax offers no practical improvement.

Frequently Asked Questions

Can WordPress run on PHP 8.5?

WordPress 6.9 and 7.0 officially support PHP 8.5. Complete site compatibility still depends on every installed plugin, theme, and dependency, so verify the full site in staging before changing production.

Can a WordPress plugin use the PHP 8.5 pipe operator?

Yes, if the plugin requires PHP 8.5 or safely isolates the syntax from older runtimes. A plugin that claims support for PHP 7.4 cannot place pipe syntax in files those sites parse.

Does the PHP URI extension replace WordPress URL functions?

No. It provides standards-based URI and URL objects. WordPress functions still handle platform-specific escaping, filtering, redirects, and integration behavior.

Is #[\NoDiscard] useful for plugin development?

Yes, especially for validation results, immutable transformations, and operations where ignoring the result is likely a defect. It should be used selectively.

Should a plugin raise its minimum PHP version to 8.5 now?

Only when its users, hosting data, dependencies, security needs, and maintenance costs support the decision. New syntax is a benefit, but compatibility is a product commitment.

Use PHP 8.5 where it improves the system

PHP 8.5 is a strong language release because it improves correctness and expressiveness without demanding a new programming model.

For WordPress developers, the exciting part is not writing the newest syntax first. It is having better tools available when product compatibility catches up.

Test PHP 8.5 now. Adopt it first in environments you control. Raise requirements deliberately. Then use each feature where it makes the code easier to understand, safer to change, or measurably faster.

If PHP 8.5 testing reveals older design problems, start with PHP Code Refactoring for Legacy Codebases and How to Optimize Large PHP Codebases Safely.