The WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:
Found a bugbugA bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.?Create a ticket in the bug tracker.
The primary aim of real-time collaboration is to build functionality into the blockBlockBlock 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. editors so that concurrent collaboration, shared edits, and online presence of peers are possible. Supporting these workflows is not just about concurrency, though, but also about lifting restrictions that have been present in WordPress for a long time, such as locking a post when two people try to edit at the same time. There are various technical layers underpinning this functionality, so let’s quickly recap what they are and what we need to take into account to get started.
First, these capabilities should be available to the widest possible audience. That means using technologies that don’t rely on sophisticated server setups that would restrict the ability for people to collaborate within their WordPress sites, regardless of hosting infrastructure. This likely puts us on the path of building on top of open web standards like WebRTC where we can ensure deployment of these features without any special burdens on the backend. WordPress itself could provide an easy to scale signalling server, likely over REST endpoints, for authentication handshake.
However, we also want to ensure the system is flexible enough to extend with other server implementations for more advanced needs — such as a WebSockets service — in order to scale beyond current limits for peer-to-peer simultaneous browser connections, or for cases where peer connections cannot be established. This would naturally be pluginPluginA 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 territory.
Outside of the peer sharing setup, we also need to establish the primitives for conflictconflictA 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. resolution that are going to be able to reason through our block data structures and orchestrate edits over time. For this purpose, it’s likely Yjs will come in handy, which is an amazing open sourceOpen SourceOpen Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL. library that implements conflict-free replicated data types (aka CRDTs) presented as shared types. This library has already been put to good success in most of the past explorations within the Gutenberg repo and related projects. The author of the library has also engaged directly in some of these iterations with suggestions and feedback. While it has worked pretty well with block data, it has not been paired with multi-entity documents yet. Furthermore, ongoing SQLite explorations might uncover other ideas and opportunities for wider offline-first experiences where CRDT needs to be handled at a different abstraction layer.
This is a summary of the broad tasks we need to look into:
Outline the set of hooksHooksIn WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. necessary to encapsulate collaboration features over block editor providers, like sharing edits and peer state across browsers.
Ensure capabilities build on top of the block APIAPIAn API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. so that block authors don’t need to make modifications for their blocks to work in collaborative environments.
Design and represent “presence” of connected peers in the interface. Integrate selection state with other useful parts of the interface, like the block list sidebarSidebarA sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme..
Lift concurrent editing restrictions. Right now WordPress locks a post to the current user that is editing it. Another user can take over, but it doesn’t allow two users working on the same post at the same time.
Review undo / redo stacks and resolution. It’s likely some modifications are needed here.
If employing CRDT, ensure its designed to work with multi-entity documents, which is a newer requirement from Phase 2 compared to just Phase 1.
Employ peer caret and selection primitives that work across block types and design their semantic and visual representation.
Consider offline a first-class use case of collaboration in orchestrating edits and transactions.
Explore the possibility of “following a user” as they work through a document.
Define authentication and messaging semantics. For example, the characteristics of a WebRTC handshake with a plain HTTPHTTPHTTP is an acronym for Hyper Text Transfer Protocol. HTTP is the underlying protocol used by the World Wide Web and this protocol defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands.REST APIREST APIThe 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/. request to the backend. Provide answers to questions like read only sessions over peer-to-peer connections and cases where peer-connections cannot be established.
Structure WebRTC implementation as an adapter that could be swapped. The architecture should be pluggable so extenders can provide other solutions.
Outline error scenarios and functional overlaps with offline-first capabilities. For example, peers losing a connection while still making edits. We’d want to employ this for same-user resolution should you be editing across different devices as a single user. Handle saving and revision allocation.
If you are interested in the challenges of real time collaboration or want to leave any feedback on the project, please chime in.