WordPress 7.1: How to Prepare Before the August Release

The 19 August 2026 release date for WordPress 7.1 is fixed. WordCamp US is the backdrop, and the WordPress project has tied the release to that event, which means the timeline will not slip for anyone who has not prepared. If your site runs on WordPress and you have not yet thought about how you will handle this update, that window is closing.

The scale of what is changing matters here. WordPress 7.1 RC1 contains more than 145 updates and fixes since Beta 4 alone: 57 in the Editor and 88 in Core. Changes of that volume touch enough of the platform’s internals that plugins and themes built against earlier versions can behave unpredictably once the update lands — and for a business site, unpredictable behaviour means downtime, broken checkout flows, or a contact form that silently stops sending. This is a major release by any measure.

The specific changes in 7.1 include a new Icons API, speculative loading configuration via environment variables, email notifications for @mentions, and shareable revision links for collaborative editing. The Icons API affects how themes and plugins render graphical elements. Speculative loading changes how the browser pre-fetches pages, which can interact with caching configurations in ways that are not always obvious until something breaks. The collaboration features — @mention notifications and revision links — introduce new database activity and email-sending behaviour, any of which could conflict with a plugin already handling similar functionality on your site. Each of those touches a different part of the platform.

WordPress 7.0’s Pulled Features Are a Practical Warning, Not a Historical Footnote

WordPress 7.0 arrived with its first collaborative editor features removed entirely before release — cut because too many issues surfaced during testing. These were the headline capability of that release, pulled because the project could not ship them safely in time. That decision reflects well on the project’s discipline, but it also illustrates the gap between what a major release promises and what it can safely deliver on day one.

The same collaborative tools are back in 7.1, refined and extended, which is a reasonable development path. They arrive with a longer testing history than they had in 7.0, but they are still new enough to carry uncertainty. WordPress itself is explicit on this point: RC1 should not be installed on production or mission-critical websites. The recommendation is to evaluate it on a test server first — and that guidance applies with equal force once the final release ships, because the final version will carry the same architectural changes.

A staging site is a private copy of your live site, running the same plugins, theme, and content, where you can apply the update and observe what happens before any of it touches your customers. If a plugin conflict surfaces on staging, you fix it there. If a layout breaks, you identify it before Google does. The cost of running a staging environment is a fraction of what a day of downtime costs a business that processes orders or generates leads online, which makes it the practical answer to the uncertainty 7.1 carries.

The July 2026 Security Incident Shows What Unmanaged WordPress Carries

A critical vulnerability patched in July 2026 allowed full server compromise with no authentication required and no plugins involved. A visitor with no account and no credentials could take complete control of the server. Affected sites required immediate update to versions 6.8.6, 6.9.5, or 7.0.2.

The vulnerability required no sophistication to exploit, and the sites most exposed were the ones running without a managed update process: no monitoring, no alert when a patch dropped, no one watching. Any opportunist with basic knowledge could act on it. That is the cost of leaving updates unmanaged — a separate risk from the 7.1 compatibility question, though both trace back to the same root cause: no one is responsible for the platform.

Business owners often treat WordPress updates as a technical task to defer. The July incident and the 7.1 release together make the case that deferral has a specific price: a compromised server, a site taken offline, customer data exposed, or a revenue channel that stops working the morning after an update runs automatically at 3am.

One consequence that rarely gets considered is what happens when your site breaks after an untested update and you need emergency recovery work: you are competing for specialist availability with every other site owner in the same position. Major WordPress releases create a spike in support demand. If you are running a site that matters to your business and you do not have a staging environment, a testing process, or someone who monitors WordPress security advisories, the 19 August date is the point at which a 145-change update will be available for automatic installation, and your site’s behaviour after that moment depends entirely on whether you have tested for it.

---

Before 19 August, I am offering a pre-release staging test for WordPress 7.1: I set up a staging copy of your site, apply the release candidate, and document any conflicts or breakage before the final version ships. Given that 7.0’s headline features were pulled after testing failures and 7.1 carries more than 145 changes, waiting until the update is live on your production site is the wrong order of operations. Book the staging test now, while there is still time to act before the release date.