No production
A Release Candidate remains a prerelease. It is used to identify and report issues, not to immediately replace a stable branch on the main server.
Processing…
Compatibility and migration
PHP 8.6 is entering its final stabilization phase before a general release planned for November 19, 2026. For PHP applications and WordPress sites, now is the time to test compatibility, not to migrate production.
PHP 8.6 development passed the hard feature freeze on September 22, 2026: features are now frozen and efforts are focused on stabilization. The schedule provides for several Release Candidates before the stable version, but the exact status of each prerelease must be verified in the official announcements.
PHP 8.6 is advanced enough to begin representative testing. It is still a prerelease, however: tests must be carried out in an isolated environment covering the code, dependencies, sessions, database, and business workflows.
The project schedule sets the hard feature freeze for September 22, 2026. It places a Release Candidate on September 24, followed by other candidate versions on October 8 and 22 and November 5, before a stable release currently planned for November 19, 2026.
The schedule has been adjusted: RC1 is shown as abandoned and RC2 is scheduled for September 24. At the time of writing, September 24, 2026, php.net still displays PHP 8.6 Beta 3 as the latest officially announced test release.
RC2 is therefore listed on the schedule for that date, but it should not be considered released before the official announcement is published. This distinction illustrates a useful rule throughout the cycle: consult both the provisional schedule and the project's actual publications.
A Release Candidate remains a prerelease. It is used to identify and report issues, not to immediately replace a stable branch on the main server.
Results are valuable only if the PHP configuration, extensions, database, and external services are close to production.
Checks must cover custom code, the framework or CMS, Composer libraries, extensions, and scheduled jobs.
Errors, warnings, and deprecations must be reviewed, even when pages appear to work normally.
An application running on PHP 8.5 cannot automatically be declared compatible with PHP 8.6. Rarely executed paths — imports, exports, CRON jobs, file processing, or error scenarios — are often the ones that reveal discrepancies.
PHP 8.6 is expected to change three default values: session.use_strict_mode goes from 0 to 1, session.cookie_httponly from 0 to 1, and session.cookie_samesite from an undefined value to Lax.
These choices aim to provide a more secure configuration against certain risks related to sessions and cross-site requests. They should be transparent for many modern applications, particularly when these protections are already configured explicitly.
With session.cookie_httponly=1, the cookie becomes inaccessible through document.cookie. Any application that retrieves the session identifier in the browser must be reviewed and, in principle, directed toward a dedicated authentication mechanism.
The cookie is normally not sent with certain cross-site requests. SSO, cross-domain forms, returns from third-party services, and multi-domain architectures therefore require end-to-end testing.
A login mechanism may pass a unit test and fail when a browser crosses several domains. Authentication, logout, redirects, and returns from external gateways are among the first scenarios to replay.
The behavior of existing sessions, identifier rotation, and any historical assumptions in the code must also be checked. Strict mode may reveal implementations that previously accepted identifiers not initialized by the server.
Applications that read the PHP cookie in JavaScript or pass a session between several domains carry a higher risk. They must be reviewed before any migration decision.
The PHP 8.6 UPGRADING document lists several behaviors becoming stricter. Functions related to arrays, paths, locales, processes, archives, or certain extensions may now throw a clearer ValueError or TypeError.
array_filter(), in particular, must reject an invalid mode with a ValueError. pathinfo() validates its flags parameter more thoroughly, while other functions no longer tolerate certain out-of-scope values.
A check limited to the home page is therefore not enough. Forms, API calls, imports, exports, asynchronous processing, and degraded scenarios must be run with both valid and invalid data.
mbstring extension disappearing. Direct and indirect calls through Composer must be identified.COM_RESET_CONNECTION.configure script.COM_RESET_CONNECTION makes it possible to restore a connection to its initial state before reuse. Earlier database versions may continue to work with PHP 8.6, but not with persistent connections in the same way.
An application that unintentionally relies on state left by a previous query may also change its behavior. This risk is limited in modern environments, but deserves review on business software and servers that have been maintained for several years.
The Autoconf 2.71 prerequisite mainly concerns customized environments and pipelines that build PHP directly from its Git sources. It does not apply in the same way to builds made from official release archives.
Internal images should therefore be audited to determine their origin, compilation tools, and support for the C11 standard.
The purpose of this phase is not to prove that a page is displayed, but to discover now what could break during the future migration.
Compatibility testing can also be used to study the possibilities offered by PHP 8.6. Several changes concern code writing, immutable objects, and URI handling.
Partial application of functions makes it possible to fix certain arguments while leaving others to be supplied. An expression such as $replaceHello = str_replace('hello', 'bonjour', ?); produces a Closure waiting for the missing value.
PHP 8.6 also allows a default value on certain readonly instance properties. The URI API is progressing with construction and identification functions, improved percent-encoding handling, and the Uri\Rfc3986\UriBuilder class.
An incompatibility may come from a library rather than from business code. The Composer 2.10.3 changelog, published on August 27, 2026, explicitly mentions fixes for deprecation messages related to PHP 8.6.
A reasonable approach is to create a dedicated branch, install PHP 8.6 in an isolated environment, then run composer update and composer check-platform-reqs. Automated tests and warning analysis come next.
As of September 24, 2026, WordPress's official compatibility matrix documents PHP through version 8.5. PHP 8.6 is not listed yet, which is consistent with its current development stage.
Work to support new PHP versions generally begins after the feature freeze and beta releases. Simply accessing the administration area therefore does not establish that a site is production-ready.
WordPress Core, the active theme, the child theme, each plugin, custom code, any Composer dependencies, scheduled tasks, and external services must be validated separately.
It indicates the support level of WordPress Core, but does not automatically cover the themes, plugins, and site-specific development.
It depends on everything actually installed and configured, including external integrations, scheduled tasks, and editorial or commercial workflows.
The priority level depends on the project's architecture. Sessions and multi-domain flows nevertheless deserve particular attention because of the new default values.
| Area | Checks | Risk being investigated |
|---|---|---|
| Sessions | Login, logout, SSO, cross-site POST requests, and external returns | Missing or inaccessible cookie |
| Code and dependencies | Tests, deprecations, types, and invalid parameters | Exceptions or changed behavior |
| Data | Imports, exports, files, archives, and document generation | Rarely tested paths becoming blocking |
| Infrastructure | Extensions, Docker, compilation, MySQL, or MariaDB | Prerequisites not met |
| CMS | Core, theme, plugins, scheduled tasks, and custom code | Partial site compatibility |
| Performance | Response time, memory, processing, and SQL load | Project-specific regression |
PHP 8.6 notes report optimizations concerning, among other things, printf(), certain constructor calls, array_map(), JSON, DOM, and ZTS builds. These changes should be measured on the actual application rather than extrapolated from a microbenchmark.
Response time, memory consumption, background processing duration, and database load provide more useful indicators for deciding on a migration.
Preparation can begin before the stable version provided production is protected and every result is documented. The goal is to obtain a reliable picture of blockers, deprecations, and required work.
The stable release of PHP 8.6 is currently planned for November 19, 2026, but this does not create an obligation to switch immediately. PHP 8.5, released on November 20, 2025, remains actively supported until the end of 2027, then is expected to receive security fixes until the end of 2029. PHP 8.4 also remains a supported branch.
A stable application can therefore wait until its dependencies and infrastructure are ready. Conversely, postponing initial testing for several years turns a manageable migration into technical debt.
The Release Candidate period gives teams, library maintainers, and plugin vendors time to identify incompatibilities. Fixes can thus be prepared before the new version becomes a production target.
The actual transition should take place after validating the complete environment, backups, a rollback plan, and third-party components.
PHP 8.6 brings new APIs and several improvements, but its production value will first depend on the quality of the preparation. Session changes, stricter parameter validation, and technical prerequisites are the testing priorities.
For WordPress as for a custom PHP application, the method remains the same: test a representative copy, monitor the logs, test real workflows, and modify the main server only after validation.
The prerelease schedule may still change. The status of the Release Candidates and stable version must therefore be confirmed in official publications before any operational decision.
Official PHP 8.6 project schedule and UPGRADING migration document, to be consulted on the official PHP project resources to confirm the status of prereleases and technical changes.
WordPress's official PHP compatibility matrix and Composer 2.10.3 changelog, cited to describe the support status and tooling as of September 24, 2026.
Web development
PHP migration, CMS updates or framework upgrades: identify compatibility issues and test essential user journeys before going live.
Enter at least 2 characters to start searching.