Why is WordPress 7.0 considered a major release?

WordPress 7.0 is the first X.0 major release since WordPress 5.0 in December 2018. It introduces the platform's first native AI infrastructure (WP AI Client), the first native Real-Time Collaboration feature (simultaneous editing with CRDT conflict resolution), and a complete admin interface refresh with DataViews replacing the legacy WP_List_Table. These are architectural changes that define the platform's next decade, which justifies the major version bump.

Is the block editor iframe sandboxing a breaking change?

Yes, it is a breaking change for any theme or plugin that queries the DOM from the parent window while the editor is open. WordPress 7.0 runs the block editor in a fully sandboxed iframe. JavaScript that uses document.querySelector() or jQuery from outside the iframe to manipulate editor content will stop working. Code must be moved inside the iframe context. This affects some older plugins that used jQuery-based editor customizations.

What are the minimum server requirements for WordPress 7.0?

WordPress 7.0 requires PHP 7.4 minimum (PHP 8.3 recommended), MySQL 8.0 or MariaDB 10.6 minimum. PHP 7.4 reached end of life in November 2022 – if you are on 7.4 to meet the minimum requirement, upgrading to PHP 8.2 or 8.3 is strongly recommended for security and performance reasons. Running the current recommended version is always better than staying at the minimum.

How does WordPress Real-Time Collaboration handle edit conflicts?

WordPress 7.0 uses CRDT (Conflict-free Replicated Data Types) for collaborative editing conflict resolution. CRDTs are mathematical data structures that can be merged automatically without conflicts, regardless of the order in which changes arrive. When two editors modify the same block simultaneously, CRDT merges both changes deterministically. The default configuration allows up to two simultaneous editors per post; this limit is configurable via the wp_collaboration_max_editors filter.

Know-how

WordPress 7.0 – WP AI Client, Real-Time Collaboration, Interactivity API 1.0, and What's New

Q: What is wp_sync_storage and why was the wp_collaboration table controversial?

Early WordPress 7.0 development planned a new wp_collaboration database table for storing Real-Time Collaboration state. This sparked debate in the WordPress community because plugins already store similar ephemeral data in post_meta. The final implementation uses wp_sync_storage with a 'post_meta' type – storing collaboration state in the existing post_meta table structure rather than a new table. This resolved the debate but means collaboration state shares the post_meta table, which can grow significantly on busy collaborative sites.

Published: April 10, 2026 · Author: Marcin Szewczyk-Wilgan

WordPress 7.0 is the first X.0 major release since WordPress 5.0 shipped with the Gutenberg block editor in December 2018. That eight-year gap between major version numbers is not accidental: the WordPress team uses the X.0 designation for releases that define the platform's direction for the next decade. WordPress 7.0 earns that designation with three genuinely new platform capabilities: native AI infrastructure, real-time collaborative editing, and a stable Interactivity API. On top of these, the admin interface gets its most significant visual and structural refresh in years. This article covers everything developers and site operators need to know about WordPress 7.0.

Release Timeline and Roadmap

WordPress 7.0Spring 2026. The initial release was delayed by an extended discussion about whether Real-Time Collaboration state should be stored in a new wp_collaboration database table or reuse the existing post_meta structure. The final implementation uses wp_sync_storage with a post_meta type, storing collaboration data in post_meta rather than a new table.

WordPress 7.1August 2026. Planned additions: always-iframed block editor (completing the iframe sandboxing begun in 7.0), new core blocks (Tabs, Dialog/Modal, Playlist), and Core Abilities shipped as part of the Abilities API.

WordPress 7.2December 2026. Phase 4 of the Gutenberg roadmap: native multilingual support. After years of relying on third-party plugins (Polylang, WPML, TranslatePress), WordPress will have built-in language management.

Real-Time Collaboration

Collaborative editing – multiple users editing the same post simultaneously with live updates – is WordPress 7.0's most visible new capability for content teams.

Transport mechanismReal-Time Collaboration uses HTTP polling as the default transport: the editor polls for updates every 4 seconds normally, or every 1 second when the user is actively typing. WebSocket support is optional and must be explicitly configured. HTTP polling was chosen for compatibility with shared hosting environments that do not support persistent WebSocket connections.

Conflict resolutionWordPress uses CRDT (Conflict-free Replicated Data Types) to merge concurrent edits without conflicts. When two editors modify the same block simultaneously, CRDT merges both changes deterministically regardless of network latency or message order. This is the same technology used by Figma, Notion, and Google Docs.

StorageCollaboration state is stored using wp_sync_storage with the post_meta type. This stores collaboration data in the existing post_meta table rather than a dedicated table. On busy collaborative sites with many simultaneous editors, post_meta can grow significantly and may require more aggressive cleanup routines.

Editor limitsBy default, WordPress 7.0 allows up to 2 simultaneous editors per post. This limit is configurable: add_filter('wp_collaboration_max_editors', function() { return 5; });. Higher limits increase the complexity of CRDT merge operations and the polling load on the server.

Notes featureAlongside collaborative editing, WordPress 7.0 adds an inline Notes feature: editors can attach formatted comments to specific blocks or passages, similar to Google Docs comments. Notes support @mentions of other users and appear in a sidebar panel. They are stored separately from post content and can be resolved and archived.

WP AI Client

WordPress 7.0 ships with native AI infrastructure for the first time. See the dedicated WordPress and AI article for full coverage. The core architecture in brief:

Provider agnostic

wp_ai_client_prompt()

The wp_ai_client_prompt() function returns a fluent builder for AI prompts. The underlying provider is determined by Settings → Connectors, not by the calling code. Plugins built for WP AI Client work with any configured connector (OpenAI, Anthropic, Google, Ollama) without modification.

Connectors

Settings → Connectors screen

WordPress 7.0 adds a Settings → Connectors admin screen for configuring AI providers. Official connectors ship for OpenAI (GPT + DALL-E + TTS), Anthropic (Claude), and Google (Gemini with web search grounding). Community connectors add OpenRouter, Ollama, and Mistral.

AI Experiments

Opt-in core AI features

Opt-in core features include: automatic excerpt generation, alt text suggestions for uploaded images, content summaries, and AI-assisted image generation. All disabled by default, enabled in Settings → AI Experiments. All use the active connector and the bring-your-own-key model.

API key security

Use environment variables

WP AI Client masks keys in the admin UI but stores them unencrypted in the database. For production sites: store keys in server environment variables, referenced via getenv() in a custom connector configuration. Database-stored keys are exposed by any database backup or SQL injection.

Admin Interface Refresh

WordPress 7.0 replaces the core admin list tables and forms with a modern component system.

DataViewsThe legacy WP_List_Table PHP class is replaced by DataViews – a React-based component that renders as a table, grid, or list view. DataViews supports inline editing, column resizing, bulk actions, and persistent view state. Pages, posts, users, and media all use DataViews in WordPress 7.0. Third-party plugins using WP_List_Table continue to work but render with the older appearance.

DataFormDataForm replaces standard WordPress meta boxes and settings forms with a unified component system. New form control types include combobox (searchable dropdown) and adaptiveSelect (context-aware dropdown that adjusts options based on other field values). DataForm is used for the post editor sidebar panels and settings screens in WordPress 7.0.

View TransitionsWordPress 7.0 adds View Transitions API support to admin navigation – page transitions in the wp-admin area are animated rather than hard page loads. The effect is subtle but makes the admin feel significantly more responsive. Requires a browser that supports the View Transitions API (Chrome 111+, Safari 18+, Firefox 130+).

"Modern" color schemeA new "Modern" admin color scheme is available in Users → Profile. It uses a lighter, higher-contrast palette with updated typography. The classic color schemes remain available. "Modern" is not the default to avoid forced visual changes for existing users.

Interactivity API 1.0

The Interactivity API, introduced experimentally in WordPress 6.5, reaches stable 1.0 status in WordPress 7.0 with two significant additions.

watch()

Reactive side effects

The new watch() function lets you register side effects that run automatically when reactive state values change. store('my-plugin', { state: { count: 0 }, init() { watch(() => { document.title = this.state.count + ' items'; }); } }); – the title updates automatically whenever count changes, without manual event binding.

state.url

Server-side URL state

state.url is a new reactive property initialized server-side with the current page URL. This enables server-rendered Interactivity API components to include the current URL in their initial state, which was previously difficult without client-side JavaScript initialization. Particularly useful for search and filter components.

state.navigation deprecated

Navigation API changes

state.navigation is deprecated in WordPress 7.0. Navigation state should now be managed through state.url and the standard browser History API via the Interactivity API's router. Plugins using state.navigation will see deprecation notices and should migrate to the new pattern.

PHP-only blocks

Blocks without JavaScript

WordPress 7.0 introduces the concept of PHP-only blocks: blocks that render entirely server-side with no client-side JavaScript bundle. For blocks that display server-rendered content without interactive features, this eliminates unnecessary JavaScript loading. Register with 'render_callback' => 'my_render_fn', 'script' => false.

Block Editor Changes

WordPress 7.0 brings several block editor changes, including one breaking change that plugin and theme developers must address.

Iframe sandboxing (breaking)WordPress 7.0 runs the block editor in a fully sandboxed iframe. JavaScript that queries the DOM from the parent window while the editor is active will stop working. This affects plugins using document.querySelector(), jQuery DOM manipulation, or any code that assumes the editor content is in the same document as the admin page. Move such code inside the editor's iframe context using wp.blocks or wp.data APIs.

Icons blockA new core Icons block provides access to the full WordPress Dashicons set and common SVG icons directly in the block editor, without requiring a plugin. Supports size, color, and alignment controls.

Breadcrumbs blockA new core Breadcrumbs block generates Schema.org-compatible breadcrumb navigation automatically from the current page's position in the site hierarchy. Replaces common plugin-based breadcrumb solutions for most use cases.

Lightbox galleryThe Gallery block gains a native lightbox mode: clicking an image opens a fullscreen overlay with keyboard navigation and swipe support. No plugin required for this common pattern. The lightbox uses native browser APIs and is accessible by default.

Responsive block visibilityAll blocks now support responsive visibility controls: show/hide on mobile, tablet, or desktop breakpoints directly from the block inspector. Previously requiring a plugin (Block Visibility, Kadence Blocks), this is now a core feature available for every block.

Block Bindings APIThe Block Bindings API (experimental since 6.5) is stable in WordPress 7.0. It lets block attributes be bound to dynamic data sources: custom fields, post metadata, or custom data providers registered by plugins. This enables building fully dynamic blocks without JavaScript – the binding and rendering happens server-side.

System Requirements

PHPMinimum: PHP 7.4. Recommended: PHP 8.3. Note that PHP 7.4 reached end-of-life in November 2022 and no longer receives security patches. Running a site on PHP 7.4 to meet the minimum requirement exposes the server to known, unpatched PHP vulnerabilities. Upgrade to at least PHP 8.2 before deploying WordPress 7.0 in production.

DatabaseMinimum: MySQL 8.0 or MariaDB 10.6. WordPress 7.0's Real-Time Collaboration and DataViews features use JSON column types and window functions that require these minimum versions. Earlier MySQL/MariaDB versions are not supported.

Web serverNo change from previous requirements. Apache 2.4+ or Nginx 1.20+ with PHP-FPM. HTTPS is required for Real-Time Collaboration – the WebSocket transport and several browser APIs used by the collaboration features require a secure context.

Upgrade Checklist

Before upgrading to WordPress 7.0, work through these seven steps:

1. Verify PHP and database versionsConfirm your server runs PHP 7.4+ (8.2+ strongly recommended) and MySQL 8.0+ or MariaDB 10.6+. Check via phpinfo() or WordPress Site Health (Tools → Site Health).

2. Test on stagingCreate a staging copy of your production site and upgrade it to WordPress 7.0 first. Verify all plugins and theme functionality before touching production.

3. Check for iframe DOM queriesSearch your active plugins and theme files for document.querySelector, $('#editor'), or any JavaScript that targets the block editor from outside it. These will break with the iframe sandboxing change.

4. Update all plugins and themesEnsure all active plugins and the active theme have been updated to their latest versions before upgrading WordPress core. Many plugin developers released WordPress 7.0 compatibility updates ahead of launch.

5. Back up everythingFull backup of files and database immediately before the upgrade. Confirm the backup is complete and restorable before proceeding. Store it off-server.

6. Perform the upgradeUpgrade WordPress core, then update all plugins and themes. Do not update plugins and core simultaneously – if something breaks, you need to know which update caused it.

7. Verify functionalityTest: frontend page load, admin panel access, post creation and editing in the block editor, any custom blocks or editor extensions, form submissions, WooCommerce checkout (if applicable), and user login/logout.

Summary

WordPress 7.0 is not a release where the main question is "should I upgrade?" – it is a major version that sets the platform's direction for the coming years. The practical questions are "when?" and "what do I need to fix first?" For most sites, the answer to when is: after testing on staging and confirming plugin compatibility, within the first month of release. What to fix first: the iframe sandboxing breaking change for any site with custom editor JavaScript, and PHP version if still running below 8.0. Everything else – AI features, collaborative editing, DataViews – is additive and can be adopted at whatever pace makes sense for each site.