What Is Changing in PHP 8.6 and When to Move

PHP 8.6 is the next version of the language that runs WordPress and most business websites. It is due for release on 19 November 2026. For anyone responsible for PHP version management for B2B websites, the useful questions are what changes, what stops working later and when switching makes sense. The short answer is that 8.6 is a steady release with sensible security improvements. No business website should move on the day it comes out.

The changes below come from the proposals the PHP project has accepted for 8.6, each of which is linked so a developer can check the detail. Each one is described in plain terms, with a focus on what it means for a website rather than for the people writing code. For background on the language itself, see what PHP is and what it is used for.

When Is PHP 8.6 Released

PHP 8.6 is scheduled for general availability on 19 November 2026, according to the official PHP 8.6 release timetable. The third release candidate came out on 8 October, with a fourth planned for 21 October and a fifth for 5 November. Release candidates are test builds for developers and hosts to try, not versions to run on a live website.

The feature list is already fixed. All proposals had to finish voting by the soft feature freeze on 13 August. The hard freeze on 22 September means anything new now needs approval from the release managers. What is in the release candidates is very close to what ships in November.

Good developer summaries of the release already exist, including the Laravel News rundown of PHP 8.6 and the PHP.Watch change list. Both are written for programmers. The sections below translate the main points for the people who own and pay for websites.

What Is New in PHP 8.6

PHP 8.6 adds a handful of features that make code shorter and clearer, rather than anything that changes how a website looks or behaves for visitors. The biggest is partial function application, which lets a developer fill in some of a function’s inputs now and the rest later without writing extra wrapper code.

Several smaller additions tidy up jobs that developers have long written by hand. A new clamp function keeps a number between a minimum and a maximum. A new Duration class gives a proper way to describe lengths of time such as a network timeout. Readonly properties can now have default values. A SortDirection enum gives one standard way to say ascending or descending.

Two larger additions sit further from everyday websites. The stream error handling changes make failures when reading files or calling other services easier to catch and record. The new polling API helps software that holds many network connections open at the same time.

None of these features does anything for a website until a developer, plugin author or theme author writes code that uses them. For a WordPress website, that will happen gradually as plugins drop support for older PHP branches over the next few years. Steady releases like this one are part of why PHP is still relevant for business websites.

Security Changes Worth Knowing About

The most useful change in PHP 8.6 for a business website is a set of safer default settings for sessions, the mechanism that keeps a visitor logged in. The secure session defaults proposal turns on strict mode, so PHP rejects session IDs it did not create. It also hides the session cookie from JavaScript. The proposal also sets the cookie’s SameSite attribute to Lax, which stops browsers sending it with most requests that start on other websites.

Well configured servers and frameworks have used these settings for years, so many websites will see no difference. Older custom code that passes session IDs between subdomains, or across a payment hand off, can behave differently and needs testing before the switch.

A second change narrows a known attack route. PHP has a feature for chaining filters onto files. Attackers have used very long chains to turn a file inclusion weakness into the ability to run their own code. The filter chain limit proposal makes PHP 8.6 raise a warning when one of these chains uses more than 16 filters, as the first step towards blocking them outright.

A new setting can also show the values passed to a function when a native function raises an error, which makes faults quicker to diagnose. The error arguments proposal was accepted with the setting switched off by default, because error logs can otherwise end up holding personal data. That is the right default for websites that handle customer details under UK GDPR.

What Is Being Deprecated in PHP 8.6

A deprecation is a warning that a feature still works but will be removed in a future version, usually PHP 9. Deprecated code keeps running on 8.6, but it writes notices to the error log and it marks work that has to be done before the next major version.

The deprecations proposal for 8.6 covers a long list of small items, voted on one by one. Separate proposals deal with the multibyte regular expression functions, whose underlying library is no longer maintained. Another covers returning values from constructors and destructors.

Several of the accepted items are likely to turn up in older WordPress plugins and custom themes. These are the ones worth checking for first.

• The mb_ereg family of functions, used for pattern matching in text that contains accented letters or characters from other alphabets.
• Duplicate function names such as is_integer, is_long, is_double and doubleval, which have standard equivalents.
• Calling define with the old case insensitive option.
• Returning a value from a class constructor or destructor.
• Returning from inside a finally block in error handling code.

Most of these are simple fixes for a developer. The risk comes from abandoned plugins that nobody is updating, because those will carry the deprecated code until PHP 9 stops it working altogether.

Checking the error log on a staging copy after a test upgrade is the quickest way to see which plugins raise deprecation notices. The list it produces doubles as a plan for future work, well before PHP 9 is on the horizon. The PHP upgrade checklist sets out how to test what breaks.

Why a Business Website Should Not Move on Release Day

A business website should not switch to PHP 8.6 on 19 November, because the software it depends on will not all be ready. WordPress core, plugins, themes and hosting platforms each catch up with a new PHP branch at their own pace. That process takes months rather than days.

WordPress core moves faster than most of the plugins built on it. The WordPress core handbook says the project aims to support each new PHP version in the major WordPress release that lands close to it each November. The same page points out that WordPress is rarely used without plugins and a theme. Those are maintained by many separate developers working to their own schedules.

Hosts are the other half of the picture. Managed hosting platforms usually add a new PHP branch some weeks after release, once their own testing is complete. Early point releases also fix the bugs that only appear once the wider world starts using a new version. Our guide to WordPress and PHP compatibility covers how to check whether plugins are ready.

Adoption figures show how slowly the wider market moves to a new branch, even after it has been out for a year. Version data from W3Techs shows PHP 8.5, released in November 2025, still running on a small minority of PHP 8 websites, with 8.3 and 8.2 the most common branches by a wide margin. The wider picture of how much of the internet runs on PHP explains why those figures move so slowly.

When Moving to PHP 8.6 Makes Sense

Moving to PHP 8.6 makes sense once the plugins and theme on a website are confirmed compatible, the host offers it as a stable option and a full test on a staging copy has passed. For most WordPress websites that point will arrive some months into 2027, not in November.

The bigger priority for many businesses is the version they run today. PHP 8.2 loses security support on 31 December 2026, only six weeks after 8.6 is due, so any website still on 8.2 should move to 8.4 or 8.5 now rather than wait. Our guide to PHP 8.2 end of life sets out what changes on that date.

Websites on PHP 8.3 have more breathing room, with security fixes until the end of 2027. That is still a deadline worth planning for, as our piece on PHP 8.3 end of life explains. A move to 8.5 or later 8.6 can be scheduled around other work rather than squeezed in at the last minute.

The hosting environment matters as well. The minimum versions proposal for 8.6 means websites using persistent database connections need MySQL 5.7.3 or MariaDB 10.2.4 or later. Both of those older database lines are already past end of life. The WordPress requirements page recommends MySQL 8.0 or MariaDB 10.11 or greater alongside PHP 8.3 or greater, so a host that meets those already clears the bar.

How Long PHP 8.6 Will Be Supported

PHP 8.6 will follow the standard support pattern of two years of active support and two further years of security fixes. The PHP supported versions page sets out that rule. Recent branches have all run to 31 December at the end of each period.

Going by that pattern, PHP 8.6 should receive bug fixes and security fixes until 31 December 2028, then security fixes only until 31 December 2030. That makes it the longest supported option available once it settles, two years beyond PHP 8.4. Our guide to PHP versions explained sets out how each branch moves through those stages.

Waiting a few months before switching costs very little of that window. A website that moves in spring 2027 still has more than three years of security support ahead of it, against far less risk than an upgrade made in the first week. A business weighing a rebuild instead of an upgrade can compare PHP, Python or Next.js for a business website.

Planning the Move to PHP 8.6

The sensible plan for PHP 8.6 is to make sure the website is on a supported branch now and to schedule the move to 8.6 for after it has settled. That means checking the current PHP version in the hosting control panel or the WordPress Site Health screen. Note when that branch loses security support, because that date sets the real deadline.

Plugins that have not been updated for a long time deserve a closer look, because they are the most likely to break or raise deprecation notices. Replacing them before an upgrade is cheaper than fixing a broken website afterwards. Our guide to the risks of an end of life PHP version covers what is at stake when that work is left too long.

Every upgrade should be tested on a staging copy first. Priority Pixels WordPress support includes PHP version upgrades in the retainer, with core, plugin and theme updates tested against a staging copy before they reach the live website. For a business website, PHP 8.6 is one more step in that routine rather than a reason to rush.