cache.lat
WordPress 7.2 already has a proposed schedule: according to the call for volunteers published on make.wordpress.org, Beta 1 would arrive between October 20 and 22, and the final version between December 8 and 10, 2026. It is a flexible schedule, but it is enough to get organized. If your site depends on speed, it is worth preparing the ground now and not on launch day.
The proposed schedule, in plain terms
- Beta 1: October 20-22
- Beta 2: October 27-29
- Beta 3: November 3-5
- Beta 4: November 10-12
- Release Candidate 1, 2, and 3: from November 17 to December 3
- Final version: December 8-10
These are proposed dates, so always check the current schedule before acting. The important thing: you have about seven weeks between the first beta and the stable version. That is more than enough time to test calmly.
Why it matters if you use page cache
Every major version of WordPress can touch things that affect a cached site: changes in the block editor, in the way the theme generates styles, in scripts loaded on the front end, or in headers. A cache that serves static HTML is very fast precisely because it does not run PHP on every visit; therefore, if something changes in how the page is generated, the stored static file keeps showing the previous version until it is regenerated.
If you want to understand that mechanism, it is explained in how cache.lat works.
Five-step preparation plan
1. Set up a testing environment (staging)
Cloning the site to a subdomain or a staging environment is the safest option. Never test a beta in production. Betas exist so the community can find bugs, and those bugs can be yours if your site is the guinea pig.
2. Test the beta with your real combination of theme and plugins
What matters is not WordPress alone, but your theme, your visual builder, your forms plugin, your store. Check especially:
- The home page and the pages that receive the most traffic.
- Forms, cart, and checkout if you have e-commerce.
- Menus, search, and dynamic content.
- The admin panel and the block editor with your usual templates.
3. Check your plugins' compatibility notices
Before updating, check whether the authors of your critical plugins declare compatibility with the new version. An abandoned plugin is the main risk of any major update. If one has not been updated in months, it is a good time to look for an alternative.
4. Check your hosting's PHP version
A WordPress update is a good excuse to review PHP. Check in your hosting panel which version you are running and what minimum requirements the new WordPress version declares. If you are on a PHP branch that no longer receives support, plan the migration in advance and also test it in staging. The technical data on what the plugin needs is in cache.lat technical data.
5. Define how you will purge the cache after updating
On the day you update to the final version, the sensible procedure is: backup, update core, update plugins and theme, and only then regenerate the cached pages and browse the site in a private window to confirm that what is being served is the new version. If you do not purge, you may end up looking at old HTML and believing that "the update did nothing," or worse, mixing old HTML with new resources. The cache.lat documentation explains how to handle regeneration.
What NOT to do
- Do not update a site that generates revenue on launch day. Wait for the first maintenance version if the business depends on the site.
- Do not disable the cache "so it does not get in the way" during the update and then forget it that way. It is a common mistake that ends up in a slow site for weeks.
- Do not test only while logged in as an administrator: the anonymous visitor is the one who receives the cached version, so also test without a session.
A note about betas
Beta and release candidate versions are for testing, not for production. If you have technical knowledge, reporting a bug found in staging helps the whole community, and the WordPress.org team looks for volunteers for testing in each cycle, as seen in the call linked above.
Practical summary
- Mark October-December on the calendar and verify the official dates.
- Clone to staging and test with your real combination of plugins.
- Review PHP and plugin compatibility before the final launch.
- Have the cache purge/regeneration procedure ready.
- Always test as an anonymous visitor.
If you have questions about how static cache fits into your site, you can check the cache.lat plans or write to the TuNegocioEnLinea.net team.