cache.lat
On October 6, 2026, the PHP team tagged PHP 8.6.0 RC3 along with PHP 8.5.12 RC1 and PHP 8.4.27 RC1. According to the published coverage, these are bug fix and memory safety versions, with no new features and no associated CVEs. They are release candidates: they are for testing, not for production. Here is what this means for your WordPress.
What was published exactly
- PHP 8.6.0 RC3: the development branch has already passed feature freeze; RC3 fixes pending issues before the final version.
- PHP 8.5.12 RC1 and 8.4.27 RC1: upcoming maintenance versions of the active branches.
- Dates: the announcement mentions final versions "in the coming weeks" if no critical errors appear. There is no set date, so don't take it for granted.
Before this, on September 24, the security versions PHP 8.5.11, 8.4.26, 8.3.35, and 8.2.34 were released. If you haven't updated to those yet, that is the real pending task; the RC does not replace it. The official news is in the php.net news archive.
What you should NOT do
Do not install a release candidate on a production site. An RC can bring regressions, and WordPress depends on plugins and themes that are not always tested against new PHP versions. If your hosting offers you "the latest version" automatically, check that it does not include test versions.
What you SHOULD do: a testing environment
If you want to get ahead of PHP 8.6, do it on a copy of your site (staging), never on the live site:
- Clone the site to a separate environment with the same configuration as production.
- Enable debug mode and check the error log for deprecated function notices (deprecated) and fatal errors.
- Test the critical paths: homepage, posts, contact form, search, and, if you have a store, cart and checkout.
- Note which plugin or theme fails and check whether its author declares compatibility.
Doing this now gives you room: when the final version comes out, you will already know what needs to be resolved and you won't have to improvise.
How cache fits into a PHP migration
A page cache that serves static HTML reduces how much PHP runs on each visit: the visitor receives an already generated file instead of going through WordPress. That does not exempt you from updating PHP (the admin panel, login, checkout, and page regeneration still use PHP), but it does make a typical visit depend less on the interpreter. You can read how cache.lat does it on the how it works page and check the details in technical data.
After changing PHP version
- Purge the full cache so pages are regenerated with the new version and no old copies with errors remain.
- Check the homepage and a couple of posts, comparing against the previous version.
- Verify that pages are still served as static files and are not bypassing the cache.
Suggested plan for this week
- Today: confirm that your server runs a version with the September security patches (8.5.11, 8.4.26, 8.3.35, or 8.2.34, depending on your branch).
- This week: create or update your testing environment.
- When the final version comes out: test on staging, wait for your key plugins to confirm compatibility, and only then plan the migration.
If you have questions about how to configure the cache during a migration, the cache.lat documentation is the best starting point.
Sources: php.net and the coverage by warp2search from October 7, 2026.