WordPress 7.0: What’s new? Everything You Need to Know About the Biggest Release in 8 Years
WordPress 7.0 was supposed to land on April 9, 2026, live on stage at WordCamp Asia in Mumbai. It didn’t. The core team pulled the release at the last minute to rework the database architecture behind the headline real-time collaboration feature. That’s probably the right call. This is the most significant WordPress release since the block editor arrived in 5.0 back in 2018, and getting it wrong would have been far worse than getting it late.
Here’s everything you need to know: what’s actually in the release, what’s been pushed to 7.1, when you’ll be able to install it, and how to prepare your sites.
What Happened to the April 9 Launch?
On March 31, release lead Matias Ventura posted on Make WordPress Core confirming the delay. The real-time collaboration (RTC) feature, which is the centrepiece of the entire release, had a performance problem in its data storage layer that needed an architectural fix rather than a late-cycle patch. The RTC implementation currently disables persistent post caches during active editing sessions, and the team identified risks around the database table design that could cause problems at scale across millions of WordPress installations.
The decision to return to a beta-like testing phase after already reaching RC2 is unprecedented in WordPress history. Pre-release builds were paused through April 17, and a revised release schedule is expected to be published no later than April 22. Current estimates from the community point to a final release somewhere around mid-to-late May 2026.
Everything else in the 7.0 feature set is ready to ship. The delay is specifically about getting the RTC database primitives right before they’re locked into core forever.
The Big Features in WordPress 7.0
Real-Time Collaboration (Phase 3 of Gutenberg)
WordPress 7.0 officially launches Phase 3 of the Gutenberg project: Collaboration. The goal is to move WordPress from a single-user editing tool to a team-based platform where multiple people can work on the same content simultaneously.
The implementation uses HTTP polling as the default sync transport, not WebSockets. This is a deliberate choice. HTTP polling works on every hosting environment without additional configuration. When a single user is editing, updates poll every four seconds. When collaborators are present, that drops to one second. WebSocket support is available as an optional enhancement for hosts that want to offer lower latency, but it’s not required.
Under the hood, the sync engine uses CRDTs (Conflict-free Replicated Data Types) stored as post_meta on an internal post type called wp_sync_storage. The architecture is designed so both the storage and transport layers can be swapped out by hosts or plugin developers. Updates are periodically compacted, requests are batched, and the client-side code initially limits simultaneous collaborators to two. This limit can be adjusted via a wp-config constant.
RTC will ship as opt-in, giving the ecosystem time to adapt. The decision on whether to enable it by default was being finalised around RC2, but the delay likely means this will be revisited.
Alongside real-time editing, the Notes system introduced in WordPress 6.9 has been significantly expanded. Users can leave inline comments on specific blocks or text fragments directly in the editor, with redesigned presence avatars, peer limits, and disconnection debouncing for stability.
The AI Infrastructure Layer
WordPress 7.0 doesn’t ship AI features in the way most people expect. It ships AI infrastructure, and the distinction matters.
A fresh install of WordPress 7.0 will not generate content, create images, or make automated suggestions by default. What it provides is a unified framework that lets the entire plugin ecosystem build AI-powered features on shared plumbing instead of each plugin rolling its own.
There are three components worth understanding:
The WP AI Client is a provider-agnostic PHP API baked into core. The entry point is wp_ai_client_prompt(), which returns a WP_AI_Client_Prompt_Builder instance with WordPress conventions (snake_case methods, WP_Error returns, integration with WordPress HTTP transport). You write your AI features against this single interface, and the site’s configured provider handles the rest. It doesn’t matter whether that’s Claude, GPT, Gemini, or a local Ollama instance.
The Connectors API is a new framework under Settings → Connectors where site owners configure their AI providers in one place. Three official provider plugins are available in the Plugin Directory at launch (OpenAI, Google, and Anthropic), and community-built providers for OpenRouter, Ollama, and Mistral have already been published. Once you add an API key, every AI-powered plugin on the site can use it. No more configuring separate API keys across five different plugins.
The Abilities API was first introduced on the PHP side in WordPress 6.9. The JavaScript counterpart lands in 7.0 via two new packages: @wordpress/abilities for state management and @wordpress/core-abilities for the WordPress integration layer. Plugins can register capabilities with input/output schemas, permission callbacks, and annotations. External AI tools like Claude, ChatGPT, Cursor, and VS Code can discover what your site can do and trigger actions through the MCP Adapter without custom integration code for every plugin.
The official AI Experiments plugin serves as the reference implementation, offering toggleable features including title generation, excerpt generation, alt text generation, image generation, review notes, content summarisation, and an Abilities Explorer.
One detail worth flagging for hosting providers: API keys stored through the Connectors UI are masked in the interface but not encrypted in the database. For production environments, credentials should be loaded through environment variables or PHP constants.
The Admin Redesign
The WordPress admin hasn’t had a meaningful visual update since the MP6 redesign in 2013. WordPress 7.0 changes that.
DataViews replaces the traditional WP List Tables that have powered the Posts, Pages, Users, and Media screens for over a decade. The new system introduces inline filtering without page reloads, multiple layout options (table, grid, list, and a new activity layout), and visual alignment between the block editor and classic admin panels. For developers, the DataViews and DataForm APIs provide standardised React components for building custom admin interfaces with consistent layouts, validation, and new controls like combobox and adaptive select.
Beyond DataViews, the refresh includes animated page-to-page transitions across wp-admin, replacing hard page reloads with smooth animations. There are unified form elements and a design token system that standardises colours, spacing, and typography. Font management gets its own dedicated screen at Appearance → Fonts. The Command Palette is now accessible from anywhere in the admin via ⌘K (or Ctrl+K).
The admin refresh is described as a “coat of paint” rather than a full redesign. Existing workflows and navigation patterns are preserved. But the DataViews migration is the highest-risk compatibility change in this release. Any plugin that modifies the Posts, Pages, or Media list views needs thorough testing.
New Blocks and Editor Improvements
Several features that previously required plugins or custom CSS are now native:
- Breadcrumbs Block. Works with custom post types, archives, and query loops out of the box.
- Icons Block. SVG icons from a pre-selected library, backed by a new server-side SVG Icon Registration API with a REST endpoint at
/wp/v2/icons. - Navigation Overlays. Customisable overlays for mobile menus, no longer experimental.
- Client-Side Media Processing. Image resizing, compression, and format conversion handled in the browser rather than on the server. Supports AVIF and reduces server load. This was temporarily reverted in Beta 6, so check the final release notes.
- PHP-Only Block Registration. Register and render blocks entirely from PHP with auto-generated inspector controls. No JavaScript build pipeline required.
- Pattern Overrides for Custom Blocks. Synced patterns can now include custom blocks with per-instance content edits, not just core blocks.
- Visual Revisions. Colour-coded overlays in the document inspector showing added blocks (green), removed blocks (red), and modified settings (yellow). Text-level diffs show additions as green/underlined and removals as red/strikethrough.
- Block Style Variation Previews. Live preview of style variations before applying them.
- Locale-Aware Formatting. Numbers and dates automatically formatted based on user locale.
The block editor also upgrades to React 19, which brings performance improvements but is a potentially breaking change for custom block developers.
PHP 7.4 Minimum Requirement
WordPress 7.0 drops support for PHP 7.2 and 7.3. The new minimum is PHP 7.4, with PHP 8.3+ strongly recommended for performance and security. Combined usage of PHP 7.2 and 7.3 had dropped below 4% of monitored WordPress installations globally, but the figure for individual hosting providers varies. Providers with older small business or legacy e-commerce customers will have a higher proportion.
Sites running PHP 7.2 or 7.3 will not receive the automatic update to 7.0. They’ll remain on the 6.9 branch, which receives security backports when possible but is not the actively maintained branch. The upgrade path is PHP first, WordPress second.
What’s Been Pushed to WordPress 7.1
Not everything made the cut. Several features were deferred to WordPress 7.1, currently targeted for August 19, 2026 to coincide with WordCamp US:
- Always-iframed post editor. Full enforcement of the iframed editor was revised to a gradual rollout in 7.0, with complete enforcement planned for 7.1. In 7.0, the post editor can be iframed when blocks use Block API version 3+.
- Core Abilities for post management. Creating, retrieving, and updating posts via the Abilities API needs further review.
- Playlist block and Dialog block. Neither finished in time.
- Third-party icon registration. The Icon block ships in 7.0, but extensibility for registering custom icon collections is planned for 7.1.
- Further Site Editor improvements and continued work on collaborative workflows.
- Improved media workflows and more granular user permissions.
WordPress 7.2 is expected around December 8 to 10, 2026, with an expansion of collaboration features and the first steps towards native multilingualism in core. The return to a three-release cadence in 2026, after only two major releases shipped in 2025, signals the project is re-establishing a sustainable rhythm.
When Will WordPress 7.0 Actually Ship?
As of April 12, 2026:
- The original April 9 date has passed. WordPress 7.0 was not released.
- Pre-release builds are paused through April 17 while the team finalises the RTC database design.
- A revised schedule will be published by April 22 at the latest.
- Community estimates suggest mid-to-late May 2026 for the final release.
- The current stable version is WordPress 6.9.4. This is what you should be running in production right now.
If you want to test now, nightly builds from the 7.0 branch are available via the WordPress Beta Tester plugin. Don’t run these on production.
How to Prepare for the Upgrade
Before the Release
1. Check your PHP version. If any of your sites are still running PHP 7.2 or 7.3, they cannot update to WordPress 7.0. Upgrade to PHP 8.2 or 8.3 on staging first, verify nothing breaks, then push to production. Do this now, not after the release.
2. Audit your plugins. Check the “Tested up to” version on every active plugin’s WordPress.org page. Plugins that modify admin list views (Posts, Pages, Media screens) carry the highest DataViews compatibility risk. Anything that hooks deeply into wp-admin screens needs attention.
3. Test custom admin CSS. The new design tokens and updated default styles may override custom dashboard stylesheets. If your theme or any plugin applies custom styles to the admin, test these carefully.
4. Review custom blocks. The React 19 upgrade and the move towards iframed editor rendering may affect custom blocks. Start migrating to Block API version 3 if you haven’t already.
5. Check hosting for collaboration. If you plan to use real-time collaboration, confirm your hosting supports the additional concurrent connections. HTTP polling works universally, but performance varies. WebSocket support is an optional enhancement that reduces latency.
When It Drops
6. Don’t auto-update production on day one. Wait for the first patch release (7.0.1 typically lands within a fortnight). Let the community surface issues and plugin vendors push compatibility updates first.
7. Test on staging. Clone your live site, run the update, and walk through critical user journeys: publishing, editing, WooCommerce checkout, contact forms, any custom functionality.
8. Back up everything. Full database and file backup before upgrading. This applies to every major WordPress update, but especially one with this many architectural changes.
9. Update the “Tested up to” field. If you maintain plugins or themes, update your readme to declare 7.0 compatibility as soon as your testing is complete. The plugins that ship 7.0-compatible from day one will pull users away from the ones that don’t.
Who Should Care and When
Update promptly, within the first week or two after 7.0.1. Editorial teams who write collaboratively, agencies running multi-author client sites, plugin or theme developers who want to build on the AI layer or new APIs.
Update carefully, after 7.0.1 lands with verified plugin compatibility. Most small business sites, WooCommerce stores, sites with extensive custom functionality.
Hold off until all critical plugins confirm “tested up to” 7.0. Sites running complex stacks of interdependent plugins, sites where downtime has direct revenue impact.
The Bigger Picture
WordPress 7.0 is arriving at an interesting moment. The same week the delay was announced, Cloudflare launched EmDash, a TypeScript CMS built in two months using agentic AI, released under MIT, and positioned as a direct challenger to WordPress. The competitive landscape is shifting, and the features WordPress 7.0 ships are exactly the capabilities a CMS needs to stay relevant as AI-native alternatives start appearing: real-time collaboration, a native AI client layer, and browser-based agent support via MCP.
The delay is frustrating for everyone who’d planned around April 9, but the core team chose stability over spectacle. For a release that changes database table design and introduces new sync primitives that millions of sites will depend on, that’s the right trade-off. Use the extra weeks to get your sites, plugins, and hosting environments ready.
WordPress 7.0 isn’t just an update. It’s the start of a shift from solo publishing tool to collaborative, AI-connected platform. Whether that shift works depends on what the ecosystem builds on top of these foundations, and that starts the day it ships.