WordPress is back to three major releases a year, and 7.1 is scheduled for 19 August, timed to WordCamp US. If you run WordPress sites, this is the second significant update in three months, following 7.0 in May.
What changed in 7.0, and why it matters for 7.1
7.0 was the biggest shift the platform has seen in years: AI features managed from a central hub, a redesigned admin, and real-time collaboration for teams working on the same content. A lot of sites have not moved to it yet. If you are still on 6.9, 7.1 means you are about to be two major versions behind, on a codebase that is changing quickly underneath you.
The real risk is not the update
It rarely is. The risk is plugin compatibility. Every major release leaves a tail of plugins that stop working, and the plugins most likely to break are the ones doing something clever with the editor, custom fields or page building. Those are usually the ones your site depends on most.
The update is not the hard part. Finding out which of your forty plugins quietly stopped working is the hard part.
What we do for the sites we run
- Inventory first. Every plugin, its last update date, and whether it is actively maintained. Anything abandoned gets replaced before the update, not after.
- Staging, always. The update runs on a copy of the site. Nobody updates production to find out what happens.
- Check the things nobody checks. Forms, checkout, search, logins. The homepage always looks fine. The contact form is what breaks.
- Update in order. Core, then plugins, then theme. One at a time on anything unusual.
- Have a way back. A backup you have actually tested restoring.
The short version
If you run WordPress and nobody is explicitly responsible for updates, 19 August is a good moment to fix that. The sites that get hurt by major releases are not the complicated ones. They are the ones nobody was watching.