WordPress 7.0 enters its final stretch, with everything locked in and focus shifting to polishing the last details.
Remember that you can listen to this program from Pocket Casts, Spotify, and Apple Podcasts or subscribe to the feed directly.
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 March 23 to 29, 2026.
Matt Mullenweg has opened a discussion on Make Core about the admin dashboard’s left sidebar menu. The problem is well known: any plugin can add menu items wherever it wants, with no established order, which means that on sites with several active plugins the menu ends up a hard-to-navigate mess.
Matt’s proposal is to establish a hierarchy: core WordPress items first, followed by a dedicated section for plugins, where heavyweight plugins like WooCommerce or an LMS would get their own top-level entry containing their entire universe. To prevent important plugins from getting buried at the bottom, he suggests allowing items to be pinned, or automatically surfacing the three most recently used plugins at the top.
The case for this change is straightforward: the current sidebar has no structural logic, and the experience on heavily-plugged installs is objectively bad. A clear hierarchy would also benefit AI agents and automation tools, which are increasingly interacting with the WordPress admin. It’s a real problem that has gone without an official solution for years.
What’s generating doubt in the community comes down to muscle memory. WordPress’s sidebar navigation has had a familiar structure for decades, and changing it means relearning. Several comments note that “recently used” lists could be particularly counterproductive, since the menu shifts position based on user behavior, making it impossible to build stable habits. Some would rather give users control to order the menu themselves — as plugins like Admin Menu Editor already do — rather than have a new structure imposed from core. Others question whether it would be more effective to start with a set of best-practice guidelines for plugin developers, without any code changes.
It’s an open conversation with no decisions made yet, but it’s significant that Matt himself started it on the Core blog.
It’s been an intense month of releases, so it’s worth a structured recap of everything that shipped and what’s still to come.
Starting with the 6.9 security releases. In early March, three maintenance releases shipped in under 48 hours. WordPress 6.9.2 fixed ten security vulnerabilities, but hours after release it caused some sites running classic themes to show a blank screen. The response was 6.9.3, published the same day. The following day it was discovered that three of the security patches from 6.9.2 had not made it into the package correctly, requiring 6.9.4. The security team later published a public retrospective acknowledging the process failure, identifying root causes, and committing to concrete improvements in the release checklist and in the automation of backports to older versions.
Running alongside that, the WordPress 7.0 betas. The beta cycle ran longer than planned. In addition to the five betas originally scheduled, an emergency Beta 4 was needed to include the 6.9.2 security patches, and a Beta 6 was required after performance issues were detected in real-time collaboration, the installation package size, and client-side image optimization. That last feature was temporarily reverted, real-time collaboration was made opt-in by default, and sync intervals were multiplied by four to reduce server load.
Release Candidate 1 arrived with 134 additional fixes over Beta 5. Beyond the usual fixes, it incorporated the AI Connectors screen and the command palette in the admin bar — features added outside the original beta cycle, deemed essential parts of the release’s core functionality.
Release Candidate 2, published just two days later, closes the translation string freeze period, giving the Polyglots team time to prepare translations for the final release.
WordPress 7.0 ships on April 9, 2026, coinciding with the Contributor Day at WordCamp Asia in Mumbai. If you have plugins or themes, now is the time to update the “Tested up to” field to 7.0 in your readme.txt.
The Core team has published two WordPress 7.0 dev notes aimed at developers, with important implications for understanding where the platform is heading.
The native AI client in WordPress 7.0 is integrated into core, meaning any plugin can send prompts to AI models without having to manage credentials or worry about which provider the site has configured. The entry point is wp_ai_client_prompt, which returns an object for building prompts in a fluent chain: text, temperature, max tokens, system instructions, response format, and more.
It supports text, image, audio, and video generation depending on the available provider. The most important thing for plugin developers is that the client completely abstracts the provider: the plugin describes what it needs and WordPress handles routing it to whichever model is available on that specific site.
The Skills API landed in WordPress 6.9 on the server side, allowing AI agents and automation tools to discover and execute WordPress functions in a structured way. In WordPress 7.0, its JavaScript counterpart arrives, with two packages: a generic one for state management that can be used in any project, and a WordPress-specific one that automatically loads all skills registered on the server via the REST API. Plugins can register their own skills in the browser, with input and output schemas, permission checks, and behavioral annotations. The practical significance is that it opens the door for AI agents to interact with WordPress directly from the browser, without needing server round-trips for every action.
Both APIs are designed to work together: the AI client manages conversations with models, and the Skills API exposes what WordPress can do so those models can act on the site in a structured and safe way.
The AI team had a week with two closely related highlights.
The first is the release of version 0.6 of the AI plugin, which brings functional updates along with an important rename. The plugin is no longer called AI Experiments — it is now simply called AI, a change that reflects its growing maturity as the central tool for AI features in WordPress. The most visible new feature in this version is AI-powered image editing directly from the Media Library: users can refine generated images through iterative prompts, edit existing images, and apply predefined actions such as expanding or removing backgrounds and replacing elements within an image. Internally, the plugin’s architecture has also evolved: experiments are now treated as a feature type in their own right, paving the way for the more mature ones to graduate to stable features in future versions.
The second highlight is the arrival of Guidelines in Gutenberg 22.7, an experimental feature that lets you define site-wide editorial standards from a new screen under the Settings menu. The idea is to have a centralized place to document tone of voice, image preferences, per-block-type rules, and any other editorial guidelines, so that both human editors and AI tools are working from the same source of truth. The feature includes JSON import/export and a revision history. For now it is an experiment that must be manually enabled in Gutenberg settings, but the team is already considering proposing it as a core feature for WordPress 7.1.
The Community team is testing a new marketing strategy to boost attendance at flagship WordCamps. The idea is to identify WordPress users with relevant local presence — photographers, artists, writers, content creators, businesses — who already use WordPress but have never participated in community events, and invite them personally.
The selection criteria targets people with more than 10,000 social media followers, or with significant investment in their online presence, who live near the event venue. The outreach is direct and personalized, with no mass-marketing methods. Those who accept can be integrated into the event program as speakers or panelists, or simply given visibility through interviews and pre-event content.
The team has already shared lists of local WordPress sites with the organizers of the three flagship WordCamps in 2026 — WordCamp Asia, WordCamp Europe, and WordCamp US. The specific execution will be left to each local organizing team.
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!
Leave a Reply