After discussions with project leadership, the decision has been made to delay the 7.0 release by a few weeks to finalize key architectural details.
WordPress 7.0 is shaping up to be a big release, with some great highlight features and a long list of improvements. I’m excited to get this in the hands of users. Within that context, contributors have been hard at work discussing, iterating, and polishing every detail.
One of the larger items for this release is the introduction of real-time collaboration primitives, which includes built-in support for HTTP HTTP 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. polling to ensure the widest possible reach and access to this capability 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).. To support this system in core Core is the set of software required to run WordPress. The Core Development Team builds WordPress., a new custom table was proposed. While there was general agreement that it would be nice to have for collaborative editing and sync coordination, it was paused due to time and design uncertainties.
Due to a combination of rapid iteration around data storage solutions and cache invalidation strategies, discussions were held before RC2. This led to a path forward that addresses the outstanding concerns by continuing to store content changes in postmeta while moving awareness/presence information about users in session to transients. This approach avoids rapid and frequent cache invalidation issues with special handling for collaborative editing meta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. fields. Since then, Matt has expressed a preference to revisit the custom table and ensure adequate time is given to come up with the best design possible from the start. To support this, more time is being added to the 7.0 cycle to ensure the best solution for the overwhelming majority of users is included.
Additionally, there was one extra consideration raised about use cases beyond the real time support (like accommodating broader sync use cases) that should also be discussed to ensure we design the right primitives in the broadest possible sense. After getting more clarity on how a new table will look and function, a new final timeline for 7.0 will be announced. This will likely be a delay of a few weeks, as there are many features that will benefit users, and it would be counterproductive to hold them back for too long. The extra time will help ensure we can process all the feedback given so far and ensure the design can stand the test of time. New features and enhancements not already in core will not be considered for inclusion.
Overall, the intention in shipping collaborative editing in 7.0 as an opt-in is to give the WordPress ecosystem time to adapt to a major change. For hosts, this can have an impact in WordPress resource usage and database interactions. WordPress sites are generally very read-heavy, but collaborative features inherently involve a writing state that is then rebroadcast to other users. The HTTP polling mechanism as designed is a lowest-common-denominator approach, but its broad compatibility comes at the cost of relative inefficiency compared to more specialized solutions like WebSockets. It’s important to empower site owners and hosts to have full control during this process. So, rather than enabling the feature for 100% of users on day one, the opt-in approach allows usage to ramp up organically. Hosts can monitor requests to the sync endpoints, perform profiling to ensure their particular caching and request management approaches are appropriate, etc.
Thus far, for example, WordPress.com has done extensive testing on this feature and has demonstrated that the conservative defaults, the limit on the number of collaborators, and the number of active editor sessions in the shared environment make HTTP polling a viable transport that can work on essentially any WordPress host without additional dependencies. Other hosts are encouraged to test this as well, and a call for testing will be coming to make.wordpress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org//hosting after the final architecture has been committed.
For 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. developers, many popular plugins still rely on metaboxes for their UI User interface. These plugins submit their inputs when a post is saved in the editor via 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/’s compatibility mode. This approach, on its own, is not compatible with collaborative editing, which builds on the wordpress/data package used by 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 to detect and sync changes across all users in a session, gracefully handling common types of conflicts. As a result, real-time collaboration is disabled when metaboxes are present. The 7.0 cycle will be a window in which these plugin developers can implement a bridge to make their metaboxes compatible or adopt more modern Gutenberg APIs that will instead render their UI in a way that more seamlessly integrates with the editor. Learn more in the official dev note for the feature and, for more details on migrating from metaboxes, see the Meta Boxes guide in the Block Editor Handbook.
Thank you to everyone’s continued commitment to ensuring 7.0 is an outstanding release, both from a features and stability perspective.
Props to @jorbin @desrosj @annezazu @griffbrad @4thhubbard for helping review this post.
#7-0