WordPress 7.0 Is Here — AI, a New Admin, and Everything That Has Changed

WordPress 7.0 shipped on May 20, 2026.
There is a lot to unpack here, but the short version is this: WordPress now has AI baked into core, the admin dashboard looks completely different, and a few editor features landed that people have been requesting for years. Real-time collaboration was supposed to be part of this release too, but it got pulled at the last minute.
Quick Answer
- AI providers like OpenAI, Gemini, and Claude can now be connected to WordPress through a single settings screen, and all plugins share that connection
- The old admin list tables (Posts, Pages, Media) have been replaced with DataViews
- Revisions now show visual diffs with colour coding instead of raw HTML
- Blocks can be shown or hidden per device (desktop, tablet, mobile) without plugins
- Breadcrumbs and Icons are now native blocks
- PHP 7.2 and 7.3 are dead. Minimum is 7.4, recommended is 8.3+
AI in WordPress Core
This is the big one, so it gets the most space.
Anyone who has worked with WordPress and AI over the past couple of years knows the situation. You install a content generation plugin, it asks for your OpenAI API key. You install an SEO plugin with AI features, it asks for the same key again. Maybe a third plugin does the same. None of these plugins know about each other. They each make their own API calls, store credentials in their own way, and if something goes wrong, good luck figuring out which one caused it.
WordPress 7.0 addresses this with three new systems that work together.
AI Connectors
Open Settings → Connectors in wp-admin. There is a new screen there. You add your API key for OpenAI, Google Gemini, or Anthropic Claude, and that is it. Every plugin on the site that needs AI access draws from this single configuration.
No more hunting through plugin settings to find where you entered a key. No more accidentally paying for duplicate API calls because two plugins hit the same endpoint independently. If you want to switch providers later, you change it in one place.
For anyone managing client sites, this cuts out a tedious piece of setup that used to eat time on every project.
WP AI Client
The AI Client is what developers interact with. It is a PHP API in core that routes requests to whatever AI provider the site owner configured in the Connectors screen.
Here is what a call looks like:
$response = wp_ai_client()->prompt(
'Generate a meta description for this post',
['context' => $post_content]
);
Write that once, and it works whether the site runs OpenAI, Gemini, or Claude. The developer does not deal with provider-specific response formats or authentication. WordPress handles the routing.
This is purely backend plumbing. Nobody will see it in the dashboard. But it is the reason AI plugins will stop being a collection of incompatible, competing integrations over the coming year.
Abilities API
This one is harder to explain, but it might end up being the most important piece.
The Abilities API lets AI models understand the structure of a WordPress site. Not just "this is a WordPress site," but the specific details: what post types are registered, what custom fields exist, what actions a plugin exposes, what the user is allowed to do.
It plugs into the Model Context Protocol (MCP), which tools like Claude already support. So instead of an AI assistant guessing at how your site works, it receives a structured description of the entire setup. Post types, taxonomies, capabilities, available operations — all of it.
If you build WordPress plugins, this changes how you write AI-powered features. You describe what your plugin can do through the Abilities API, and the AI provider knows how to work with it. No custom middleware, no bespoke adapters. The protocol handles the conversation.
A rough analogy: before this, asking an AI to help manage your WordPress site was like handing someone a set of tools and pointing them at a building with no blueprints. The Abilities API hands over the blueprints.
Why WordPress Did Not Ship an AI Writing Button
A lot of people expected WordPress 7.0 to ship with some kind of "generate content" button in the editor. It did not, and that was deliberate.
The core team built infrastructure instead. Pipes, not features. The reasoning is straightforward: thousands of developers already build AI tools for WordPress. Giving them a shared, stable foundation to build on is more useful than WordPress trying to ship its own AI content tool and competing with the existing ecosystem.
Yoast, Jetpack, and the dozens of smaller AI plugins out there will likely migrate to the AI Client within a few months. New plugins will build on it from the start. The fragmentation problem does not disappear overnight, but the path forward is clear now.
The New Admin
The admin list tables have been around since WordPress 2.x. You know them — the Posts screen, the Pages screen, the Media library. Same layout, same full-page-reload filters, same design language that stopped matching the rest of WordPress years ago.
DataViews replaces all of that.
Filtering happens inline now. Click a category, a status, an author — the list updates without reloading the page. You can switch between list view, grid view, and table view depending on what works for the content you are managing. Searching and sorting are noticeably faster, especially on sites with a lot of content.
The dashboard also got a visual update. Cleaner typography, a refreshed colour palette, better spacing throughout. It is not a dramatic visual redesign, more of a cleanup. But the admin no longer feels like two separate applications glued together — the block editor on one side and everything else stuck in 2012.
Command Palette
Cmd+K on Mac, Ctrl+K on Windows. This now works everywhere in wp-admin, not just inside the block editor. Search for a page, jump to a settings screen, trigger a quick action. If you have used VS Code or Figma, you already know this interaction pattern. Once you start using it, navigating through menus feels slow.
Editor Updates
Visual Revisions
WordPress has always saved post revisions, but the comparison view was not useful unless you could read HTML. The old screen showed two columns of markup with inline diffs. For most people, it was meaningless.
The new revision screen renders your content the way it looks in the editor and highlights changes with colour. Green for new content, red for removed content, yellow for edits. You look at it and immediately see what changed. That is it — simple, but long overdue.
Responsive Block Visibility
You can now toggle whether a block appears on desktop, tablet, or mobile. The setting is right there in the block sidebar.
Before this, showing different content on mobile versus desktop meant writing custom CSS, installing a visibility plugin, or asking a developer to handle it in the theme. Now a content editor can do it without code. A wide banner on desktop, a shorter version on mobile — handled directly in the editor.
Breadcrumbs and Icons Blocks
Two new native blocks. Breadcrumbs gives you a built-in breadcrumb trail without needing Yoast or a dedicated breadcrumbs plugin. The Icon block lets you drop SVG icons into your content and style them (colour, size, spacing) from the block settings.
Neither is groundbreaking, but both remove plugin dependencies that should not have been necessary in the first place.
Block-Level CSS
There is now an "Additional CSS" field in every block's Advanced panel. Editors can add custom styles to specific blocks without needing a code editor or access to theme files. It bridges the gap between "no code access at all" and "full theme development" — which is where a lot of everyday content work sits.
HTML Block Overhaul
The custom HTML block used to be a single text area where you dumped everything. HTML, CSS, JavaScript — all in one box. It got messy quickly, especially with third-party embed widgets that needed custom styling.
Now it splits into three tabs. Write your HTML in one, CSS in another, JavaScript in the third. Small change, but it removes a real annoyance.
Typography and Fonts
The font library used to be restricted to block-based (FSE) themes only. That restriction is gone. Every WordPress theme can now use it, accessible via Appearance → Fonts.
This matters because a large number of WordPress sites still run classic themes. Locking useful features behind block themes created an artificial pressure to switch, and not every site is ready for that migration. Removing the restriction is a sensible move.
Mobile navigation overlays are now customisable directly from the editor with device-specific controls. Menus can be saved as template parts and reused across the site.
Technical Details
PHP Version
WordPress 7.0 drops PHP 7.2 and 7.3. The floor is now PHP 7.4, with PHP 8.3+ recommended.
Most managed WordPress hosts have been on PHP 8.x for a while, so this will not affect everyone. But if you are on budget shared hosting or a self-managed server, check before you update. Running the upgrade on an unsupported PHP version will cause problems.
Performance
A few things under the hood:
- Block rendering is faster
- Database queries for pulling posts have been optimised
- Image and media processing can now happen client-side, which takes load off the server
- Lazy loading for images and iframes has been improved
None of these will show up in a changelog headline. On a site with lots of media or complex block layouts, the combined effect adds up. Faster page loads are always welcome.
What Got Pulled
Real-Time Collaboration
Google Docs-style simultaneous editing was supposed to be one of the main features of 7.0. It did not ship.
The core team ran into stability problems during testing. Synchronisation bugs under concurrent editing, server load concerns, and architectural issues that could not be resolved in time. They pulled it rather than shipping something that could corrupt content.
The plan is to revisit it for 7.1 or 7.2. Real-time collaborative editing is genuinely hard to build, especially on top of a system that was never designed for it from the ground up. Waiting for a stable version is the right call, even if it is disappointing.
Upgrading
WordPress 7.0 is worth the upgrade, but treat it like any major release.
Before updating:
- Check your PHP version. 7.4 minimum. No exceptions.
- Test on staging. Custom themes and plugins that rely on admin list tables may not work with DataViews yet. Find out on staging, not on your live site.
- Look at your AI plugins. If you have plugins with their own OpenAI or Claude integrations, they may conflict with the new Connectors system. Check for updates.
- Back up everything. This should go without saying for any major update, but it bears repeating.
What Comes After
WordPress is shipping three major releases in 2026:
- 7.0 — May 20 (this release)
- 7.1 — August 2026
- 7.2 — December 2026
Real-time collaboration is expected in one of those. DataViews will mature as plugin developers adopt it and push its limits.
Final Thought
WordPress 7.0 is a bigger deal than most version bumps. The AI infrastructure, the admin overhaul, the editor additions — these are not incremental improvements.
The AI piece is the one to watch. It does not do much that is visible right now, but it gives the plugin ecosystem a shared language for building AI features. That kind of foundational work tends to look quiet at launch and then reshape everything over the following year.
If you run a WordPress site, plan your upgrade and do not skip the staging step. If you build with WordPress, the AI Client and Abilities API are worth exploring now — before the rest of the ecosystem catches up and the patterns get set in stone.
On this page
0%
Perlat Kociaj
Full Stack Web Developer
Need help with yourWordPress upgrade?
Whether you are upgrading to WordPress 7.0 or building something new with its AI capabilities, I am happy to walk you through it.