157. The Road to WordPress 7.2

We now know the roadmap for WordPress 7.2 — what’s being planned for this release, and what shouldn’t make it in.

Program transcript

Hello, I’m Alicia Ireland, and you’re listening to WPpodcast, bringing the weekly news from the WordPress Community.

In this episode, you’ll find the information from September 14 to 20, 2026.

WordPress 7.2 is slated for early December 2026, and the team has published the official roadmap for the cycle. As with every roadmap, the team itself notes that everything listed here is under active development, but nothing guarantees it will land as-is in the final release: it’s a roadmap of intentions, not a closed list of commitments.

The item that grabbed the most headlines this week is the default theme itself: it’s called Ipsum, and with it WordPress breaks a decade-plus tradition of naming its themes after their release year. Going forward, each default theme will have its own name and will change whenever the design calls for it, not on the calendar’s schedule. The backstory here is interesting: the team had spent months working on a much more ambitious and expressive theme, codenamed Mētis, meant to showcase everything Gutenberg can already do. After reviewing the direction with Matt, the criteria shifted: the theme bundled with WordPress should be the simplest possible starting point, leaving more elaborate design to exist separately. Mētis lives on as an independent project, but it won’t ship with this release.

Ipsum, named after the classic “lorem ipsum” filler text that occupies a page until the real content arrives, is a blank canvas built for blogs, with dashed lines simulating an editor’s pencil strokes, a handful of type pairings, and style variations that retint the entire page, images included. All the combinations meet WCAG AA. It’s already available to download and test from GitHub, with a very tight feedback window ahead of the 7.2 launch.

Notes, the editor’s internal comment system, takes its most ambitious leap yet: suggestion mode arrives, where instead of simply commenting on a block you can propose an actual text change for someone else to accept or reject — a huge step toward much more direct collaboration between people editing the same content. Also added: emoji reactions on notes themselves, and a dedicated shortcut in the block toolbar to add a note without leaving the writing flow.

The security section brings three heavyweight pieces. Conceptually the most eye-catching is the so-called “sudo mode”: a very early-stage feature proposing to require a one-time re-authentication for especially sensitive admin actions, even with an active session — common in operating systems but new to WordPress; for now only the intent has been announced, with a detailed proposal still pending. The second is the Secrets API, already covered in its initial proposal: it continues moving toward 7.2, with day-one support for WP-CLI while the admin interface is pushed to a later release. The third is a round of improvements and hardening for Application Passwords, with better detection of local environments versus HTTPS, email notifications when a new application password is added, and safer handling of the default role assigned to them. Alongside this is continued hardening work on the HTML processing API, so WordPress parses markup more safely and reliably across core.

The team’s message on AI is very clear and, to be fair, something of a brake: the 7.1 cycle made clear that AI features first need to demonstrate real adoption and practical value before being considered for core, so all the work in this area continues in the AI plugin, with no guarantee of landing in 7.2. Among what’s cooking: more WordPress Abilities, including the first write abilities and not just read ones; an update to the MCP adapter to the latest spec, with plans to publish it as a regular plugin in the directory; MCP activation with minimal configuration directly from the AI plugin itself; experimentation with WebMCP in in-browser agent workflows; an identity and delegation model so agents get an auditable identity with permissions manageable independently from human accounts; site context and editorial guidelines reusable across different AI features; shared embeddings support for semantic search; and AI response streaming in the PHP client.

The roadmap highlights four concrete high-effort accessibility fronts: making admin dashboard notices announce properly to assistive technology and easier to dismiss by keyboard; introducing automated axe-core tests to prevent regressions; allowing metabox reordering to be fully disabled, which has long caused visual-complexity issues and accidental changes on mobile; and removing widgets accessibility mode, to reduce the number of distinct management modes that need maintaining.

A new Description List block arrives, made up of three static blocks that serialize to the <dl>, <dt>, and <dd> HTML tags, following the same parent-and-child block pattern already used by Tabs or the List block, aimed at glossaries, technical specs, and any term-definition relationship. The Icon block completes its keyword search, so searching “hamburger” or “navigation” now also surfaces the menu icon. The Table of Contents block, which had been in experimental status for a long time, moves to dynamic server-side rendering to finally become stable, with editor and frontend sharing a single source of truth for the content’s headings. The Interactivity API gains a data-wp-html directive for rendering markup from the store within an interactive region, plus a clearer way for blocks to observe client-side navigation. And the React 19 upgrade keeps moving, though it’s unlikely to make it in time for 7.2.

One of the cycle’s more significant underlying changes: the extensible Site Editor is moving to a new foundation, built on the wordpress/boot routing package, already close to feature parity with the current editor. What matters here isn’t just the technical redesign, but that for the first time it’s opening up to third parties: a server-side view-configuration endpoint will let plugin authors register their own screens and settings inside the Site Editor itself, instead of having to build their own API from scratch every time. Other ongoing projects, like navigation editing, are already building on this foundation instead of duplicating work.

The DataViews and DataForms system keeps refining its extensibility, with view and form configuration registered on the server, and fields and actions also registerable there; as part of this, the post inspector itself — featured image, excerpt, status, date, author, or template — is being migrated to a DataForm, and help is already being requested to test that specific piece. The omnibar, introduced in 7.1, continues iterating with dashicons being replaced by SVG icons, command palette improvements, and ongoing accessibility review. And there’s a new round of improvements to error messages: clearer, easier to diagnose, and with a copy button to make them easy to search or share, following the defensive design principles Matt laid out a few weeks ago. The “On this day” widget also returns, having previously been attempted for 7.1 without success.

Form elements — buttons, text fields, dropdowns, and the previously missing label — will finally be stylable consistently straight from Global Styles, without touching theme.json by hand. The responsive styling introduced in 7.1 is being extended to more controls, with a public API so third-party blocks with custom controls can take advantage of it too. A custom “active” state can now be defined for interactive blocks, such as the current menu item in a navigation, starting with the Navigation Link block and the Tabs block. And, with renewed weight this time, the project to show Global Styles’ inherited styles directly in the block inspector is back — the feature that was shelved in 7.1 after several failed design attempts; now there’s the added question of whether to visibly indicate when a global value has been overridden locally, and how to offer a clear way to revert that change.

Client-side media processing, which debuted in 7.1, is now focused on maturing the system: hardening the upload process, expanding supported formats, and closing out pending performance work. The media inserter is being redesigned with very large media libraries in mind, with more sources for the dynamic gallery and sorting options for the static gallery. The 7.1 media-editing modal is focused on tracking the relationship between an original image and its crops, solving a real problem: today, each crop creates an independent attachment with no recorded link back to the original, which can end up filling the media library with loose duplicates. On performance, the focus is on removing script and style concatenation in favor of preloading, and on improved responsive images, with the Performance team’s Enhanced Responsive Images plugin available for anyone who wants to help test. And visual revisions, introduced in 7.0, keep being polished to make comparing and restoring changes smoother.

One deliberate, well-reasoned absence: real-time collaborative editing is not on the 7.2 roadmap, though work continues in parallel to the release cycle. The team acknowledges there are still important architectural decisions to resolve, and rather than list it here only to have to pull it later, as happened in previous cycles, they’d rather leave it out entirely for now.

While we wait for 7.2 to arrive, WordPress 7.1.1 is already here — the first maintenance release for 7.1. It brings 17 core fixes, 19 fixes in the block editor, and eleven security fixes, so it’s an update recommended immediately: the announcement itself stresses this, as is standard for any security release.

Among the fixed bugs are a stored XSS in wpautop() exploitable by a logged-out visitor via a comment pending approval; an issue in the HTML API that allowed escaping an HTML comment through abrupt closing sequences; a stored XSS in themes with custom-header support; specially crafted URLs that allowed an inactive theme to be automatically installed and previewed from WordPress.org; and an authenticated path traversal in the templates REST controller, reported once again by Anthropic.

The list continues with more heavyweight fixes: a site administrator could network-activate a network-only plugin without it being installed; XML-RPC allowed publishing customizer changes while bypassing the permission check for editing CSS; an arbitrary post overwrite by a Contributor, also reported by Anthropic; a missing permission check that leaked a private parent post’s title through attachment metadata; disclosure of a draft or pending post’s slug by a Contributor without proper authorization; and a bug that allowed any authenticated user to reassign a comment’s parent, notes included. As usual, the patches are being backported to every supported branch, from 4.7 through 7.0.

Gutenberg 24.0 is now available. The most practical addition is that visual revisions finally include the post title, which had been left out until now: seeing title changes alongside body-text changes avoids having to guess when something was renamed. The Gallery introduces a fully customizable grid variation replacing the old non-editable flexible layout, and both the column count and image cropping can be configured differently per device, so a gallery can show four columns on desktop and two on tablet without touching a line of CSS.

The Site Title gains a “fit-text” option, making the text scale to fill the available width instead of staying fixed at a set point size and either wrapping or falling short. Other highlights include a redesign of nearly a hundred icons toward a unified, stroke-based visual language, the ability to indent and outdent a full list item — or several selected at once — with Tab, background images that now accept a URL directly without having to go through the Media Library, and non-breaking spaces becoming visible while editing instead of staying invisible and silently changing the line break.

The Core team working on real-time collaborative editing has explained why the feature remains off the roadmap. The current design merges changes only in the browser, with no server involvement until someone saves, and that leaves three serious gaps: it doesn’t know who authored each change within a session, which could let unauthorized HTML slip in under someone else’s permissions; it can’t participate when an update comes in through the REST API or WP-CLI; and it can’t mediate when two people get out of sync, with a real risk of losing work.

The proposed solution is to make collaboration “server-aware”: instead of exchanging changes directly with each other, each person sends theirs to WordPress, which checks permissions, merges everyone’s changes, and resolves conflicts, rather than leaving it all up to the browser. The trade-off is more server load, so performance will need care, especially on more modest hosting.

There are three sync engines in testing, available as a plugin for anyone who wants to try them and give feedback: one based on the Yjs library, another using three-way merge that syncs only on save, and a third that logs short descriptions of each change instead of the full content.

The “AI-Powered WordPress” course is now live on Learn WordPress, designed to progressively walk through everything that has shipped with the canonical AI plugin since 7.0. It’s structured into four modules: the first three are aimed at anyone who manages or publishes on a WordPress site — owners, writers, editors, or administrators — with no coding required, covering everything from connecting your first AI provider via the Connectors screen, to using the editorial tools to draft, summarize, and classify content, automatically generating accessible alt text, moderating comments with sentiment and toxicity analysis, and controlling what AI is doing on the site through the request log and connector approvals.

The fourth module takes a leap into development, without assuming prior PHP experience, though it helps to have touched theme or plugin files before: it covers connecting assistants like Claude or ChatGPT to a site via the MCP adapter, registering a WordPress Ability so AI tools can discover a custom plugin’s functions, and using the WordPress AI Client to fire prompts from your own plugins and themes. The full course runs an estimated nine hours, requires a site running WordPress 7.0 or higher with admin access, and closes with a section on responsible best practices for publishing and building with AI in WordPress.

Fun anecdote: bbPress has jumped straight to 2.6.17, skipping 2.6.16, because John James Jacoby found a SQL bug right after tagging that version and chose to ship the fix without waiting. It’s another security and maintenance update. It hardens inherited visibility for private and hidden forums, BuddyPress group-forum limits, subscriber access checks, profile editing, REST API and XML-RPC requests, search results, canonical redirects, topic tags, moving replies, splitting topics, and output escaping in general.

The other major piece is a thorough overhaul of the maintenance and counter-repair tools — for topics, replies, forums, subforums, engagement, voices, and user contributions — which now behave better during moderation, moves, merges, splits, deletion, restoration, reassignment, and concurrent requests. Additionally, block themes now get first-class support while bbPress continues using its own PHP templates.

And finally, this podcast is distributed under a Creative Commons license as a derivative version of the podcast in Spanish; you can find all the links for more information, and the podcast in other languages, at WPpodcast .org.

Thanks for listening, and until the next episode!