On 14 October 2026 the WordPress core team published a guide to three experimental sync engines for real-time co-editing, which WordPress calls real-time collaboration, and asked for testers. Each engine has its own way of merging the changes of several people who edit the same post at once. The feature itself is not planned for WordPress 7.2.
The idea is familiar from Google Docs, where several people work on one document and each sees the others' changes as they type. Today, when two people open the same post, WordPress tells the second that someone else is editing it and asks whether they want to take over.
Why real-time co-editing was pulled from WordPress 7.0
The feature was meant to ship with WordPress 7.0 but was removed from the release in May 2026. The reasons given included concerns about server load and recurring bugs found in testing.
In September the developers proposed a new direction. In the current experiment, edits are merged only in the browsers, so the server cannot tell who wrote what. An author who is not allowed to publish HTML can add a script to a post an administrator is also editing. When the administrator saves a fix, the script is stored under the administrator's permissions. In the new approach every change goes through WordPress, which checks who made it, whether they are allowed to and whether it carries unsafe code before storing it.
The three real-time co-editing engines
The three engines under test differ in how fast changes reach the others and in what happens when two people change the same spot.
- yjs-server. The closest to Google Docs, with fast updates and the others' cursors on screen. But if two people change the same thing at once, one silently wins and nobody is warned.
- DE-RTC. The closest to how WordPress works today. Changes are shared on autosave, every ten seconds by default, so it does not feel like Google Docs. If two people change the same block in conflicting ways, it is set aside for review and a person decides which version stays. The developers see it as a good fit for small, low-cost hosting.
- intent-log. The browser describes each action, such as "split block 1", and the server logs these descriptions, which leaves a history of who did what. Here too, conflicts are set aside for a person to review.
What changes for your site
Nothing for now. The engines live in the gutenberg-sync-engines plugin, where the developers compare them before picking one to release as a separate feature plugin for wider testing. The official plan for WordPress 7.2, due on 8 December, deliberately leaves collaborative editing out because more time is needed for architectural decisions.
The test plugin needs the Presence API, a plugin that tracks which user has which post open. The summary of the 12 October meeting puts the earliest date the Presence API can qualify for a core proposal at 3 December. None of the posts gives a date for real-time co-editing itself.
When the feature reaches sites, it will ask more of the server. The simplest option, where the browser checks for changes every few seconds, works on any host, at the cost of PHP workers, the processes that run the site's code. Faster options such as WebSocket need a server that can run a separate process. The developers write that frequent polling is less realistic on low-resourced hosting and expect the options to depend on the host.
For stores, note that the posts cover the block editor, where pages are written, while WooCommerce products open in the classic edit screen by default. The posts say nothing about them.
What to do
On your live site there is nothing to do for now. To try the engines yourself or with your developer, use a staging copy, a separate copy of the site kept for tests. On cPanel, the WP Toolkit guide shows which editions can make such copies. Before you test, keep in mind the following:
- The test plugin needs WordPress 7.0 or newer and the Presence API plugin, activated first.
- It is not in the plugin directory. It comes from GitHub.
- It does not work alongside an active Gutenberg plugin, because it ships its own copy of the editor.
- On activation it creates its own tables in the database.
Feedback goes to GitHub and the #feature-realtime-collaboration channel on the WordPress Slack.
What we do
Under monthly maintenance, WordPress, theme and plugin updates are tried first in staging. Every change is in Git and reaches the live site only after the tests, as described in how we work. Write to us through the inquiry form and we will get in touch.
Frequently asked questions
What is real-time collaboration in WordPress?
A feature that lets several people edit the same post at once, each seeing the others' changes as they type, as in Google Docs. Today, when two people open the same post, WordPress tells the second that someone else is editing it and asks whether they want to take over.
Will real-time collaboration be in WordPress 7.2?
No. The official plan for WordPress 7.2, due on 8 December 2026, deliberately leaves collaborative editing out because more time is needed for architectural decisions. None of the team's posts gives a date for the feature itself.
Why was real-time collaboration pulled from WordPress 7.0?
The feature was meant to ship with WordPress 7.0 but was removed from the release in May 2026. The reasons given included concerns about server load and bugs that kept coming back in testing.
What is the security problem with the current experiment?
In the current experiment edits are merged only in the browsers, so the server cannot tell who wrote what. An author who may not publish HTML can add a script to a post an administrator is also editing, and when the administrator saves, the script is stored under the administrator's permissions. In the new approach proposed in September 2026, every change goes through WordPress, which checks who made it, whether they are allowed to and whether it carries unsafe code.
What are the three sync engines being tested?
yjs-server is the closest to Google Docs, but when two people change the same spot at once, one silently wins. DE-RTC shares changes on autosave, every ten seconds by default, and sets conflicts aside for a person to review. intent-log has the server log a description of each action, which leaves a history of who did what.
Will real-time collaboration put more load on my hosting?
Yes, once the feature reaches sites. The simplest option, where the browser checks for changes every few seconds, works on any host but uses up PHP workers. Faster options such as WebSocket need a server that can run a separate process, and the developers expect the options to depend on the host.
Does real-time collaboration cover WooCommerce products?
The WordPress team's posts cover the block editor, where pages are written. WooCommerce products open in the classic edit screen by default, and the posts say nothing about them.
Can I try the real-time collaboration test plugin?
Yes, but not on your live site, because the developers warn that all three engines still need work and may have bugs. Use a staging copy on WordPress 7.0 or newer and activate the Presence API plugin first. The gutenberg-sync-engines test plugin comes from GitHub, does not work alongside an active Gutenberg plugin and creates its own database tables.
Sources
- Make WordPress Core, Real-time Collaboration, A Guide to Sync Engines
- Make WordPress Core, Presence API meeting summary, October 12, 2026
- Make WordPress Core, Moving to a server-aware approach for collaboration
- Make WordPress Core, Real-time collaboration will not ship in WordPress 7.0
- Make WordPress Core, Roadmap to 7.2
- Make WordPress Core, WordPress 7.2
- GitHub, WordPress/gutenberg-sync-engines
- WordPress,
_admin_notice_post_locked() - GitHub, WooCommerce 11.2.0, class-wc-post-types.php