A long-time client called me last month in a mild panic. They run a news site with about fifteen editors, and the editors kept overwriting each other. Someone would spend an hour on a headline, then a colleague would save a one-character typo fix and the headline would be gone. My first thought was one of those heavy-handed post locking plugins, but that is a band-aid on the wrong wound. What they need is Phase 3 of the WordPress 7.0 roadmap: real-time collaboration.
Collaboration has been talked about for years, but the planning for 7.0 reads like the end of the experimental stage. It has moved past Notes into real-time diffing and syncing that holds up in use. Anyone who has done much WordPress development knows how hard it is to sync content between several users without opening up a race condition. This is not a UI change. It is infrastructure work, and it needs serious server-side support, which is part of what the core team is hashing out in the official Core planning post.
The reality of the WordPress 7.0 roadmap
The largest change under the hood is the jump to React 19. I read that as another library bump at first, which was wrong. React 19 changes enough that plugin developers will have to rethink how they handle state. If your site runs on a pile of legacy Gutenberg blocks that nobody has touched in a while, that is where the pain will land. Start auditing your custom block dependencies now rather than during the upgrade.
There is better news for anyone worn down by the “This block is broken” message. 7.0 adds block validation levels, which is a way of making the editor more forgiving. Rather than failing hard when an attribute is slightly off, the engine tries to recover. That helps most on sites you have handed over to clients who occasionally poke at the HTML in a code block.
On the same theme, there is ongoing work on Block Bindings. Binding block attributes to custom dynamic data sources is getting close to something you can do without ten intermediate hoops. A simplified version of registering a custom source for those bindings might look like this:
/**
* Conceptual registration for a custom bbioon data source in 7.0
*/
function bbioon_register_custom_binding_source() {
register_block_bindings_source( 'bbioon/custom-data', array(
'label' => __( 'My Custom Meta', 'bbioon' ),
'get_value_callback' => 'bbioon_get_binding_value',
) );
}
add_action( 'init', 'bbioon_register_custom_binding_source' );
function bbioon_get_binding_value( array $source_args ) {
// Logic to grab the specific meta or API data
return get_post_meta( get_the_ID(), $source_args['key'], true );
}Then there is the AI Client API. I am as tired of AI announcements as anyone, but the core team is going about this sensibly. No specific provider gets bundled into core, whether that is OpenAI or Gemini. Instead they are building a uniform API that developers point at whatever provider they want, which keeps core small and leaves the choice with you.
Practical takeaways for site owners
- Real-time collaboration is the headline feature, so plan for Google Docs-style editing and for the extra load it puts on your server.
- React 19 will break badly written blocks. Get your dev team through the custom code sooner rather than later.
- Block validation gets more forgiving, which means fewer broken-block errors for your editors.
- The modern admin look becomes the default, which makes it easier to sell clients on current WordPress.
Most of this gets fiddly in practice. If you have inherited someone else’s setup and you want it to keep working through the updates, my team does this work. Send us a message.
I am curious which way people are leaning on 7.0, the features or the upgrade work. Comments are open.
