PHP 8.5: Here’s What Actually Changed

Prologue

If you’ve worked with PHP for a while, you’re probably familiar with the trend in recent PHP releases to not reinvent the wheel each year.

In favor of making day-to-day development cleaner, safer, and easier. PHP 8.5 is a continuation of this trend.

PHP 8.5 was officially released on November 20, 2025. It introduces several new features, including the URI extension, the pipe operator, clone() with property updates, #[\NoDiscard], better support for closures and first-class callables in constant expressions, along with several smaller improvements.

As of October 9, 2026, the PHP release archive lists PHP 8.5.10, released on August 27, 2026.

Before we get into the details, though, there’s one thing worth keeping in mind: you don’t need to start using most of these new features right away.

For an existing Laravel or PHP application, the more interesting question is:

“What changes are actually useful for my application, and what should I look out for when upgrading?”

That’s the viewpoint I’m going to take in this post.

Updated October 9, 2026: This post has been updated with the released PHP 8.5 documentation and migration guide. The original version was written before PHP 8.5 was released and contains a fair amount of speculation.

Questions to Ask Before Upgrading

❓ “Do I need to upgrade right away?” Not necessarily. The version of PHP 8.5 is already out, but I would determine if it makes sense for my application based on the current PHP version, the framework version, the application’s dependencies, test coverage, and a smooth deployment process.

❓ “Will my existing PHP code break automatically?” Not automatically. PHP 8.5 is a minor release within the PHP 8 series, but it still introduces deprecations and backward-incompatible changes. Review the migration guide, check your dependencies, and test the application before upgrading production.

❓ “Do I need to rewrite my application to utilize the new functionality?” Not really. The new tools and possibilities in PHP 8.5 are an opportunity, not a necessity. So I would use the new PHP 8.5 features in my application if I find them useful. However, I would not rewrite my existing and working application software solely because of the new PHP version.

❓ “Should performance be the primary reason for the upgrade?” I would think twice before doing that. I’d rather have real benchmark data than make assumptions. A generic benchmark can give you a useful baseline, but it won’t tell you how your Laravel application, APIs, queue workers, or database will behave after the upgrade. Therefore, I would measure the performance of my application after upgrading from PHP 8.4 to PHP 8.5 and see the concrete results.

PHP 8.5 at a Glance

Features That Matter

The release notes have lots of them, but here are some that you should definitely pay attention to for their impact on your code, not just as an exercise. (The official migration guide is where to go if you want to see the full list.)

1. 🔗 URI Extension

PHP 8.5 now provides a built-in URI API for applications that need standards-based URI and URL parsing, normalization, and manipulation:

// PHP 8.4 and older
$components = parse_url('https://php.net/releases/8.4/en.php');
var_dump($components['host']);
// string(7) "php.net"

// PHP 8.5
use Uri\Rfc3986\Uri;
$uri = new Uri('https://php.net/releases/8.5/en.php');
var_dump($uri->getHost());
// string(7) "php.net"

If you’re already using a third-party URL library, I wouldn’t replace it automatically. I’d first compare what the application actually needs with what the new URI API provides.

Where it helps: anywhere you’re currently doing validation or normalization of user-submitted URLs, redirect targets, or webhook callback URLs. Parsing with parse_url() has always been a bit loose about malformed input; this is stricter and standardized.

What to be cautious of: this is additive, parse_url() still works. I wouldn’t rush to replace every existing parse_url() call. A new API doesn’t automatically invalidate existing code.

2. 🔀 Pipe Operator (|>)

Chains function calls left to right, instead of nesting them inside-out:

// PHP 8.4 and older
$slug = strtolower(
    str_replace('.', '',
        str_replace(' ', '-',
            trim($title)
        )
    )
);

// PHP 8.5
$slug = $title
    |> trim(...)
    |> (fn($str) => str_replace(' ', '-', $str))
    |> (fn($str) => str_replace('.', '', $str))
    |> strtolower(...);

Use case: data transformation pipelines, for writing out readable, top-to-bottom logic, as opposed to having to read nested function calls from the inside out.

Considerations: readability improvement, but not a performance gain. Don’t assume these are faster, necessarily; it’s just a change in style. Also, this is something your team will have to become familiar with before it becomes idiomatic in your shared codebase.

3. 🧬 Clone With

PHP 8.5 makes it easier to clone an object and update specific properties at the same time:

readonly class Color
{
    public function __construct(
        public int $red,
        public int $green,
        public int $blue,
        public int $alpha = 255,
    ) {}

    public function withAlpha(int $alpha): self
    {
        return clone($this, [
            'alpha' => $alpha,
        ]);
    }
}

The official PHP release page lists clone() with an associative array of property updates as one of the new features in PHP 8.5.

Where could this come in handy?

• readonly classes
• value objects
• DTOs
• immutable-style objects
• configuration objects

This isn’t something that all PHP projects are likely to need. But if you’re already using immutable-style code, the new syntax can remove some boilerplate.

4. ⚠️ #[\NoDiscard] Attribute

One interesting addition to PHP for code quality is the new #[\NoDiscard] attribute introduced in PHP 8.5. This attribute indicates that the return value of a function is important and should not be discarded by the caller. PHP will emit a warning if the returned value is not used:

#[\NoDiscard]
function getPhpVersion(): string
{
    return 'PHP 8.5';
}

getPhpVersion();
// Warning: The return value of function getPhpVersion() should
// either be used or intentionally ignored by casting it as (void)

Use case: This is useful for library and internal-API authors in any situation where the caller should not discard a return value (such as the result of a validation), as that would be a logic error.

Considerations: The important caveat is to use (void) when you do want to discard the return value intentionally; this is the escape hatch and should not be used as a justification for poor API design.

5. 🧩 Closures and First-Class Callables in Constant Expressions

PHP 8.5 extends what can appear in constant expressions, enabling the use of static closures and first-class callables in places such as:

• attribute parameters
• property defaults
• parameter defaults
• constants

For example:

final class PostsController
{
    #[AccessControl(
        static function (
            Request $request,
            Post $post,
        ): bool {
            return $request->user === $post->getAuthor();
        }
    )]
    public function update(
        Request $request,
        Post $post,
    ): Response {
        // ...
    }
}

Use case: Frameworks and apps using attribute-driven configuration (access control, validation rules) which previously needed a workaround to express logic in an attribute.

Well, this may not change how you write a typical controller every day. But it gives frameworks and libraries more flexibility when describing behavior through attributes and other contexts of constant expressions.

6. ➰Persistent cURL Share Handles

PHP 8.5 introduces persistent cURL share handles. Essentially, it is about allowing you to persist cURL share handles between PHP requests to avoid having to re-initialize the same shared connection-related resources every time.

This is a more specialized feature than some of the additions discussed above. If your application makes a lot of outbound HTTP requests through cURL and you already care about connection reuse, it may be worth investigating.

But for a standard application that only sporadically makes some external API calls, I would not consider it a reason to upgrade solely for this feature.

7. 🧰 Small but Genuinely Useful Additions

PHP 8.5 has lots of changes besides the obvious innovations. A few of them are listed below:

New array helpers:

array_first()
array_last()

New error/exception handler functions:

get_error_handler()
get_exception_handler()

There are also changes in other areas, including:

• DOM
• Reflection
• cURL
• error handling
• attributes
• cookies
• internationalization
• database-related extensions

I’m not going to duplicate the entire list here. For an actual upgrade, the official migration guide is a better choice because it isolates new features from compatibility improvements and deprecations.

What Changes for Existing Applications

PHP 8.5 is not a “drop it in and nothing changes” release. The official migration guide clearly lists the actual deprecations and backward-incompatible changes you need to be aware of. The ones most likely to affect a typical application:

None of this is “risk-free” or “automatically safe”; that’s exactly why the checklist below exists. Run your test suite and check your deprecation warnings before you trust any upgrade.

My PHP 8.5 Upgrade Checklist for Real Projects

Before performing a production upgrade, this is the actual checklist that I would go through, not just blindly upgrading:

The Delivery Perspective

From a project point of view, the PHP version itself is rarely the risky part of such an upgrade: the dependencies, the QA’s ability to actually run the checklist above, and the release timing are much more important factors. I would not schedule a PHP version bump in the same week as a major feature release. It needs a proper QA slot, dedicated and with time, just like a capacity-planned sprint.

I wouldn’t apply every new PHP 8.5 feature on an existing codebase just because it’s available, either. The pipe operator is a nice readability improvement, but whether to introduce new syntax is a team decision, not just a technical one.

Frequently Asked Questions (FAQ)

What is new in PHP 8.5?
The main features of PHP 8.5 are URI extension, pipe operator (|>), Clone With for readonly classes, #[\NoDiscard] attribute, and support for closures in constant expressions. Details are described above.

Is PHP 8.5 a major release or a minor update?
PHP 8.5 is a minor version update to the PHP 8.x range. In other words, PHP 8.5 brings both new features and compatibility improvements, so it’s worth testing everything before moving to production.

Does PHP 8.5 include any backward-incompatible changes?
Yes, PHP 8.5 has several deprecations (non-canonical casts, null array offsets, backtick operator) and one removal (disable_classes). These changes may affect applications differently depending on the codebase, dependencies, and server configuration. That’s why I would still test the application thoroughly before upgrading to PHP 8.5.

Should I upgrade my existing PHP project to PHP 8.5?
As long as your framework and third-party libraries support PHP 8.5, you should eventually consider upgrading. Before making the change, though, double-check the points mentioned above and run your test suite.

What should I test before upgrading from PHP 8.4 to PHP 8.5?
Before upgrading, check your Composer dependencies, run the test suite, and review the list of deprecations. In the best case, you should also review all the changes that affect your project, such as new serialization- and array-related edge cases.

Do I need to rewrite my existing PHP application to upgrade to PHP 8.5?
You generally don’t need to rewrite an existing application just because you’re moving to PHP 8.5. However, you should still verify framework and dependency compatibility and test the application against the PHP 8.5 migration changes before deploying it to production.

Should I utilize all the new PHP 8.5 features right away?
Not really. As mentioned in the introduction, a feature is only worth using if you actually need it. For example, the pipe operator introduces new syntax to PHP that may improve code readability in some cases. However, not all developers will find it useful. The same applies to the URI extension, but it is rather a minor addition.

Is PHP 8.5 faster than PHP 8.4?
I do not think that there is a reason to say that PHP 8.5 is faster than PHP 8.4. If performance is a concern, then I recommend measuring your application’s performance before and after the upgrade.

Can I use PHP 8.5 with Laravel?
It all depends on the Laravel version and the application stack. Before upgrading to PHP 8.5, make sure that all of your dependencies are compatible with PHP 8.5. In the case of Laravel, PHP 8.3 is the minimum version required to run Laravel 13. You can learn more about the Laravel 13 upgrade in my separate article about Laravel upgrades.

What should I check first before upgrading PHP?
Upgrading PHP is not done in isolation, so it is worth spending a few minutes reviewing the application to identify potential issues. If you have an existing production application, then I recommend checking the following items:

1. Current PHP version
2. Framework version
3. Composer dependencies
4. PHP 8.5 migration guide
5. Test suite
6. Critical integrations
7. Staging validation
8. Rollback plan

This list isn’t exhaustive, but these are some of the key things worth considering before upgrading.

Final Take

After examining the released PHP 8.5 features, I think that the interesting part is not exactly the single headline. It is rather an overall direction.

Pipe operator, Clone With, #[\NoDiscard], and URI extension are all very neat examples. Some may have an immediate impact on your code quality, while others may be more framework- or library-specific.

But the thing is, when you are responsible for an existing production application, I would say that the feature list is not even close to the priority list.

Before even considering a PHP 8.5 upgrade, you should think about compatibility, test coverage, dependencies, integrations, monitoring, and your rollback plan

The practical approach is to:

Understand what’s new, identify what could actually be useful in your application, test the areas that carry the most risk, and then upgrade deliberately.

That is a much better practice than trying to embrace every single language update in your production environment right away.

Official PHP 8.5 Resources

• PHP 8.5 Release Announcement
• PHP 8.5 Release Page
• PHP 8.5 Migration Guide
• PHP Release Archive