WordPress 7.0.1 maintenance release ships 31 bug fixes
Released on , WordPress 7.0.1 is a short-cycle maintenance release that corrects 31 bugs across core and the block editor, seven weeks after WordPress 7.0 "Armstrong" shipped with AI capabilities in core. Read the WordPress release note here.
Maintenance releases rarely make headlines, and that is usually the point. They exist to clean up after a major version, and 7.0 was a large one. Armstrong reworked the admin interface, brought AI features into core, and introduced Visual Revisions. A release of that size always leaves a tail of regressions behind it, and 7.0.1 is the first pass at clearing them.
The fixes fall into three broad groups: things that broke in the 7.0 cycle and were caught late, things that were consciously deferred to keep 7.0 on schedule, and a handful of accessibility improvements that did not make the cut in May. Seventeen are core tickets. Fourteen come from the block editor. The release was led by Aaron Jorbin, Brian Haas, Carlos Bravo and Estela Rueda.
How it works
WordPress numbers its releases as major.minor.patch, and the middle number is where features arrive. 7.0 was a feature release. 7.0.1 is a patch on that branch, so it adds nothing new. The project restricts what can go into a patch: tickets qualify only if they fix an issue introduced during the 7.0 cycle, or if they were intentionally deferred at the end of it. That discipline is why a 31-ticket maintenance release is safe to install quickly, while a 31-ticket feature release would warrant a staging pass.
The distribution mechanism matters more than the version number. Since WordPress 3.7, minor releases install themselves on any site with automatic background updates enabled, which is the default. Most of the UK sites running 7.0 today will be on 7.0.1 within days without an administrator doing anything. That is a strength when the release is purely corrective, and it is the reason the project polices the contents of a patch so tightly.
If you want to see exactly what landed, the full list is on the project's issue tracker: the 7.0.1 milestone on core Trac lists every fixed ticket grouped by component, and the release candidate announcement published on 1 July enumerates them individually. Eight days elapsed between RC1 and the final build, which is a short window even by maintenance-release standards.
Three of the 31 tickets are build and test tooling rather than site behaviour: an improvement to the browserslist Grunt task, support for testing unmerged Gutenberg changes, and a guard on a PHP unit test. They matter to contributors and to nobody else. The other 28 change something a person can see or something a theme can do.
Examples and use cases
The single most consequential fix is ticket 65270. In 7.0, wp_kses() corrupted valid CSS, rewriting a background-image: url(...) declaration into style=")". The kses layer sanitises content submitted by users below Administrator level, so on a multi-author site an Editor or Contributor could save a section with an inline background image and silently destroy the style attribute. The content looked fine while it was being written and broke on save. Any UK agency running a client site with a distributed editorial team should assume this happened at least once between 20 May and this week, and go looking for it.
Ticket 65336 restores the ability to dequeue global-styles-inline-css, which had been impossible since 7.0. That stylesheet carries theme.json global styles, and dequeuing it is a standard optimisation for classic themes and for custom builds that never use global styles in the first place. Losing that control in 7.0 meant an unavoidable block of inline CSS on every page, which is a small but measurable performance cost on a site that had deliberately eliminated it. Related, ticket 78493 fixes a black flash on wp-admin pages before hydration, which was cosmetic but jarring on every single admin page load.
Ticket 64742 fixes an incorrect array access in wp_get_attachment_image_src under PHP 8.5. PHP 8.5 is recent enough that few production sites are on it, but hosts move fast and the error surfaces wherever an attachment image is requested, which is nearly everywhere. If you are planning a PHP upgrade this quarter, 7.0.1 is a prerequisite rather than an optional step.
The rest cluster around the interfaces people use daily. The admin reskin left form elements unstandardised in the mobile viewport (64999) and crowded the publishing action buttons in the Publish settings panel (65286). The media library shipped with a misaligned loading spinner in the modal filter toolbar (65275) and a search bar that jumped position after a search (65296). The image editor's scale and crop inputs disagreed with the button beside them (64937), and the scale button itself sat out of alignment with the dimensions field (65428). Individually these are irritations. Collectively they describe an admin interface that was rebuilt in a hurry.
On the block editor side, the Navigation block gets two fixes: a deprecated shim restoring block_core_navigation_submenu_render_submenu_icon() for themes that called it directly (78484), and correct use of block context to determine whether a Page List sits inside a Submenu (79048). Four tickets improve accessibility, covering the Visual History interface (65122), a non-colour secondary indicator for diff blocks in revisions (78393), a missing aria-label on the image lightbox trigger (78426), and focus movement to the revisions slider when entering revisions mode (79691).
What this means for UK site owners
For most sites, nothing. The update installs overnight and the experience improves slightly. That is the intended outcome, and the honest advice for a straightforward brochure site on a well-supported theme is to let automatic updates do their job and move on.
The sites that need attention are the ones with custom code touching the areas 7.0.1 changed. If a theme dequeues core stylesheets, the global-styles fix changes behaviour. If a theme calls the Navigation submenu icon function directly, it now resolves through a deprecated shim rather than failing, which is a reprieve rather than a fix: deprecated shims get removed. If a plugin filters content through kses in a custom flow, the CSS sanitisation change alters what survives. None of these will break a site on update, but all of them are worth a look before 7.1 arrives in August and the deprecation window starts closing.
The multi-author case deserves a second mention because it is the one with content already damaged. If a client's team has been publishing through Editor or Contributor accounts since late May, inline background-image styles in that content may already be corrupted, and installing 7.0.1 does not repair what was saved. It stops the bleeding. Finding and fixing the affected posts is a manual job, and it belongs on a WordPress maintenance checklist this month rather than a discovery six months from now when someone notices a hero section has lost its background.
There is also a planning signal here. WordPress 7.1 is scheduled for 19 August 2026, timed to WordCamp US. That is roughly six weeks out. If you are commissioning a new WordPress build or a theme rebuild in that window, it is worth knowing that the platform you are building against will move underneath you before the project ships, and that 7.0's regression tail suggests 7.1 will have one too.
Practical considerations
Treat "maintenance release" as a description of intent rather than a guarantee of safety. The 7.0.1 fixes are narrow, but two of them change how themes interact with core output, and one changes what the sanitiser permits. A ten-minute staging check on a site with a custom theme is cheap. Skipping it on a site with a bespoke block library is not brave, it is just untested.
Be aware of what this release does not do. It contains no security fixes, so it does not close a known vulnerability, and it does not address anything in the AI features that 7.0 introduced into core. Those remain as shipped. If you were waiting for 7.0.1 to resolve a specific complaint about Armstrong's AI behaviour, check the Trac milestone before assuming your ticket is in it.
Finally, the eight-day gap between release candidate and final build is worth registering. It is short. The project's own guidance is that maintenance releases carry lower risk precisely because their scope is constrained, and that logic holds. But a compressed RC window means less community testing than a feature release receives, and the sites most likely to surface an unexpected interaction are the ones with the most custom code. That is not an argument against updating. It is an argument for updating with a backup you have actually verified restores.
FAQ
Is WordPress 7.0.1 a security release?
No. WordPress 7.0.1 is a bug-fix maintenance release. The announcement does not list any security fixes, and the release notes describe it as a short-cycle maintenance release covering issues introduced during the 7.0 cycle or deferred at the end of it. You should still install it promptly, because several of the fixes address regressions that break real editing and publishing workflows.
Will WordPress 7.0.1 install itself?
On any site that supports automatic background updates, yes. Minor releases are applied automatically by default, so most sites will move to 7.0.1 without anyone touching them. If you have disabled automatic updates, or your host manages core versions for you, you will need to trigger the update from Dashboard, then Updates, then Update Now.
What was the wp_kses bug and does it affect my site?
Ticket 65270 records that wp_kses() corrupted valid CSS background-image: url() declarations, rewriting them into style=")". It affects content saved by users whose input passes through kses filtering, which in practice means Editors, Authors and Contributors rather than Administrators on a single site. If your team publishes sections with inline background images, check recently edited content for broken styles.
How many of the 31 fixes are actually user-facing?
Most of them. Seventeen are core tickets and fourteen come from the block editor. A small number are build and test tooling, such as improvements to the browserslist Grunt task and support for testing unmerged Gutenberg changes. The remainder cover the admin interface, the media library, the image editor, the Navigation and Custom HTML blocks, the revisions interface and accessibility.
When is the next major WordPress release?
WordPress 7.1 is scheduled for 19 August 2026, timed to WordCamp US. That is the next release that will introduce new features. Anything numbered 7.0.x before then will be a maintenance or security release on the 7.0 branch.
Should I test 7.0.1 on staging before it reaches production?
For a simple site running well-maintained plugins, the automatic update is fine. For anything with a custom theme, a bespoke block, or a plugin that dequeues core stylesheets, test first. The fix restoring the ability to remove global-styles-inline-css and the deprecated Navigation submenu shim both change how themes interact with core output, so a staging pass is worth the ten minutes.
