I once worked with a large newsroom where the editorial team was permanently at each other’s throats. Fifteen editors would be polishing one breaking news story, and every save risked wiping out a colleague’s paragraph. My answer at the time was a custom soft-lock built on transients and the Heartbeat API. It held up for about two days, until a burst of concurrent edits hit a race condition and took out half a day of work. That is how I learned you cannot bolt synchronization onto an architecture that was never built for it.
WordPress real-time collaboration is finally landing in core, targeted at version 7.0 in 2026. I have been reading the early feedback from the beta testers, and it splits along one line: build for modern WordPress and you will have an easy time of it, stay on legacy metaboxes and you have work ahead of you.
Post meta is where this breaks
The update on the WordPress Core blog, covering feedback from about 45 beta participants, reports that the feature works as expected on sites using native blocks. The trouble starts with legacy data structures. The most common failure is a block that stores its data in post meta instead of block attributes, particularly when that meta is not registered properly for the REST API.
Real-time collaboration depends on the data store seeing changes as they happen. If your plugin or custom theme writes to the database through old PHP hooks that bypass the REST API, the collaboration engine cannot see those writes, so it cannot sync them. Debugging a silent sync failure is considerably harder than registering the field correctly in the first place.
For custom fields to work with the collaboration features, you have to register them with show_in_rest set to true. This is how I have been handling it on recent projects:
function bbioon_register_collaboration_meta() {
register_post_meta( 'post', 'bbioon_editorial_notes', array(
'show_in_rest' => true,
'single' => true,
'type' => 'string',
'auth_callback' => function() {
return current_user_can( 'edit_posts' );
}
) );
}
add_action( 'init', 'bbioon_register_collaboration_meta' );The shift in editorial culture
The workflow change may be the bigger story. The beta feedback singled out a new Notes feature, which lets editors leave contextual comments without touching the block content. The same research found that not every team wants to work that way. Some still want to lock down particular sections or restrict editing by role.
- Revisions currently record who saved a post, not who wrote which sentence during a collaborative session. Core is working on contributor metadata to close that gap.
- Real-time interfaces are hard on screen readers, and the dev team has asked for help keeping the UI from turning into a stream of notifications.
- A site built on the Block Editor following current practices is already about 90% of the way there.
Preparing for WordPress 7.0
A full release is still some way off, but the direction is set. The check-in, check-out era of WordPress editing is on its way out. The full report on the WordPress Core site has the details of how the feature is being stress-tested, and it is worth reading if you maintain a publishing workflow at any real scale.
Preparing for this gets complicated fast. If you would rather not spend your weeks making an old codebase ready for the next generation of WordPress features, get in touch with my team. We have probably run into it before.
So which way will you go: keep the old locking system, or let a live multi-user editor loose on your posts?
