The future of WordPress: 2026-2030 roadmap and beyond

In 2015, the WordPress conversation was about the REST API. In September 2026, with 7.1.1 as the stable release, it is about who gets to edit a post at the same time, what an AI agent is allowed to call, and whether you can get your content out of a closed builder without hand copying it.

Two numbers frame the rest of this page. W3Techs measured WordPress at 40.2% of all websites and 58.8% of sites with a known CMS on 20 September 2026, down from 43.2% of all websites in December 2025. The roadmap is a response to that slope, not a victory lap. The launch of Cloudflare’s EmDash CMS is one visible piece of the same pressure.

What follows is the roadmap checked against core, release by release. Where a feature is real, you get the function name. Where it is still a discussion, it says so.

#Does WordPress have real-time collaboration in 2026

The wordpress.org roadmap names four Gutenberg phases: Easier Editing, Customization, Collaboration, Multilingual. Phase 3 is the active one, and it has been partially delivered.

Notes shipped. Block-level commenting landed in WordPress 6.9 on 2 December 2025, after an experimental run in the Gutenberg plugin. It was renamed from “block comments” to Notes specifically to keep it distinct from the wp_comments feature readers use. The first release covers adding, threading, resolving and deleting notes on a whole block, not on a selection inside a block. Viewing or creating one requires the edit_post capability, because notes only exist inside the post editor.

WordPress 7.1 extended it rather than replacing it: email notifications for at-mentions inside Notes, shareable revision links, and a fix so Notes no longer leak into comment feed queries. That last one is the sort of detail worth knowing before you file a bug: a custom comment feed built on 6.9 could see note records it never asked for.

Real-time collaboration did not ship. It reached core as a beta feature and was then pulled. The 11 March 2026 call for testing asked people to install WordPress 7.0 Beta 1 on a server somebody else could reach, switch on “Enable real-time collaboration” under Settings > Writing, and open the same post from two accounts. On 8 May 2026 it was removed from 7.0, and the reasons given are the useful part: surface area, race conditions, server load, memory efficiency, and bugs that kept surfacing through fuzz testing. It is not enabled in 7.1 either. The sync layer is built on Yjs, and the core/freeform (Classic) block is listed as incompatible. For the release-by-release view, see the WordPress 7.1 roadmap.

The part that touches your code. The test call states the rule plainly: blocks sync through their attributes, so most blocks support collaboration by default, and the ones that break are the ones holding editor state somewhere else. That makes the fix concrete rather than speculative. Declare the field in block.json with a type, read it from attributes, and write it with setAttributes on change, instead of parking it in a React useState inside edit() until blur. That already pays off in undo, revisions and autosave, and it is what decides whether your block survives if collaboration returns.

#When will WordPress core support multilingual sites

The roadmap describes phase 4 in one line: core implementation for multilingual sites. There is no schema, no API, no dev note and no date. The Advanced Administration Handbook still documents multilingual WordPress as something you solve with a plugin.

The sequencing is the interesting part, and it is stated openly in the phase 3 updates: the collaboration infrastructure has to be settled before multilingual can be designed, because both need the same answer to how one logical piece of content maps to several stored versions. Doing them in the other order would mean solving that twice. So phase 4 is not blocked by lack of interest, it is blocked by phase 3 not being finished, and phase 3 is a release cycle behind its own beta.

The claim that core will standardise translation tables is not on any WordPress page. Nobody has published a data model. What you can sensibly do while waiting:

• Keep translation identity in post meta or a taxonomy, not baked into template logic, so it can be remapped when a core model appears.
• Do not store a locale string inside block attributes. A block that hardcodes de_DE becomes invalid content the day the translation layer moves.
• Treat WPML and Polylang as long-term dependencies, not stopgaps. They will outlive this roadmap item.

#Can Data Liberation migrate a site to WordPress

The project page at wordpress.org/data-liberation was published on 6 December 2023 and names five phases explicitly:

That table is the honest version of the story. Phases 4 and 5, which are the ones people mean when they say “one click migration”, have not started.

What does exist is narrower and more useful than the slogan. The data liberation agent plugin, open sourced by Studio by WordPress.com, ships purpose-built extractors for named platforms: GoDaddy Websites and Marketing, Hostinger Website Builder, HubSpot, Shopify, Squarespace, Webflow, Weebly and Wix. That is a list of scrapers for specific closed builders, not a universal format. In parallel, the Playground team is building new PHP importers as streaming parsers, and the Playground blueprint importWxr step can now route through the Data Liberation importer instead of the legacy one.

The practical read for an agency: for the eight platforms on that list, there is real tooling worth testing before you quote a manual content migration. For anything else, the core export format is still WXR, and WXR still does not carry your media files, your plugin settings or your block pattern library. Budget accordingly.

#What changed in the WordPress 7.1 admin

First, a correction that circulates a lot. MP6 did not land in 2012. It was a feature plugin proposed in October 2013 and merged into WordPress 3.8, released 12 December 2013. And the admin has not been frozen since: 7.1 changed it.

What shipped in WordPress 7.1 on 19 August 2026 is a design system foundation, described in the core dev note of 31 July 2026. Two resources are now registered by default:

• A wp-theme stylesheet carrying semantic design tokens as CSS custom properties, named on the pattern --wpds-color-background-surface-neutral-strong, --wpds-border-radius-lg, --wpds-dimension-padding-2xl.
• A wp-theme script handle exporting a ThemeProvider React component from the @wordpress/theme package.

ThemeProvider takes five props: color.primary and color.background as seed colours (hex, rgb, rgba or a CSS named colour), cursor.control, cornerRadius with the presets none, subtle, moderate and pronounced, and isRoot to apply theming at the document root. The dev note’s own example:

import { ThemeProvider } from '@wordpress/theme';
import { Card } from '@wordpress/ui';

function Application() {
	return (
		<ThemeProvider
			color={ { primary: '#3858e9', background: '#11004d' } }
			cornerRadius="pronounced"
		>
			<Card.Root>
				<Card.Content>
					WordPress is designed for everyone.
				</Card.Content>
			</Card.Root>
		</ThemeProvider>
	);
}

Three more 7.1 admin changes that will show up in your issue tracker before they show up in a blog post:

1. The __next40pxDefaultSize prop has finished its journey: as of 7.1 it is a no-op, still accepted and ignored rather than removed. Form controls render at 40px regardless, so any admin screen whose spacing was tuned against the old default shifts.
2. wp_get_tooltip() and wp_get_toggletip() give you accessible tooltips as a core function instead of a per-plugin reimplementation.
3. The post list table row header moved from the checkbox column to the title column, an accessibility fix that changes what a screen reader announces per row.

What 7.1 is not: a replacement for wp-admin, a client dashboard, or a white-label handover. Tokens and a provider component are the opening, not the finished redesign. Plan a client-facing admin on the assumption that you still own that layer.

#What to learn as a WordPress developer in 2026

Three things are concrete enough to justify study time, and one common claim is not.

The Abilities API, shipped in 6.9. This is the registry that lets plugins, core and external agents discover what a site can do. You hook wp_abilities_api_init, call wp_register_ability() with a namespaced name such as my-plugin/my-ability, and supply an execute callback plus a permission callback with typed input and output schemas. Abilities are private by default: show_in_rest is false unless you set it, and only then do they appear under the wp-abilities/v1 REST namespace at /abilities, /abilities/{name} and /abilities/{name}/run. WordPress 7.0 added the client-side counterpart. Core registers three read-only abilities of its own in wp-includes/abilities.php, all marked @since 6.9.0: core/get-site-info, core/get-user-info and core/get-environment-info. Check the current names in trunk before you code against them, because earlier drafts of this set carried different ones. If you want a single API to learn from this roadmap, it is this one.

The AI Client, merged into 7.0. The merge proposal of 3 February 2026 described provider-agnostic infrastructure: a PHP prompt builder, a provider and model abstraction, credential storage shared across plugins, REST endpoints and a JavaScript API, and filters to allow or disallow prompt configurations. It was accepted on condition that the Connectors flow shipped alongside it, and 7.0 ships both. The SDK itself sits in wp-includes/php-ai-client/, with its vendored dependencies scoped to WordPress\AiClientDependencies\*; the WordPress glue on top of it (the prompt builder, the ability function resolver) sits in wp-includes/ai-client/. The Connectors screen has its own admin file, wp-admin/options-connectors.php, marked @since 7.0.0 in trunk. The practical consequence: you no longer bundle an API key and an HTTP client in every plugin that wants a model. What core does not include is page generation from a description, content optimisation or predictive updates. That is still plugin territory.

React, specifically the editor data layer. JSX is the easy half. The half that decides whether your block survives collaboration and the new admin is @wordpress/data, attribute schemas in block.json, and now @wordpress/ui and @wordpress/theme for admin surfaces that follow core tokens rather than fighting them.

And the claim to drop: there is no “canonical API” that makes headless WordPress easy. There is the REST API, there is WPGraphQL as a plugin, and there is now the Abilities API for agent-facing calls. They are three different contracts with three different maintenance stories, and choosing between them is still an architecture decision you have to make yourself.

#How the roadmap affects WordPress plugins

The roadmap does not only touch core; it changes how plugins lean on the platform. It helps to separate what already requires action from what is still conditional.

#Do plugins need changes for real-time collaboration

Until simultaneous editing returns to core, nothing forces you to rebuild a plugin. What you can do today, because it pays off without collaboration too, is make table editors, form builders and SEO tools keep their state in block attributes rather than in local React state. That is the same requirement the 7.0 Beta 1 call for testing set, and it is also what makes undo and revisions behave.

#Do plugins need changes for multilingual core

There is nothing to prepare against an API here, because there is no API. The only actionable step is not to lock yourself in: keep translation identity in meta or a taxonomy and keep language strings out of block attributes. Any list of standardised core translation APIs is, as of today, invented.

#What happened to real-time collaboration after WordPress 7.0

The removal did not end the work, it moved it out of the release branch. On 3 June 2026 the core team announced a collaborative editing outreach effort for 7.1: early adopters run the latest Gutenberg plugin, enable collaboration under Settings > Writing, and report in the #collaborative-editing-outreach Slack channel through the 7.1 cycle, at least until 18 August 2026. The Hosting team post of the same day asked web hosts to invite their own customers, so the feature gets tested on many server setups rather than one. That matches the reasons it was pulled: server load and memory efficiency depend on the host.

Two repositories show where the engineering went next. Gutenberg Sync Engines, created on 10 August 2026, describes itself as a comparison of possible sync engines and transports for Gutenberg real-time collaboration. The Presence API feature plugin, listed on wordpress.org since 21 July 2026 and requiring WordPress 7.0, tracks which users are logged in, which admin screen they are on and which posts they are editing. It moves that data through the Heartbeat API into a dedicated wp_presence table with a 150 second TTL, and keeps post locks there instead of in post meta, so holding a lock no longer makes cached post queries stale. Version 0.18.1 was released on 13 October 2026.

The Presence API meeting summary of 12 October 2026 sets the bar for a core proposal: three outside projects using the API and eight weeks without a breaking API change, counted from version 0.17.0, which makes 3 December the earliest date. Post locks are the first consumer and Gutenberg Sync Engines is the first outside project. No WordPress version is named as a target. If your plugin reads or writes the _edit_lock post meta, this is the work to watch, because post locks are exactly what the plugin moves.

#When is WordPress 7.2 released

The call for volunteers of 12 August 2026, posted by Jeffrey Paul, proposes 9 December 2026 as the final release date and calls it flexible. Alpha development began on 10 August 2026. The proposed milestones move in weekly steps:

The roadmap page, last modified on 20 August 2026, lists 7.2 for 10 December 2026 and says projected dates are for rough planning only. It also states that new features are frozen a month before a release. The call for volunteers names roles (release lead, release coordination, tech leads, triage lead, test lead) but no features. As of mid October there is no published scope for 7.2, so anything presented as coming in 7.2 before Beta 1 is a guess. For agency planning, the useful dates are the release candidates: test client sites and custom blocks against RC1 in the week of 17 November, not on release day.

#How to prepare plugins and blocks for WordPress 7.1

Without guessing at the future, this is what you can do with what has been published:

1. Declare block attributes in block.json with a type and write them with setAttributes. That is the condition the call for testing itself set for a block to sync.
2. Register your capabilities with the Abilities API instead of inventing your own REST endpoint for an agent to call, and leave show_in_rest at false until you know who consumes that ability.
3. Use the --wpds- tokens in your own admin screens, instead of hardcoding colours and radii that will drift in the next release.
4. Check the spacing of your admin screens against the 40px controls, because __next40pxDefaultSize no longer changes anything.

WordPress is not slowing down, but it is not sprinting either: one collaboration feature delivered, one deferred, an admin redesign at the token stage, and a multilingual phase that has not begun. If you want that read applied to a specific stack, we do exactly this kind of audit as WordPress developers.