Yes, you can try WordPress collaborative editing right now: activate the latest Gutenberg plugin, turn it on under Settings, Writing in the dashboard, and two logged-in users can work on the same post at once. Whether that belongs on a client site today is a separate question, and the honest answer is no, not yet.
The feature was cut from WordPress 7.0 in May after a hard call by the core team, and it has since slipped past 7.1 as well. In June the project opened a standing outreach program to get the feature onto real sites and real hosting setups before it tries to ship again, and the announcement on Make WordPress Core is the source for the details in this post. The original ask was participation through the 7.1 cycle, at least until 8/18/26, with test team badges at the end. A July update to that post adds that collaborative editing was punted from 7.1 too, and that the effort keeps running beyond the cycle.
I’d argue that people who build sites for clients are the testers this feature needs most, and not only out of civic spirit. Core can test core. What core’s own testing can’t reproduce is the specific mess on your client installs, and that is where it breaks.
What the 7.0 testing left out
For 7.0 the feature got a serious workout: developer-oriented testing, enterprise-level testing, and deterministic test runs with hosting companies, all three described in the announcement. That kind of testing earns its keep. It finds crashes and race conditions and scaling problems, but only in controlled environments. The announcement is also upfront that stability, performance, and reliability were the focus, and that the feature needs more than that to succeed.
What it cannot find is how the feature behaves on an ordinary stack, used by people with deadlines, for weeks: two editors on one long page, a page cache serving stale markup, a plugin that ships a meta box with inline scripts and its own save path. That data did not exist, and the 7.0 removal happened anyway.
The new program borrows the FSE Outreach idea: one Slack channel, #collaborative-editing-outreach, where testers and the people building the feature share a room. There are no recurring themed calls for testing this time, because those would get repetitive fast; instead the team posts key updates in the channel as fixes land. Everything arrives through the Gutenberg plugin, and a separate featured plugin was ruled out, so running the latest version is part of the deal. Hosting companies are being contacted to recruit testers, because environment spread is the whole point.
We wrote about the 7.0 cut when it happened, and the reasoning still holds up: shipping a half-tested sync layer to every site at once was the risk.
Setting up WordPress collaborative editing on a copy of the site
The toggle appears in Settings, Writing as soon as the Gutenberg plugin is active, which makes it tempting to enable on production, click around for ten minutes, and call it tested. Two problems with that. Every fix and change for the collaborative layer ships through the Gutenberg plugin, so you are signing the live site up for frequent updates from the plugin’s freshest channel. And one person clicking alone tells you almost nothing, because the feature is a multiplayer feature.
The setup that produces useful signal is a clone of a real site you maintain, on staging or locally, with the latest Gutenberg and two accounts that match the roles your client uses:
wp plugin install gutenberg --activate
wp plugin update gutenberg
wp user create rtc_tester_two tester2@example.com --role=editorEnable collaborative editing under Settings, Writing, open one existing draft in two browsers with the two accounts, and work on real content, the pages the client edits day to day. Skip the throwaway post with two paragraphs. If you join the channel, expect to update the plugin often and pin nothing, and note the version in every report you make. A report against an old build wastes your time and theirs.
For store owners, product copy is a realistic scenario if the description field is block based. I’m not sure how far the WooCommerce product screen has moved in that direction, so check that before counting on it.
What breaks first, and where to report it
The collaborative layer syncs block content and block attributes. Everything the block editor does not own stays single-user, and that boundary is where the breakage concentrates. Classic meta boxes are the obvious case, and why your meta boxes break it is worth reading in full. But plugin sidebars that mutate external state, custom blocks that keep data outside their attributes, and save routines that assume exactly one writer all misbehave in their own quiet ways.
Before you test, it helps to know what your editor screens register outside the block document. This snippet logs every meta box on any editor screen, so you start with a list instead of guesswork:
<?php
add_action( 'add_meta_boxes', 'bbioon_log_editor_meta_boxes', 100 );
function bbioon_log_editor_meta_boxes() {
global $wp_meta_boxes;
$screen = get_current_screen();
if ( ! $screen ) {
return;
}
$ids = array();
foreach ( (array) ( $wp_meta_boxes[ $screen->id ] ?? array() ) as $contexts ) {
foreach ( (array) $contexts as $priorities ) {
foreach ( (array) $priorities as $box ) {
if ( is_array( $box ) ) {
$ids[] = $box['id'];
}
}
}
}
error_log( sprintf( 'Meta boxes on %s: %s', $screen->id, implode( ', ', $ids ) ) );
}A short session script that covers the usual suspects:
- Two editors in one long post, with undo and redo from both sides.
- A plugin sidebar or meta box save fired while the other session is typing.
- Post status changes, locking, and autosave while both sessions are open.
- Your most complex custom block with two people editing it at once.
When something breaks, report it in the channel with the Gutenberg version, the PHP version, the host, the plugin list, and exact steps. The team is deliberately recruiting across hosting environments, so “works on my staging” is exactly the kind of data they want. Read the key updates in the channel before writing anything up, since several of the things you’ll find are known and being fixed upstream. The long-running collaborative editing discussion in the Gutenberg repository is also worth a skim, because it helps you tell a bug apart from a design gap.
The point of all this is to get WordPress collaborative editing onto strange stacks before it ships to everyone, and those strange stacks are on the sites you build and maintain.
If your client sites carry custom editor code and you want a second pair of eyes on what the sync layer will do to it, I do that kind of audit regularly. Send me the plugin list and the custom blocks in play, and I’ll tell you where it will hurt first.
One concrete step for today: clone a single client site to staging, run the two plugin commands above, enable the toggle, open one draft in two browsers, and spend twenty minutes on your own plugin’s editor UI. Post the first thing that breaks in the channel. That is the whole contribution loop.
