September 16, 2026 — Gutenberg 24.0 shipped September 16 with three changes that each close a gap publishers have worked around for years: post titles now appear in the visual revision record, the Gallery block finally has a responsive grid an editor can configure without touching CSS, and a policy layer arrived in the dashboard that lets an admin govern what users are allowed to do. Where 23.8 pushed revisions outside the editor and 23.9 handed design-system enforcement to editors, 24.0 keeps extending two arcs at once — accountability and governance — and does it in the surfaces where a large newsroom actually gets burned.
Key Themes
- Visual revisions now cover the post title, so a rewritten headline shows up in the same diff view as body edits instead of vanishing without a trace.
- The Gallery block gained an editable grid variation with per-breakpoint column counts and crop control, replacing the old non-editable flex layout.
- A Policy provider landed in the dashboard, governing user actions, enforcing rules on the staging layer, and gating “Reset to default” behind a policy check.
- The extensible Site Editor kept rebuilding — view configuration now loads from an endpoint and a root error boundary stops a single failure from blanking the whole screen.
- The writing desk picked up a batch of small wins: list Tab/Shift+Tab indent-outdent, background images by URL, fit-text site titles, and an iOS Safari auto-capitalization fix.
Jump to: 📝 Post Titles Join the Revision Record · 🖼️ The Gallery Goes Responsive · 🛡️ A Policy Layer Lands in the Dashboard · 🧱 The Site Editor’s Second Draft Keeps Building · ✍️ Small Wins for the Writing Desk · 🔧 Smaller Updates · 💡 Takeaways
📝 Post Titles Join the Revision Record
Visual revisions now include the post title. Titles participate in the revision diff like any other content, so a reviewer dragging the revision slider sees exactly when a headline was changed and to what — no more guessing whether a rename happened in this edit or three edits ago (#82536, #82586). It is a targeted extension of the revisions work that has been shipping across the last several releases.
Why this matters: The headline is the single most-edited field in a newsroom. It gets rewritten for SEO, retested for click-through, softened for sensitivity, corrected for accuracy — often many times after a story goes live, and often by people who never touched the body. Until 24.0 every one of those changes was invisible in the revision history: the diff tracked the paragraph a copy editor moved but not the headline an editor quietly rewrote at 11pm. For a publisher, that gap is a real accountability hole — headline changes are exactly the edits that draw legal, standards, and audience-trust scrutiny, and “who changed this headline and when” was a question the platform couldn’t answer without a database query. Now it answers it in the same slider view everyone already uses. This is the revisions arc reaching the field that needed it most: 23.8 made revisions shareable and added a code diff, 23.9 gave that diff surrounding context, and 24.0 finally points it at the headline.
🖼️ The Gallery Goes Responsive
The Gallery block got a real grid. A new Grid variation replaces the old default flex layout — which was not editable — with a fully configurable grid that exposes per-breakpoint controls: a Column count and a Crop images to fit setting that can each be set independently for wide, tablet, and mobile viewports (#81909, #82003). A gallery can show four columns on a desktop and drop to two on a tablet without a line of custom CSS. The release also fixed a bug where “Crop images to fit” was broken in the editor (#82318) and tightened the crop button’s copy (#82617).
Why this matters: Galleries are not a nice-to-have for a media site — they are photo essays, product roundups, event coverage, and the image-dense modules that carry a visual story. And responsive behavior is where they always broke: the old flex layout gave an editor no say in how many columns rendered at each width, so getting a gallery to look right on mobile meant a developer writing breakpoint CSS or a bespoke block. That put every “can we show three across on desktop and two on phones” request into an engineering queue. Per-breakpoint column and crop control moves that decision to the person building the story, in the editor, at the moment they’re building it. It is also the responsive-styles arc — the per-block, per-breakpoint control that 23.2 and 23.3 introduced for spacing and typography — reaching one of the most visual blocks in the set. The pattern holds: take a layout decision that lived in custom CSS behind a deploy and hand it to the editor as a viewport-aware control.
🛡️ A Policy Layer Lands in the Dashboard
Governance moved from styling into user actions. The Widget Dashboard gained a Policy provider that governs what actions a user is permitted to take (#81967), policy is now enforced on the staging layer for instance operations (#82256), and the “Reset to default” action specifically is now gated through a policy check rather than being freely available (#82255). Alongside it, standalone Pages rendering now requires authentication and the right capability instead of rendering for anyone who hits the route (#82254).
Why this matters: This is the governance arc jumping tracks. 23.7 — the release this series called the Quiet Governance Release — made style inheritance visible; 23.9 added a drift detector so a design lead could find off-spec blocks. Both governed styling. A Policy provider that governs user actions is a different and more consequential thing: it is the platform starting to build a native seam for “who is allowed to do what” inside the admin, rather than leaving every capability decision to roles-and-caps plumbing and custom code. For a publisher running a large author pool under least-privilege — where a junior contributor, a staff writer, a section editor, and a syndication partner all touch the same install with very different permissions — a policy layer that can gate a destructive action like “Reset to default” is exactly the kind of guardrail that prevents an expensive mistake. Gating it on the staging layer matters too: it means the enforcement point sits where instance-level operations actually happen. And the Pages authentication fix closes a smaller but real hole — a standalone render route that didn’t check capability is the kind of access gap a security review flags. None of this is a finished governance framework yet, but the direction is unmistakable, and it’s the direction enterprise buyers have been asking about.
🧱 The Site Editor’s Second Draft Keeps Building
- The extensible Site Editor now loads its view configuration from an endpoint across Identity, Navigation, Pages, Patterns, Template Parts, and Templates, and uses canonical fields for the templates and patterns lists (#82692, #82138, #82666, #82672).
- A root error boundary now catches a failure before it blanks the entire screen, showing a recoverable error instead of a white page (#82486), and the “Add New Template” flow adopted the design-system focus ring in place of the legacy box-shadow (#82164).
Why this matters: The September developer roundup called this the Site Editor’s second draft, and 24.0 is that draft still being written. Driving view configuration from an endpoint is the load-bearing change: it turns the Site Editor’s screens from hard-coded UI into something the server describes, which is the groundwork for an editor an enterprise can extend and shape to its own content model rather than accept as shipped. The root error boundary is the less glamorous but more immediately valuable fix — a Site Editor that shows a recoverable error instead of a blank white screen is a Site Editor an editorial team can trust in production, because the failure mode stops being “the whole tool is gone.” For any publisher weighing whether to standardize on the block-based Site Editor versus a bespoke admin, both signals point the same way: the platform is being rebuilt to be extended and to fail gracefully.
✍️ Small Wins for the Writing Desk
- List indent and outdent by keyboard. Tab and Shift+Tab now indent and outdent fully selected list items, including multi-item selections, instead of doing nothing useful (#82460, #82411).
- Background images by URL. Background image support now accepts a direct image URL without requiring the asset to live in the Media Library (#82230).
- Fit-text site titles. The Site Title block can scale its text to the full available width via a toggle in the typography panel, instead of being pinned to a fixed point size (#82074).
- Cleaner query controls. The Query Loop filter formerly labeled “Keyword” is now “Search terms” with help text (#82387), and a reload-triggering modal was replaced with a less disruptive snackbar notice (#82246).
- Mobile authoring fix. Auto-capitalization after pressing Enter on iOS Safari was corrected (#82475), and non-breaking spaces are now visualized during editing (#74040).
Why this matters: None of these is a headline, and together they are the difference between an editor that fights the writer and one that gets out of the way. List keyboard control and the iOS capitalization fix target the two places authors spend the most time — structured text and mobile drafting — and both were small daily irritations that added up across a large desk. The “Search terms” rename and the snackbar-over-modal swap are the kind of clarity changes that reduce support tickets from non-technical authors. And background-image-by-URL quietly removes a step for teams pulling art from an external DAM or CDN instead of the Media Library. This is friction removal, not feature work, and it is the layer that decides whether writers trust the editor day to day.
🔧 Smaller Updates
The admin’s visual language got consistent. Nearly 100 icons were redrawn from a mix of filled and outlined styles into a single stroke-based set (#78812, #78808, #82338) — part of the same design-system rebuild that has been quietly reshaping the WordPress admin for several releases.
Media handling got more honest. Unattached uploads now attach to the current post on save or publish (#81977), server upload failures are reported in plain language (#81735), the editor stopped claiming “Upload complete” when every upload actually failed (#81397), and HEIC images are only blamed on browser codecs when they are genuinely undecodable (#82265) — all relevant to a photo desk moving large volumes of assets.
Performance hit the paths that scale. theme.json sanitization now avoids rebuilding identical block schemas (#82203), the ToolsPanel render cascade was cut (#82180), and rich text resolves its event listeners once instead of per subscriber (#80605).
Accessibility kept its cadence. The ProgressBar now respects reduced-motion preferences (#82490), and several contrast issues in form controls and the Connectors page were fixed (#82304, #82378).
The toolchain moved to Node 24. Gutenberg’s build moved to Node.js v24 LTS and npm v11 (#80395, #82355), the test suite continued its migration to Vitest, and the Command Palette’s search dropped the third-party cmdk library for the in-house wordpress/ui Autocomplete primitive (#82504). The release credits 80+ contributors, 8 of them first-timers. As always, confirm production is on a supported WordPress version before updating.
💡 Takeaways
- Fold headline changes into your editorial audit. Revisions now cover the post title, so brief your standards and copy desks that “who changed this headline and when” is finally answerable inside the editor — and update any review process that assumed it wasn’t.
- Rebuild your responsive galleries in the editor. Move photo essays and image roundups onto the new Gallery grid variation, set per-breakpoint columns and crop, and retire the custom CSS or bespoke blocks you built to get responsive behavior.
- Map the new dashboard policy layer to your role model. The Policy provider is early, but decide now which destructive actions — starting with “Reset to default” — you want gated for your lower-privilege authors, and track this arc if governance is on your platform checklist.
- Test the extensible Site Editor’s failure mode. The root error boundary is a real production-readiness signal; if you’re weighing the block-based Site Editor against a bespoke admin, confirm it recovers gracefully in your setup before you commit an editorial team to it.
- Plan for the Node 24 baseline. Gutenberg’s move to Node.js v24 and npm v11 is the trajectory your build tooling will follow — audit your local and CI environments so your own block development doesn’t fall behind the platform’s floor.
The full changelog is available on Make WordPress Core.