Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
WordPress server-aware real-time collaboration is still an exploratory project, not a feature you can assume is included in WordPress Core. As of October 10, 2026, the project is investigating ways for WordPress Core to control collaborative state on the server. An earlier Gutenberg experiment synchronized a CRDT document between browsers and kept unsaved edits in browser memory. The newer proposal gives the server a more active role, but no engine, hosting requirement, transport, or release date has been finalized.
What “server-aware editing” means in WordPress
Server-aware editing is the proposed architectural direction for WordPress real-time collaboration. The goal is simultaneous editing while WordPress Core—not only the participating browsers—understands, stores, synchronizes, and can govern the collaborative state.
This distinction matters because “real-time collaboration” can describe several different features. A comment thread, a revision history, autosave, and two people typing in the same post are not equivalent. The proposal concerns concurrent editing of a post or page. It is not a claim that a finished collaboration system has shipped.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
The September 18, 2026 Make WordPress Core proposal says the work is early and not ready for inclusion in Core. Treat its three synchronization designs as candidates under development, rather than as selectable WordPress settings or production guarantees.
#1 Best Overall
The literal answer to “How does WordPress real-time collaboration work?”
In the former experiment, each browser held a copy of the post in a CRDT document. Browsers exchanged updates, merged those changes locally, and retained unsaved work in browser memory until someone saved. The project described this plainly: “The current RTC experiment in Gutenberg merges edits only in the browser.”
The server-aware direction asks WordPress Core to participate in that process. Depending on the eventual design, the server could hold the collaborative document, reconcile competing saves, or maintain an ordered record of editing intentions. That could improve server-side control and attribution, but it also makes server load, security, memory use, compatibility, and transport design central engineering questions.
Is real-time collaboration available in WordPress yet?
Not as an established WordPress Core feature as of October 10, 2026. WordPress Core announced on May 8, 2026 that real-time collaboration would not ship in WordPress 7.0. The decision followed concerns about robustness, race conditions, server load, memory efficiency, the size of the affected code surface, and recurring bugs found through fuzz testing.
That announcement did not permanently reject collaboration. It said the capability remained important and that broader testing and iteration would continue after immediate release work. The September proposal is part of that continued exploration.
WordPress.org’s version history records WordPress 6.6.10 as released on October 6, 2026. That release-history entry does not indicate that server-aware collaboration shipped in 6.6.10. No source establishes a Core release containing the proposed design, and no release date has been announced.
What you should expect on a current site
- Do not expect two editors to share a single post state through a standard Core setting.
- Do not infer availability from the phrase “real-time collaboration” in an experiment, plugin, presentation, or roadmap discussion.
- Check the specific project or plugin documentation for any test feature; experimental behavior is not a Core support commitment.
- Keep ordinary revisions, autosaves, editorial permissions, and backups in place because they are not replaced by the proposal.
How the earlier browser-based experiment worked
The earlier Gutenberg implementation used Yjs and a provider-based synchronization layer. A CRDT (conflict-free replicated data type) represents the document so that separate clients can apply changes and converge on a consistent result without a single browser receiving every keystroke first.
Editing and synchronization flow
- Each participating browser opened a local collaborative document representing the post.
- An editor changed blocks or other supported content in the browser.
- The local CRDT recorded the change and the provider exchanged updates with other clients.
- Each browser merged the received updates into its own document.
- The resulting state remained unsaved in browser memory until an editor saved or an autosave occurred.
This model let the block editor feel familiar: users edited in the browser while the synchronization layer handled concurrent changes. Its weakness was authority. Because the collaborative document lived in the clients until save, the server could not reliably attribute each individual edit during the session or exercise the same control over state that it has over a saved post.
Transport in that experiment
The March 10, 2026 developer note says the default provider used HTTP polling. It also documented the sync.providers filter, which allowed a plugin to replace or extend the transport—for example, by using WebSockets.
Those details describe the earlier experiment only. They do not establish that HTTP polling, WebSockets, or the sync.providers filter will be the transport model for the later server-aware proposal.
Compatibility limit: classic meta boxes
The experiment did not synchronize classic WordPress meta boxes. To avoid data loss, collaboration was disabled when a post contained meta boxes. The developer guidance suggested moving data to registered post meta with show_in_rest enabled, or using sidebar plugins and block-based interfaces.
This is an implementation constraint of the earlier experiment, not a confirmed rule for a future server-aware feature. Developers should nevertheless treat any editor surface outside the supported block-editor data model as a compatibility risk until a final design documents how it is synchronized.
What changes in a server-aware design
The proposed direction moves the authority boundary. Instead of treating the server mainly as a place to receive a final save, WordPress Core could maintain or validate collaborative state while users are editing.
| Concern | Earlier browser-centered experiment | Proposed server-aware direction |
|---|---|---|
| Where active collaborative state lives | A CRDT copy in each participating browser; unsaved state stayed in browser memory. | The server would participate in maintaining or controlling collaborative state; the exact storage model is undecided. |
| Server participation | Browsers exchanged updates through a provider, with the server unable to attribute every in-session edit reliably. | WordPress Core would have a more active role in synchronization, state control, and policy. |
| Save behavior | Editors could work locally and save the converged document later. | Depending on the selected engine, synchronization could be continuous or tied to save/autosave operations. |
| Security and attribution | Client-held unsaved state limited server-side visibility into individual edits. | Server control is intended to improve governance and attribution possibilities, while introducing additional security work. |
| Performance responsibility | Much of the merge work occurred in browsers. | Server CPU, memory, network traffic, and persistence costs must be measured and managed. |
This table describes architectural goals in the project proposal, not independent benchmark results. No source establishes that the proposed design is faster, more reliable, or cheaper for a particular host.
The three synchronization engines under consideration
The September proposal describes three candidate approaches. The project has not selected a winner, and none should be presented as production-ready.
1. Yjs-server
Yjs-server would provide a PHP implementation of Yjs. The server would hold a CRDT document and share it with connected clients. This keeps the familiar CRDT convergence model while making the server a participant that can inspect and manage the collaborative document.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →- State location: a CRDT document on the server, with client replicas.
- Synchronization pattern: clients exchange updates through the server.
- Concurrent merge: CRDT rules merge independent changes.
- Server work: maintain documents, process updates, distribute changes, and account for memory and connection load.
The proposal does not supply a benchmark, PHP version requirement, maximum collaborator count, or hosting tier for this option.
2. Distributed Editing (DE-RTC)
Distributed Editing uses a three-way merge when the version being saved is no longer based on the latest saved post. It compares the latest saved version, the editor’s proposed version, and the base version from which that editor began.
- State location: saved WordPress versions plus each editor’s proposed document.
- Synchronization pattern: synchronization occurs on save or autosave, not on every individual change.
- Concurrent merge: the system performs a three-way comparison against the common base.
- Server work: detect stale bases, calculate merges, and resolve or report conflicts at save time.
Because updates are not synchronized on every keystroke, this design represents a different meaning of “real time” from a continuously shared document. The proposal does not state how every block-level conflict would be displayed or resolved in a final implementation.
Rank #4
3. Intent log
An intent-log design uses operational transformation. Rather than sending only raw document states, clients send concise semantic descriptions of actions, such as moving a block. The server keeps an ordered log that clients can replay.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware match- State location: an ordered server-side record of editing intentions, plus client document state.
- Synchronization pattern: clients send operations that the server orders and distributes.
- Concurrent merge: operational-transformation rules adjust operations so concurrent intentions can be applied consistently.
- Server work: validate, order, transform, retain, and replay the operation log.
This approach could make edits more semantically meaningful—for example, “move this block” rather than “replace these bytes”—but it requires transformation rules for the editor’s supported operations. The proposal does not establish the coverage of those rules or their resource cost.
Candidate comparison
| Candidate | Primary collaborative state | When synchronization occurs | Merge model | What remains unknown |
|---|---|---|---|---|
| Yjs-server | Server-held CRDT document and client replicas | Update exchange through the server | CRDT merge | Benchmarks, capacity, PHP requirements, transport, and production status |
| DE-RTC | Saved versions, editor proposal, and editing base | Save or autosave | Three-way merge | Conflict UI, supported content types, performance, and rollout plan |
| Intent log | Ordered server-side operation log | As operations are submitted and replayed | Operational transformation | Operation coverage, log retention, resource cost, and final API |
The evidence supports a mechanism comparison only. It does not support ranking these designs for speed, reliability, or host compatibility.
Why WordPress moved toward server awareness
The browser-centered model exposed problems that become more serious as collaboration scales. The May 2026 release decision listed robustness, race conditions, server load, memory efficiency, broad code-surface concerns, and fuzz-testing bugs. Even when most merging happens in browsers, WordPress still has to accept saves, protect permissions, reconcile versions, and preserve data.
The server-aware proposal therefore treats performance as an unresolved engineering requirement. It calls for better collaboration at lower update frequencies and considers alternative transports for hosts with additional resources. That wording does not define a minimum server specification. No validated benchmark, supported hosting tier, engine selection, or capacity figure has been published.
Recommended Free Tools
What server awareness could improve
- State governance: Core can apply authentication, authorization, validation, and lifecycle rules closer to the shared document.
- Attribution: a server-controlled stream or document can provide a clearer basis for associating operations with users than unsaved browser memory.
- Recovery: server-held state may offer more consistent recovery when a browser closes or loses connectivity, subject to the final persistence design.
- Compatibility planning: Core can define how saves, autosaves, revisions, and editor extensions interact with collaboration.
What server awareness makes harder
- Resource consumption: active documents, connections, merge operations, and logs consume CPU, memory, storage, and network capacity.
- Failure handling: disconnects, stale sessions, retries, duplicate operations, and partial saves require explicit protocols.
- Security: a server receiving collaborative operations becomes a more important target and must enforce permissions and validate input.
- Hosting variability: shared hosting, managed WordPress environments, and resource-rich infrastructure may support different transports and workloads.
- Backward compatibility: existing plugins, custom fields, meta boxes, revisions, autosave, and REST integrations must not silently lose data.
WordPress Notes are not simultaneous co-editing
WordPress Notes are a separate editorial-feedback mechanism. Documentation says Notes are available in post and page editors for users who have permission to edit the content. Notes were introduced in WordPress 6.9, with more advanced features in 7.1.
Best Value
A user can attach a note to a block or selected text, reply in a thread, mention collaborators, and resolve feedback. Notes are visible in the editor to users with permission and do not appear in published content. This is asynchronous discussion around content, not two people changing the same document state at once.
Custom post types can support Notes when a theme or plugin author enables them. Notes are not available in Site Editor templates and template parts. Consequently, “we use Notes for collaboration” should be understood as “we exchange editorial comments,” not “WordPress Core provides simultaneous co-editing.”
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What developers should plan for
Keep editor data in supported, registered structures
The earlier experiment’s meta-box limitation is a warning for extension authors. If a plugin stores editorially important values in an interface that the collaboration layer cannot observe, two editors can see inconsistent state or overwrite one another. Registered post meta exposed through the REST API, sidebar interfaces, and block-based controls were the suggested direction for the earlier implementation.
Do not assume that show_in_rest alone guarantees future collaboration support. It makes data available through the REST API; the eventual server-aware protocol still has to define how that data is versioned, merged, authorized, and displayed.
Do not hard-code the old transport
The earlier developer note documented HTTP polling as the default provider and the sync.providers filter for replacement or extension. A plugin built around that experiment should isolate its transport integration so it can adapt if the project chooses a different protocol or server architecture.
Test failure paths, not only the happy path
- Open the same post in multiple sessions with different permissions.
- Make overlapping edits, then save from each session.
- Disconnect a browser before save and reconnect it later.
- Close a tab with unsaved changes and verify what is recoverable.
- Exercise custom fields, embeds, reusable blocks, and plugin-owned editor controls.
- Check revision, autosave, undo, and restore behavior after a conflict.
These are prudent compatibility tests, not a statement that any final Core protocol will behave exactly this way.
What site owners should do now
- Do not change hosting solely for the proposal. The project has not published server requirements or a measured capacity target.
- Use normal WordPress permissions and revisions. They remain the established controls for editorial work while real-time collaboration is unsettled.
- Use Notes for review conversations. They support threaded feedback without pretending to provide concurrent editing.
- Evaluate any experiment separately. Confirm its WordPress version, supported content types, transport, data-loss behavior, and maintenance status before enabling it on a production site.
- Maintain backups and a staging environment. Experimental collaboration code can affect saves and editor state, so test restoration before inviting a large editorial team.
- Watch official Core updates. The selected engine, feature-plugin plan, transport support, requirements, and release timing are all still open.
Open questions the proposal has not answered
- Which of the three candidate engines, if any, will be selected?
- Will collaboration be packaged first as a feature plugin, and what testing period will precede Core consideration?
- What PHP, database, object-cache, persistent-connection, or WebSocket capabilities will be required?
- How will shared documents be authenticated, authorized, encrypted in transit, retained, and removed?
- How will classic meta boxes, custom post types, revisions, autosaves, and third-party blocks participate?
- What is the behavior when editors work offline, reconnect, or submit duplicate operations?
- How will administrators inspect, audit, roll back, or recover a collaborative session?
- What performance cost will a site incur at different update frequencies and collaborator counts?
- When will a stable release be available?
Until those questions are answered by an implementation and its documentation, claims about required hosting, supported transports, maximum users, or release timing are speculation.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Timeline and status checkpoints
| Date | Event | What it establishes |
|---|---|---|
| March 10, 2026 | Developer note on Real-Time Collaboration in the Block Editor | Documents the earlier Yjs/provider experiment, HTTP polling default, sync.providers, and classic meta-box limitation. |
| May 8, 2026 | WordPress Core announcement | Real-time collaboration would not ship in WordPress 7.0 because of robustness, race-condition, resource, and testing concerns. |
| June 14, 2023 | General WordPress hosting guidance last updated | Provides ordinary hosting advice, not requirements for server-aware collaboration. |
| August 18, 2026 | Notes documentation update | Documents Notes capabilities and their separation from published content. |
| September 18, 2026 | Proposal for a server-aware approach | Introduces the three candidate engines and says the work is exploratory and not ready for Core inclusion. |
| October 6, 2026 | WordPress 6.6.10 release-history entry | Confirms a dated WordPress release; it does not confirm server-aware collaboration. |
| October 10, 2026 | Current status covered by this guide | Server-aware collaboration remains a project direction rather than an established Core feature. |
Bottom line for editors, developers, and administrators
WordPress real-time collaboration is being redesigned around server awareness because the earlier browser-only CRDT experiment did not provide enough server control and raised robustness and resource concerns. The project is evaluating Yjs-server, three-way Distributed Editing, and an intent log, but has not selected one or published production requirements.
For now, treat simultaneous co-editing as unavailable in standard WordPress Core. Use Notes when the need is threaded editorial feedback, keep revisions and backups for content safety, and treat any collaboration experiment as a version-specific test. The next meaningful milestone will be a documented feature plugin or equivalent implementation with measured performance, compatibility rules, security behavior, and a stated path toward Core—not merely another proposal.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
