WordPress 7.0 is the most anticipated major version since the block editor landed in 5.0. With WordPress 6.8 releasing in April 2026 and the roadmap entering a sharper Phase 3 focus, developers now have enough signal to plan seriously. This guide covers the confirmed 7.0 feature set, the realistic beta and RC schedule, what has shipped in the lead-up releases, and a practical prep checklist for developers building sites and plugins today.
One clarification upfront: WordPress 7.0 has no official release date as of April 2026. What we have are confirmed features in active development, a clear roadmap milestone (Phase 3: Collaboration), and a realistic projection window based on Gutenberg plugin shipping velocity. Everything below is grounded in Make WordPress posts, core trac tickets, and Gutenberg releases through version 19.x.
WordPress 7.0 Release Date: What We Know in April 2026
WordPress follows a predictable release cadence: two to three minor releases per year, each tracked on Make WordPress Core. Here is the current picture as of April 2026:
| Version | Release Date / Window | Key Features |
|---|---|---|
| WordPress 6.8 | April 2026 (released) | Pattern Overrides stable, Connectors API alpha, admin redesign progress, performance pass |
| WordPress 6.9 | Q3 2026 (projected) | Collaboration features shipping, async comments, Connectors API beta |
| WordPress 7.0 | 2027 or late 2026 (no official date) | Phase 3 complete, full collaboration stable, Phase 4 planning begins |
The honest answer to “when is the WordPress 7.0 release date?” is: when Phase 3 is done. The core team has consistently said 7.0 will mark the completion of a major Gutenberg phase, not a calendar deadline. Phase 3 (Collaboration) is in active development. The beta and RC schedule will be announced on Make WordPress Core 12-16 weeks before the release, following the same pattern used for 6.8.
Beta and RC Schedule Pattern
Based on WordPress 6.7 and 6.8 release cycles, expect the following structure when 7.0 enters the release phase:
- Beta 1: 12 weeks before release, core feature freeze
- Beta 2: 10 weeks, major bug fixes only
- Beta 3: 8 weeks, string freeze begins
- Release Candidate 1: 4 weeks before release
- Release Candidate 2: 2 weeks before release (if needed)
- Final release: after RC is stable for one week with no blockers
To track 7.0 development in real time: follow Make WordPress Core and the WordPress News blog. The Gutenberg plugin changelog is the most reliable leading indicator of what lands in core.
What Just Shipped: WordPress 6.8 (April 2026)
Understanding the 7.0 trajectory requires knowing what 6.8 delivered. It is the most Phase 3-adjacent release to date and sets the foundation for collaboration features in 7.0.
Pattern Overrides (Stable)
Pattern Overrides shipped as a stable feature in WordPress 6.8. They allow specific blocks inside a synced pattern to be customized per-instance without detaching the pattern. This is the first concrete piece of Phase 3’s editing model: patterns can now carry both locked and unlockable content in the same structure.
For developers, the implementation uses a new block attribute called metadata.bindings. A block inside a synced pattern can declare which attributes are overridable:
// Block attribute declaration in a synced pattern
{
"name": "core/paragraph",
"attributes": {
"content": "Default text",
"metadata": {
"id": "my-pattern-description",
"bindings": {
"content": {
"source": "core/pattern-overrides"
}
}
}
}
}
This means theme developers can ship patterns where structural elements (layout, spacing, colors) stay locked while editorial content (headings, text, CTAs) is editable per-use. It closes the gap between reusable patterns and per-page customization that has been a complaint since Reusable Blocks shipped in 5.0.
Connectors API (Alpha in 6.8)
The Connectors API is a new data integration layer in WordPress 6.8 that lets blocks source content from registered data providers. It extends the Block Bindings API into a formal registry for external data connections. In alpha state in 6.8, it is the mechanism that will power third-party integrations in 7.0.
The API works through a registration pattern:
// Register a connector source (plugin or theme)
add_filter( 'wp_block_editor_settings_all', function( $settings ) {
$settings['__experimentalConnectors'] = [
'my-plugin/product-data' => [
'label' => __( 'Product Data', 'my-plugin' ),
'fields' => [
'price' => [ 'label' => __( 'Price', 'my-plugin' ) ],
'availability' => [ 'label' => __( 'Availability', 'my-plugin' ) ],
'sku' => [ 'label' => __( 'SKU', 'my-plugin' ) ],
],
],
];
return $settings;
} );
When the Connectors API reaches beta in 6.9 and stable in 7.0, plugin developers can register data sources that appear in the editor’s binding UI. Users connect blocks to WooCommerce products, ACF field groups, or custom post meta without writing code. This is the architecture that separates 7.0’s data layer from the static template approach of 6.x.
Admin Interface Progress in 6.8
The WordPress admin modernization effort continued in 6.8 with updated typography scale in the dashboard, revised sidebar navigation spacing, and improved responsive behavior on tablet viewports. The full redesign targeting visual consistency with the block editor is a 7.0 deliverable, but 6.8 ships the incremental groundwork.
Phase 3: Collaboration Features in WordPress 7.0
Phase 3 of the Gutenberg roadmap is the development theme for WordPress 7.0. It covers real-time collaboration, async review workflows, and the editor infrastructure that makes multiple-contributor workflows native to WordPress instead of requiring external tools.
Real-Time Co-Editing
Multiple editors working on the same post simultaneously, with presence indicators showing who is in which block. The first iteration uses optimistic locking rather than full operational transformation: editors claim blocks, changes sync in near-real-time, and conflict resolution favors the most recent committed change. Full CRDT-based merging is planned for a post-7.0 iteration.
The Gutenberg plugin has shipped presence indicators and block-level locking in builds from Gutenberg 19.x onward. These are the co-editing primitives that 7.0 will stabilize.
Block-Level Revision History
WordPress has had post revisions since 2.6, but the UI treats content as an HTML string. The 7.0 revision UI understands block structure: diff at the block level, restore individual blocks from a previous revision, and attribute history per block. For teams where multiple contributors touch a post over days, this replaces the current “show full diff” model that is unreadable on complex structured content.
Async Block Comments
Inline comments on specific blocks, visible only to editors with editorial access, that follow a resolve workflow. The UX mirrors Figma comments and Google Docs suggestions: editors tag collaborators, add context to a specific paragraph or heading, and reviewers resolve comments when changes are accepted. For agencies running client review cycles, this removes the last reason to export to Google Docs for approval.
Connectors API: Deep Dive for Plugin Developers
The Connectors API is the feature most plugin developers should be watching. It formalizes how plugins expose data to the block editor and replaces the current fragmented approaches (custom REST endpoints, meta boxes, Gutenberg sidebar panels) with a unified binding layer.
Architecture Overview
The Connectors API sits on top of the Block Bindings API (stable since 6.5). Block Bindings lets you bind a block attribute to a data source; the Connectors API provides the editor UI that makes those bindings discoverable and configurable without code.
| Layer | Responsibility | Status in 6.8 |
|---|---|---|
| Block Bindings API | Server-side binding registration, value resolution | Stable (since 6.5) |
| Block Metadata Source | Post meta binding built in to core | Stable (since 6.7) |
| Connectors API | Editor UI for discovering and configuring bindings | Alpha (6.8) |
| Connector Registry | Formal plugin API for registering data sources | Experimental (6.8) |
What Plugin Developers Should Build Now
The alpha status means the API surface will change before 7.0. The right move now is to implement Block Bindings (stable) as the data layer and design your plugin’s data schema with the Connectors API in mind. Specifically:
- Use
register_block_bindings_source()today. This is stable and will not break. - Keep your data fields flat and labeled, the Connectors UI surfaces these labels to users.
- Avoid building custom sidebar panels for block configuration that duplicate what the Connectors UI will handle natively.
- Test against Gutenberg plugin releases, not just WordPress core, the alpha API is shipping there first.
Pattern Overrides: The New Design Contract
Pattern Overrides change the design contract between theme developers and site editors. Before Pattern Overrides, synced patterns were either fully locked (no customization) or fully editable (defeat the purpose of syncing). Pattern Overrides introduce a third state: locked structure, unlocked content.
Practical Use Cases
For theme developers shipping premium block themes, Pattern Overrides mean:
- A hero pattern where the layout, colors, and spacing are locked, but the headline, subtext, and CTA label are per-page editable
- A testimonial card pattern where the card structure is locked but the quote text and author name are customizable
- A pricing table where column layout is locked but prices, feature lists, and button labels are overridable
For plugin developers, Pattern Overrides integrate with the Connectors API: an overridable block attribute can be bound to a data source, so the “override” is not a manual edit but a live data connection.
Implementing Pattern Overrides
To make a block overridable inside a synced pattern, add the core/pattern-overrides binding to the attribute you want to unlock:
<!-- wp:heading {
"metadata": {
"id": "hero-headline",
"bindings": {
"content": {
"source": "core/pattern-overrides"
}
}
}
} -->
<h2 class="wp-block-heading">Your Headline Here</h2>
<!-- /wp:heading -->
In the Site Editor, users see this block with an “Override” indicator. They can type their own headline for this instance without detaching from the synced pattern. The pattern source retains the default text as the fallback.
The Four Phases of the Gutenberg Roadmap
WordPress 7.0 is defined by Phase 3. Understanding the full roadmap shows why the version number matters.
| Phase | Focus | Status (April 2026) |
|---|---|---|
| Phase 1: Easier Editing | Block editor, Gutenberg foundation | Complete (WP 5.0-5.9) |
| Phase 2: Customization | Full Site Editing, theme.json, block patterns | Complete (WP 6.x) |
| Phase 3: Collaboration | Real-time co-editing, revision history, async comments | In active development |
| Phase 4: Multilingual | Native multilingual content management | Early planning |
The version bump to 7.0 will happen when Phase 3 features are stable enough to ship as a cohesive set, not when an arbitrary version number is reached on a calendar schedule.
Additional Features Confirmed for the 7.0 Window
Interactivity API: Stable 1.0
The Interactivity API, introduced in 6.5, has shipped updates through 6.6, 6.7, and 6.8. The 7.0 release window finalizes the public API surface as stable 1.0. For developers building dynamic frontend behavior on block themes, this removes the last “experimental” qualification from the API that handles real-time filtering, cart updates, and interactive search without a JavaScript framework dependency.
// Interactivity API directive example (stable as of 7.0)
<div
data-wp-interactive="my-plugin/search"
data-wp-context='{ "query": "", "results": [] }'
>
<input
type="text"
data-wp-on--input="actions.updateQuery"
data-wp-bind--value="context.query"
/>
<ul data-wp-each--item="context.results">
<li data-wp-text="context.item.title"></li>
</ul>
</div>
Admin Interface Redesign (Full)
The admin modernization that began incrementally in 6.7 and 6.8 targets a complete stable release in 7.0. The redesign goal is visual and interaction consistency between the block editor and the broader WordPress admin, not a navigation overhaul. Menu structure and workflow patterns are preserved; typography, spacing, color system, and component styling align with the block editor’s design language.
REST API: Batch Requests and Custom Post Types
The REST API improvements targeting 7.0 include formal batch request support, more consistent filtering across custom post type endpoints, and improved support for the posttypes meta key used in template registration. For headless WordPress setups consuming the API, these reduce the custom handling currently required for edge cases in CPT queries and batch operations.
Performance: Continued INP Optimization
WordPress 6.8 continued work started in 6.7 on script loading strategy, autoload reduction, and block editor memory footprint. The 7.0 target is better Interaction to Next Paint (INP) scores on block editor loads, which affects both admin UX and collaboration feature responsiveness.
WordPress 7.0 Preparation Checklist for Developers
This is the practical checklist based on what is confirmed in development. Check these off now rather than scrambling when 7.0 enters beta.
For Theme Developers
- Upgrade to theme.json version 3, introduced in 6.6, version 3 is the format 7.0 targets. Audit your theme.json and update the schema version.
- Audit synced patterns, identify which blocks in your patterns should be overridable using Pattern Overrides. Document the intended override schema now.
- Test against Gutenberg 19.x+, run the Gutenberg plugin on a staging environment. Phase 3 UI changes land in the plugin months before core.
- Move to block-based themes, classic themes will not receive Phase 3 collaboration features. If you have not shipped a block theme, the 7.0 window is the hard deadline.
- Update
Tested up toheaders, keep theme headers current through 6.8 and 6.9 as they release.
For Plugin Developers
- Implement Block Bindings for any plugin that exposes block-level content. The Connectors API in 7.0 builds on this layer.
- Audit editorial workflow features, if your plugin handles approval workflows, editorial locks, or review queues, map how they overlap with Phase 3 native collaboration. Some features will become redundant; others will integrate with new hooks.
- Check
deferandasyncon all enqueued scripts, WordPress 7.0 is expected to enforce stricter defaults for script loading. Plugins without proper loading strategies will conflict with core’s loading strategy. - Test on PHP 8.2 and 8.3, WordPress 7.0 is expected to raise the minimum PHP recommendation. Common issues: deprecated dynamic class properties, stricter array handling, typed enums.
- Follow the Connectors API alpha, watch for phase changes from experimental to beta in Gutenberg plugin changelog. That is the right time to start prototyping.
For Site Owners and Agencies
- Stay current on minor releases, sites current on 6.8 and 6.9 will have a smooth 7.0 upgrade. Sites skipping minor versions accumulate debt.
- Verify hosting PHP version, confirm your host supports PHP 8.2+ before 7.0 ships. Switching PHP versions on a live site under deadline pressure is avoidable.
- Evaluate editorial tools, audit whether your team uses external tools (Google Docs, Notion, Figma comments) specifically for WordPress content review. Phase 3 will replace these workflows natively. Plan training updates.
- Run Gutenberg plugin on staging, early access to Phase 3 features lets you demo collaboration capabilities to clients months before 7.0 ships.
WordPress 7.0 and the Broader CMS Landscape
Phase 3 collaboration directly addresses the argument for switching to Contentful, Notion, or headless CMS platforms with native co-editing. Teams that moved to these platforms for inline comments and collaborative drafting will have functional parity in WordPress 7.0.
The Connectors API and Pattern Overrides address a different competitive pressure: the feature gap between WordPress and visual-first site builders like Webflow or Framer. By making structured content patterns flexible without sacrificing design control, WordPress 7.0 competes as a design system, not just a publishing tool. For a detailed look at how the Connectors API works at the plugin level, see our guide on WordPress Connectors and what plugin developers need to get right.
Phase 4 (Multilingual) is the next competitive gap. Native multilingual content management without WPML or Polylang is a documented request from enterprise users and a stated roadmap item for after 7.0. Design discussions for Phase 4 will likely become public during the 7.0 development cycle.
For developers who want to start building block themes now that will be ready for 7.0’s Pattern Overrides and Connectors API, the WordPress Block Theme vs Classic: Complete Developer Guide covers the migration decisions and architectural tradeoffs in depth.
Frequently Asked Questions
What is the WordPress 7.0 release date?
No official date has been announced as of April 2026. Based on current Phase 3 development velocity and the typical release cadence, a late 2026 or 2027 window is realistic. The official beta schedule will be posted to Make WordPress Core when the release cycle opens. Follow the Gutenberg plugin changelog for the most current development signals.
What is the WordPress 7.0 release date for the beta?
Beta 1 will be announced approximately 12 weeks before the release target. No beta date has been set as of April 2026. Historical pattern: beta announcements happen via Make WordPress Core with 2-3 weeks of advance notice. Subscribe to the Make Core blog for the announcement.
Will WordPress 7.0 break my existing site?
WordPress maintains a strong backward compatibility commitment. Sites on 6.x should upgrade without breaking core functionality. The risk areas are plugins that hook into editor JavaScript in ways that conflict with the Phase 3 collaboration layer, and themes or plugins relying on deprecated PHP functionality below the 8.2 minimum recommendation.
What is the Connectors API?
The Connectors API is a new data integration layer shipping in alpha with WordPress 6.8 and targeting stable status in 7.0. It lets plugins and themes register data sources that block authors can connect to block attributes through the editor UI, without writing code. It extends the Block Bindings API with a formal discovery and configuration interface.
What are Pattern Overrides?
Pattern Overrides let specific blocks inside a synced pattern be edited per-instance without detaching the pattern. They shipped as stable in WordPress 6.8. Theme developers use them to create patterns where structural design is locked but editorial content (headlines, CTAs, text) can be customized per page or post.
Do I need to update my theme for WordPress 7.0?
Classic themes continue working but will not benefit from Phase 3 collaboration features or Pattern Overrides in their full form. Block themes need to update to theme.json version 3 and audit synced patterns for Pattern Overrides compatibility. Start this work against WordPress 6.8 and the current Gutenberg plugin release.
WordPress 7.0 is not a vague future milestone anymore. The features are in active development in the Gutenberg plugin, the data API architecture is in alpha, and Pattern Overrides shipped stable in 6.8. The work you do today against the Gutenberg plugin and the Block Bindings API is direct preparation for the 7.0 upgrade path.
Developers who track Gutenberg plugin releases and test against the current plugin build will have months of compatibility testing completed by the time 7.0 enters beta. That is the only reliable preparation strategy: stay in the pipeline, not waiting outside it.
Prepare Your Stack for WordPress 7.0
We help agencies and dev teams audit custom blocks for Pattern Overrides compatibility, migrate to block themes, and test against the Connectors API alpha before 7.0 ships. Reach out if you need a 7.0 readiness review.
Admin Redesign Block Editor Connectors API Developer News Full Site Editing
Last modified: April 20, 2026










