Extending the 7.0 Cycle ![rw-book-cover](https://make.wordpress.org/core/files/2026/03/Extending-the-7.0-Cycle.png) 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 polling to ensure the widest possible reach and access to this capability. To support this system in core, [a new custom table was proposed](https://core.trac.wordpress.org/ticket/64696). 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 fields. Since then, [Matt has expressed a preference](https://wordpress.slack.com/archives/C18723MQ8/p1774855143315979) 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](https://github.com/WordPress/gutenberg/issues/76919#issuecomment-4163846218)) 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](http://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/hosting after the final architecture has been committed. For plugin developers, many popular plugins still rely on metaboxes for their UI. These plugins submit their inputs when a post is saved in the editor via 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 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](https://make.wordpress.org/core/2026/03/10/real-time-collaboration-in-the-block-editor/) and, for more details on migrating from metaboxes, see the [Meta Boxes guide](https://developer.wordpress.org/block-editor/how-to-guides/metabox/) 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., Extending the 7.0 Cycle, make.wordpress.org, 01kn4vvy4cagmces07ayjk54zs.