WordPress 7.0 development has moved on to the harder problems, and the Core Dev Chats are where you hear about them first. The agenda for the April 8, 2026 meeting was mostly about the architectural foundations of real-time collaboration. That takes the editor past ordinary CRUD work and into state synchronization, which is where most legacy systems fall apart.
I have seen how real-time goes wrong. I once spent three days debugging a race condition in a custom stock sync for a high-traffic WooCommerce store because two transients were fighting for dominance. In WordPress 7.0 the problem is not transients. It is CRDTs (Conflict-free Replicated Data Types) and sync providers.
The roadmap for WordPress 7.0 development
The latest Path Forward note treats 7.0 as the Phase 3 milestone: the release where the block editor stops being a single-player experience and becomes a shared workspace. Most of the core team’s attention is on keeping the synchronization layer provider agnostic. The default transport is HTTP polling, a safe bet on low-end shared hosting, but anything at enterprise scale will need more than that.
That makes custom sync providers the thing most developers will trip over. If you build for agencies or high-scale clients, the default polling transport will bottleneck your server and hand users stale data as soon as concurrency climbs.
If you are already in the internals, my earlier breakdown on building a custom sync provider in WordPress 7.0 covers the state logic underneath.
Working with custom sync providers
In WordPress 7.0 development, registering a sync provider lets you swap the default polling for WebSockets, or for a third-party service like Ably or Pusher. That is what keeps performance sane when several editors are in the same long-form post at once.
The API below is the hypothetical one proposed in the latest dev notes, so treat it as a sketch. A filter injects the provider class into the registry.
<?php
/**
* Registering a high-performance WebSocket Sync Provider.
*/
function bbioon_register_custom_sync_provider( $providers ) {
$providers['bbioon-websocket'] = [
'label' => __( 'Bbioon WebSocket Provider', 'bbioon' ),
'transport' => 'websocket',
'endpoint' => 'wss://sync.example.com/v1',
];
return $providers;
}
add_filter( 'wp_sync_collaboration_providers', 'bbioon_register_custom_sync_provider' );
Registration is the easy half. The work is in the implementation: handling disconnects, clearing the ghost cursors left behind when a client loses its socket, and reconciling data server side without taking out database locks.
Polling versus WebSockets
The polling provider ships by default for backward compatibility, and it is expensive. Put twenty people on twenty different posts and your admin-ajax.php or REST API endpoints take the hit. At that point a socket-based architecture stops being an upgrade and becomes the baseline.
I wrote up how these systems hold together under load in my notes on stability testing for real-time collaboration.
If the 7.0 sync work is eating your dev hours, I can take it on. I have been working with WordPress since the 4.x days.
The rest of the April 8 dev chat
Open Floor went to tickets around block API version 3, with a request that developers test their custom blocks against the refinements to contentOnly mode. The Make WordPress Core logs and the WordPress Developer Resources are where the details land.
