WordPress 7.0.1 Maintenance Release: 31 Bug Fixes Before 7.1

Maintenance releases are the part of WordPress the trade press never covers, and the part I care about most when a client site is in production. No new features, no tour, no marketing beat — just the tidy-up pass that decides whether the last major release is safe to leave running for another quarter.

WordPress 7.0.1 landed on July 9, 2026, exactly on the schedule Aaron Jorbin posted three weeks earlier. Thirty-one bugs across Core and the Block Editor. No new APIs. No behaviour change on any of my client sites that I have been able to reproduce. That is the point.

It also arrives six days before WordPress 7.1 Beta 1 pins trunk on July 15, which is the actual reason to read this post now instead of next Monday. If your site is still on 7.0.0 when the 7.1 cycle opens, you are compounding two migrations in the same window. Take 7.0.1 first.

What is actually new

WordPress 7.0.1 is a short-cycle maintenance release led by Aaron Jorbin, Brian Haas, Carlos Bravo and Estela Rueda, announced on wordpress.org/news on July 9, 2026. It ships fixes for thirty-one bugs “throughout Core and the Block Editor, addressing issues affecting multiple areas of WordPress including the block editor, mail, and classic themes,” per the official announcement — that wording lifted verbatim from the 7.0.1 documentation page.

The changeset shape is worth reading. Block Editor changes are consolidated under a single sync commit (changeset 62610), which is exactly what the “Guidelines for Syncing Code From Gutenberg Into WordPress Develop” post described at the end of June — one rollup commit per minor for Gutenberg-side fixes, individual Trac tickets for Core-side fixes. This is the first maintenance release where that discipline shows up cleanly in the log.

The Core-side fixes cluster around a small number of components — Media (Media Library search bar position, spinner alignment, an image editor scale/crop input mismatch), the Editor admin (Block Visibility hide-everywhere behaviour, orphaned Gutenberg asset files, the Scale button on the image edit screen), an HTML API-adjacent hardening of wp_kses() around background-image: url() in inline CSS, a PHP 8.5 array-access fix in wp_get_attachment_image_src, and a set of admin UI regressions (mobile form elements, crowded Publish buttons, Network header logo). The RC1 announcement from July 1 is the canonical list; if you filter by ticket type you can see the Core side sits at thirteen tickets and the Gutenberg-side sync brings the remaining count up to thirty-one.

Two things are notable by their absence: no security fixes (this is not a security release), and no database update. The schedule Jorbin published on June 18 called for RC1 on July 1 and general release on July 9, and both hit on the day.

Why it matters for WordPress and WooCommerce people

WordPress 7.0 went out on May 20, 2026. Seven weeks to first maintenance release is on the long side for a modern major — 6.8 got its first dot in under three, 7.0 took a bit longer because the 7.0 cycle itself absorbed the real-time collaboration pull-out and the React 19 revert. The delay is not laziness; it is the release squad refusing to sync half-finished Gutenberg branches into a stable maintenance release. That is the healthy read.

For agency work, the practical implications are narrow but real. The wp_kses() fix on background-image: url() in inline CSS matters if you have themes or plugins that write inline styles for hero backgrounds or dynamic gallery covers — some of them were being stripped after 7.0.0. The PHP 8.5 wp_get_attachment_image_src fix matters if you have moved staging or production to PHP 8.5 already; the array-access change in 8.5 was strict enough to surface a latent bug that had been dormant for years. And the Block Visibility fix restores the “hide everywhere” semantics that a couple of block libraries depend on to gate whole blocks by role or context.

WooCommerce sites have a specific reason to update this week. WooCommerce 11.0 is scheduled for July 28, and its product object caching plus Action Scheduler 4.0.0 rollout will interact with WP core in a hot code path. Going into that on 7.0.1 is materially safer than going into it on 7.0.0 with fourteen unresolved regressions in the log. It is also cheaper to prove: 7.0.1 is a maintenance release, so a five-minute staging pass is enough for most stores.

The 7.1 timeline is the other pressure. Beta 1 pins trunk on July 15. RC1 is August 5. General release August 19. If you are testing plugins or themes against 7.1, you want to be doing it against a 7.0.1 baseline, not a 7.0.0 baseline with known bugs muddying the diff.

What I would do (or not do) about it

Update to 7.0.1 this week on every site on 7.0.0. This is a fifteen-minute job for a well-run agency: pull staging, run the update, click through the site editor and one or two admin screens, look for PHP warnings on the error log, promote to production. No database update to worry about, no data migration path to think about, no plugin compatibility matrix.

If a site auto-updates minor releases (the default), it is already done — 7.0.1 supports automatic background updates and most stores will have picked it up within twenty-four hours of July 9. Confirm via Tools → Site Health → Info → WordPress and move on. The people who need to actually intervene are the ones who have disabled auto-updates for a reason, and those are exactly the sites where I would run a real staging pass before promoting.

What I would not do is skip it and jump straight to 7.1 when Beta 1 arrives on July 15. Betas are not production. Every release cycle I watch a handful of teams try to shortcut the maintenance-release step because “we’ll just wait for the next major” — and every cycle at least one of them ships a regression they could have caught on 7.0.1 in July. Take the free pass.

I also would not run 7.1 Beta 1 on any production WooCommerce store. WooCommerce 11.0 lands July 28, three weeks before 7.1 general release, and the responsible sequence is 7.0.1 now, WooCommerce 11.0 on July 28 (after your own staging pass), WordPress 7.1 on or after August 19 once the field guide is out. Skipping steps costs more than the steps save.

The broader signal in 7.0.1 is quieter than the topline. The Gutenberg-sync discipline is holding. The release squad is publishing schedules and hitting them. The 7.0 cycle absorbed two significant pull-outs (RTC and React 19) without breaking the maintenance cadence. That is the WordPress governance layer doing exactly what it is meant to do — and it is why I still recommend WordPress for work that has to still be running in three years.