By WordPress 7.2 Beta 1 arrives October 20. Six weeks is not a lot of runway, and the September developer roundup just confirmed two deprecated APIs with hard removal deadlines attached. On the good news side, autoRegister is finally in the block.json schema — meaning your IDE now validates the flag you have been typing by memory since WordPress 7.0. Here is what changed, what you need to fix, and what is coming.
Fix Your InnerBlocks Template Props Now
This is the most urgent item in Gutenberg 23.9. The template and templateInsertUpdatesSelection props were moved from the <InnerBlocks> component into block type settings registered via registerBlockType(). The old props still work today, but they are officially deprecated and will be removed before WordPress 7.2 ships.
The reason for the change is real-time collaboration. The old prop applied the template after mount, on each connected client. Insert a List block with three users in the document, and you got three list items — one per user. Moving the declaration into block type settings means a single atomic store operation: one insert, one result, regardless of how many editors are watching.
The migration is straightforward:
// Deprecated — remove before WordPress 7.2
<InnerBlocks
template={ [ [ 'core/list-item' ] ] }
templateInsertUpdatesSelection={ true }
/>
// Correct approach
registerBlockType( 'my-plugin/list', {
template: [ [ 'core/list-item' ] ],
templateInsertUpdatesSelection: true,
// … rest of block definition
} );WordPress core has already migrated roughly twenty blocks. Third-party blocks are on their own clock.
Update @wordpress/dataviews If You Bundle It
DataViews removed its dependency on @wordpress/private-apis in Gutenberg 23.9. If you have ever seen “Cannot unlock an object that was not locked before” while building a plugin that bundles @wordpress/dataviews, this is where that error comes from: two copies of the private-APIs runtime in one bundle cannot unlock each other’s objects.
The components DataViews previously pulled from private APIs now live in public packages. Calendar and RangeCalendar moved into @wordpress/ui. ValidatedInputControl is now public. withIgnoreIMEEvents landed in @wordpress/keycodes. Update to the latest version of the package and the error goes away.
autoRegister Is Now in the block.json Schema
This one has been a small annoyance since WordPress 7.0 introduced PHP-only block registration in March. The autoRegister flag worked — WordPress auto-generated Inspector Controls from your attribute definitions and used ServerSideRender for preview — but it was invisible to your IDE. No autocomplete, no validation, just typing from memory and hoping for the best.
Gutenberg 23.9 added it to the official block.json schema. VS Code, PhpStorm, and anything else that reads the schema now validates and autocompletes the flag. If you are building PHP-only blocks and have not tried autoRegister yet, it is the fastest path to a working block editor UI without a JavaScript build step:
register_block_type( 'my-plugin/example', array(
'attributes' => array(
'title' => array( 'type' => 'string', 'default' => 'Hello World' ),
),
'render_callback' => function ( $attributes ) {
return sprintf( '<div %s>%s</div>',
get_block_wrapper_attributes(),
esc_html( $attributes['title'] )
);
},
'supports' => array( 'autoRegister' => true ),
) );WordPress generates the editor UI, handles the preview via ServerSideRender, and you write zero JavaScript. The Block Registration Handbook covers the full API if you want to go deeper.
The Code Reference Now Runs in Your Browser
WordPress 7.1 shipped the first runnable examples in the Code Reference, and September confirmed more are live. The mechanism is WordPress Playground: click “Run” on any code snippet marked as interactive, and it executes against a real WordPress install inside your browser tab. No local environment, no Docker, no switching to another tab. The examples are defined in source DocBlocks using a php interactive code fence, which means they stay in sync with the code they document. More are coming with WordPress 7.2. The Code Reference has needed this for years.
Two Smaller Additions Worth Your Attention
The @wordpress/kebab-case package is now available on the JavaScript side. It replicates the behavior of PHP’s _wp_to_kebab_case(), including its opinionated handling of numbers: kebabCase('font2xl') returns 'font-2-xl'. If you have been generating CSS variable names in both PHP and JavaScript and wondering why they occasionally do not match, this package eliminates that class of bug.
The post editor, widgets editor, and customizer widgets editor are now wrapped in a ThemeProvider seeded from the user’s active admin color scheme. getAdminThemeColors() is now a public export of @wordpress/admin-ui, and you can use it to make your plugin’s UI panels match the admin theme rather than always defaulting to the blue scheme.
What Is Coming in WordPress 7.2
Beta 1 is October 20–22. The release candidate is November 17–19. Final ships December 8–10. The headline features are an expansion of real-time collaboration (pulled from 7.1 when it was not ready) and the first steps toward native multilingual support in core. Site Editor v2 is actively in development — Gutenberg 23.9 included roughly twenty PRs toward it, covering identity routes, theme preview with Global Styles editing, and canvas navigation between entity records.
The full September developer roundup is on the WordPress Developer Blog. If you maintain blocks or plugins that touch the editor, review the deprecation items now — Beta 1 in six weeks is not as far away as it sounds.
