WordPress 7.0 features are landing fast, and the shiny new tools are taking the headlines while the interesting work sits in the plumbing underneath. Between Beta 3 and the security sweep in 6.9.2, a staging environment that has not been updated yet is already out of date.
I have watched release cycles for 14 years, and 7.0 has the feel of a foundational shift, close to what Gutenberg was. Before the new toys, though, there is a fire to put out today: the WordPress 6.9.2 security release.
The 6.9.2 patch comes first
Read the advisory if you have not. It patches ten vulnerabilities, among them a blind SSRF and a PoP-chain weakness in the HTML API. These are the kind of holes that end in a full site takeover if you run complex nav menus or use the data-wp-bind directive. Patch before you do anything else on this list.
Real-time collaboration and its internal plumbing
Real-time Collaboration (RTC) is the most awaited of the WordPress 7.0 features, and it does not use WebRTC. The team took the pragmatist’s route and went with an HTTP polling sync provider, because WebRTC is a nightmare to support across every host on the planet.
Under the hood it runs on Yjs, with a custom internal post type called wp_sync_storage for storage. Conflict-free Replicated Data Type (CRDT) updates go into post_meta. The sync provider architecture is swappable by design, so you can adjust the defaults or drop in a different provider with a constant in your config.
// You can tweak RTC limits or providers via wp-config.php
define( 'WP_RTC_MAX_COLLABORATORS', 5 );
For the longer-term picture behind these changes, see my thoughts on WordPress 7.0 development and the AI client debate.
AI connectors: one interface at last
AI handling is finally provider-agnostic. WordPress 7.0 adds a Connector feature built on the php-ai-client package, and it sits at platform level rather than inside each plugin. Instead of every plugin author writing an OpenAI or Anthropic integration, we all code against one shared interface, and switching providers becomes a configuration change on the new Connectors screen.
If you are building block-based AI tools, stop writing proprietary API handlers and work out how to hook into the package instead. It spares you from tracking API changes across five different LLM providers.
Gutenberg refinements: content-only becomes the default
Patterns now default to content-only editing. That trims UI clutter for clients and gets in the way of any developer who needs structural access. You can opt out globally or per pattern with a filter.
<?php
// bbioon_disable_content_only: Keep structural access open for unsynced patterns
add_filter( 'block_editor_settings_all', function( $settings ) {
$settings['disableContentOnlyForUnsyncedPatterns'] = true;
return $settings;
} );
Revisions also get visual change tracking, with color-coded overlays: green for additions, red for removals, and a yellow outline for modified block settings. Clients can see what changed for themselves, which cuts down the “what did I break?” phone calls.
WP-CLI and local dev tooling
For anyone who lives in the terminal, the new wp block and ability commands matter. Block entities are readable from the CLI at last, read-only for now, with stable support for pattern exports arriving in v3.0 later this month. wp-env also supports phpMyAdmin in the Playground runtime now, which puts it level with Docker setups minus the overhead.
If this WordPress 7.0 features work is eating your dev hours, hand it to me. I have been wrestling with WordPress since the 4.x days.
Takeaway for devs
7.0 reads as an architectural cleanup. The standardized AI interfaces, the RTC polling provider and the SVG Icon Registration API all push the WordPress way toward something more structured. Use the Beta cycle to refactor your legacy hooks and to check that your themes honor the new block-defined feature selectors. Stability in 7.0 will come from following the new standards instead of hacking around them.
