Dynamic blocks with useBlockProps() are double-wrapped in editor and do not receive .wp-block-* class

[pixelwatt]

Description

When creating a dynamic block (registered with a PHP render_callback and no JS save() function), applying useBlockProps() to the top-level element in edit() does not prevent double-wrapping in the block editor.

In this case:

• The block is rendered inside a wrapper
  in the editor.
• The developer’s own wrapper (the one using useBlockProps()) does not receive the expected .wp-block-[name] class.
• This leads to inconsistency between editor and frontend.

This happens even when:

• edit() returns a single root element
• useBlockProps() is used correctly
• BlockControls and Popover are moved outside the main return
• A save() function is defined as () => null or () => <div {...useBlockProps.save()} />

What’s been tried:

• Moving all controls outside the main wrapper
• Adding a save() function that returns null
• Adding a save() function with useBlockProps.save()
• Avoiding any fragments or sibling return nodes

Impact:

This causes editor-styling bugs when relying on .wp-block-[name] selectors (especially with theme.json). It forces developers to write fragile CSS selectors or override unwanted inner wrapper behavior with layout hacks. It also makes using theme.json to set default styles untenable, as CSS is going to have to be provided for the backend anyway (since the auto-generated styles use a selector that isn't applied)

⸻

Suggested Fix Direction:

Ensure that when:
• useBlockProps() is returned as the top-level node,
• save() is null or present,
• and the structure is otherwise valid,

…the block is not wrapped again in a fallback .wp-block div.

Step-by-step reproduction instructions

1. Register a dynamic block using register_block_type() with a PHP render_callback.
2. In JS, define a block with an edit() function that returns a single <div {...useBlockProps()}>.
3. Do not define a save() function (or define a null-returning one).
4. Observe the rendered block in the editor DOM.

Expected:

...

Actual:

...

Screenshots, screen recording, code snippet

No response

Environment info

• WordPress 6.8.1, Method theme (custom)
• Chrome 137.0.7151.120, MacOS 15.4.1
• Gutenberg plugin active or not — issue occurs in both
• Block is fully dynamic (render_callback only)
• useBlockProps() applied directly to return root
• Global theme stylesheet (no per-block enqueued styles)

Please confirm that you have searched existing issues in the repo.

• Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

• Yes

Please confirm which theme type you used for testing.

• Block
• Classic
• Hybrid (e.g. classic with theme.json)
• Not sure

[t-hamano]

@pixelwatt Thanks for the report. Could you provide a code example for the Edit component?

[yashjawale]

Based on the given information, I tried reproducing the issue but couldn't. I've tried with dynamic blocks in the following contexts:

• With render.php in Block theme
• With render.php in Classic theme
• With render_callback in Block theme
• With render_callback in Classic theme
• All the above options in WordPress version 6.8.1 and 6.5.5

Although I do remember the situation described in the issue occurring in the past while creating a block...

But for some reason, I'm not able to replicate the issue now

edit.js

import { __ } from '@wordpress/i18n';
import { useBlockProps } from '@wordpress/block-editor';

export default function Edit( { attributes } ) {
	const blockProps = useBlockProps();

	return (
		<div { ...blockProps }>
			<p>{ __( 'Hello World (Editor)', 'my-plugin' ) }</p>
		</div>
	);
}

my-block.php

<?php
/**
 * Plugin Name: Hello World Block
 */

add_action( 'init', function() {
	register_block_type( __DIR__ . '/build/my-block/block.json', [
		'render_callback' => 'my_plugin_render_hello_world_block'
	] );
} );

function my_plugin_render_hello_world_block( $attributes, $content, $block ) {
	$wrapper_attributes = get_block_wrapper_attributes();
	return sprintf(
		'<div %s><p>%s</p></div>',
		$wrapper_attributes,
		__( 'Hello World', 'my-plugin' )
	);
}

Markup generated in Editor:

Markup generated in Frontend:

@pixelwatt It'll be helpful if you could provide a code snippet that demonstrates the behavior