Earlier this year, real-time collaboration (RTC) was removed from WordPress 7.0. Since then, I, @alecgeatches, @dmsnell, and others have been working through the valid concerns that led to that decision. We think these concerns call for a change in direction: Collaboration should be server-aware, with WordPress Core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. in control.

The current RTC experiment in Gutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ merges edits only in the browser. Each browser holds a copy of the post in a CRDT document. Peers exchange updates with each other until every copy matches. The changes exist only in browser memory until someone saves.

This design mirrors how the block Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor itself works: The editor does its work in the browser and hands WordPress the finished post when someone saves. A client-side approach to collaboration keeps changes to Core relatively small and makes the feature more responsive. But it leaves unsolved problems:

The server has no ability to attribute individual edits during a collaborative session. Even if the client provides attribution metadata, the server must either trust it blindly or assume that all of the content belongs to the person who saves. As a result, security checks can be sidestepped.

Example: Content laundering. An author (who is not allowed to publish raw HTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers.) and an admin (and super admin) are collaborating on the same post. The author adds a block containing a <script> tag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) and it is synced to administrator’s editor. The administrator, working in a different section of the post, fixes a typo and clicks Save. The post is updated under the admin’s capabilities A capability is permission to perform one or more types of task. Checking if a user has a capability is performed by the current_user_can function. Each user of a WordPress site might have some permissions but not others, depending on their role. For example, users who have the Author role usually have permission to edit their own posts (the “edit_posts” capability), but not permission to edit other users’ posts (the “edit_others_posts” capability)., including the script that the admin never looked at.

Collaboration is only open to browser clients. Updates that flow through the server—via the REST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/ or WP-CLI WP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is http://wp-cli.org/ https://make.wordpress.org/cli/—cannot be shared with peers and result in an “all-or-nothing” update.

Example: A scheduled integration. A script fetches a post at 09:00 and writes back its modified copy at 09:03. It does not know that two editors opened the post at 09:01 and began revising it. The script effectively erases their work.

Browsers can be told when a change like this occurs. But the server cannot tell them what changed, only that something changed. The editor must then choose to adopt or toss the newer server version in its entirety. Either way, work is lost.

When RTC is working optimally, peers stay in close sync. However, if peers drift from each other, then the experience can suffer and content loss can occur.

Example: A dropped connection. Alice and Bob are editing together when Bob’s network (versus site, blog) connection drops. Alice keeps editing, saves, and closes her tab. Later, Bob’s connection comes back. Before his editor can catch up on Alice’s changes, Bob clicks Save and erases her work.

Example: Overlapping edits on a slow connection. Alice and Bob start editing a post at about the same time, targeting the same paragraph. As their work syncs to each other, the resulting merge is confusing and disorienting.

The fix is to route collaboration through WordPress and let the server participate. Collaborators can no longer directly exchange updates with each other. Instead, they must send updates to WordPress. For each update, WordPress records who made the change, checks that the user is authorized to make it, merges it with everyone else’s changes, and stores the result.

WordPress then responds with changes from other peers that the current collaborator lacks. Or, if the change cannot be merged cleanly because of an update from a script or another peer, it can raise a conflict A conflict occurs when a patch changes code that was modified after the patch was created. These patches are considered stale, and will require a refresh of the changes before it can be applied, or the conflicts will need to be resolved. for the collaborator to review.

By moving the “sync engine” to the server, we make sure that WordPress retains authority over the content no matter who or what is collaborating.

Moving additional work to the server means that even more attention must be paid to server load and performance. Frequent polling carries a larger cost and becomes a less realistic path to effective collaboration on lower-resourced hosts.

Instead, we must improve the experience of collaboration when peers exchange updates less frequently. At the same time, we can offer alternative transports that offer an enhanced experience for hosts that are willing to invest additional resources.

No matter what, we must build on the community performance testing from May to provide a clear calculation of how much this new approach costs.

Our exploration is in its early stages and not ready for Core inclusion today. However, we have implemented three candidate server-aware sync engines that solve the problems outlined above:

• Yjs–server uses a PHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher implementation of Yjs to merge updates. The server holds a CRDT document and shares it with clients.
• Distributed Editing (DE-RTC) employs a three-way merge between the latest saved version, the editor’s proposed version, and the base version that the editor started from (if it differs from the latest saved version). Sync happens on save (or autosave), not when changes occur.
• Intent log is an operational transform engine that sends short semantic descriptions of what changed, such as “move this block.” The server holds an ordered log of these updates, which can be replayed by clients.

We are developing these sync engines (as well as a variety of transports) in the gutenberg-sync-engines repository. While it is a functional WordPress plugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party., it is intended as an exploratory tool to help us find the best path forward. We encourage you to try it, give feedback, and contribute.

As we move closer to choosing our preferred sync engine, we will share more about the engine internals and our methodology for measuring performance. Our eventual goal is to package our preferred sync engine in a feature plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins for wider use and testing.

Comments here are welcome, as is discussion in the #feature-realtime-collaboration channel in Slack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/.

Thanks to @alecgeatches, @ingeniumed, and Paul Kevan for their contributions to this post.