WordPress 7.0 arrived in May, six weeks later than planned and without the real-time collaboration that had been its headline feature. 7.1 followed, and 7.2 now closes the year. It is a quieter release, with more for developers and site owners than for editors, which is exactly why it is easy to under-test.
A proper place for credentials
The most useful change for larger sites is a new Secrets API: a standard way to store API keys and credentials, encrypted at rest, with support for rotation and for keeping secrets in an external store. Today, keys for CRMs, payment providers and other integrations end up in configuration files, in the database in plain text or in a plugin's settings page. A standard approach makes those integrations easier to audit and easier to hand over.
It will take time for plugins to adopt it. In the meantime it is a good prompt to list where your site's credentials live today and who can see them.
Changes editors will notice
- Images can be resized, compressed and converted in the browser before upload
- Responsive controls extend to more blocks, including gallery columns and image cropping
- Notes, the block-level comments added in 7.0, gain reactions and a minimised mode
- Navigation links can be added and edited from the editor sidebar
- Admin icons move from the old Dashicons set to the WordPress icon library
What to test before 8 December
- Image uploads, if you rely on server-side image handling, a DAM or a CDN that transforms images
- Custom blocks and block styles, especially anything that hooks into the block inspector
- Admin customisations, since scripts and styles now load individually and icons have changed
- Integrations that store keys today, so you know which could move to the Secrets API
- Editor training notes and screenshots, which will be out of date
On a large site, the release date is when you start testing in earnest, not when you update production.
When to update
For most organisations the sensible plan is to test against the release candidates in November, then update production once 7.2.1 has picked up any early fixes, while continuing to take security releases on 7.1 immediately. That only works if your build is tidy enough to test quickly: a short, maintained plugin list, custom code kept in version control and an environment that matches production. If a major WordPress release feels like a project rather than a task, that is usually a sign the build needs attention.
