Using blocks.registerBlockType block-filter to change core block markup. Is this how it's supposed to be done?

[ts-mz]

Hi,

I was looking for a way to wrap the inner blocks of the core/details block in a container-div to simplify animated toggling of the initially hidden content.

While I assume this is also possible using the render-block filter to change the markup only in the front-end, after a lot of googling I found this older tutorial ( https://jschof.com/gutenberg-blocks/using-gutenberg-filters-to-extend-blocks/ ) that explains how one can add a wrapper around the edit and save functions using the block-filter blocks.registerBlockType.

However, this also implies that, using this filter, the original edit and save functions of any registered block can also be completely replaced by new edit and save functions, in this case to add the additional div around the innerBlocks component. So I copied the relevant code from the Details block's DetailsEdit and save functions into two new functions called NewDetailsEdit and NewDetailsSave, and within those I added an additional wrapper div around the innerBlocks component.

function NewDetailsEdit( { attributes, setAttributes, clientId } ) {
  (relevant parts only)
	return (
            <details
	          { ...innerBlocksProps }
	          open={ hasSelection || showContent }
	          >
	          <summary onClick={ ( event ) => event.preventDefault() }>
		          <RichText
			          paramters omitted
		          />
	          </summary>
                  <div class="this-is-my-new-containter-class">
	                  { innerBlocksProps.children }
                  </div>
          </details>
	);
}

function NewDetailsSave( { attributes } ) {
  (relevant parts only)
	return (
		<details { ...blockProps } open={ showContent }>
			<summary>
				<RichText.Content value={ summary } />
			</summary>
			<div class="this-is-my-new-containter-class">
				<InnerBlocks.Content />
			</div>
		</details>
	);
}

After this I call the filter, adapted from the tutorial linked to above, and instead of the default edit and save functions call the new components that have the additional div.

const { addFilter } = wp.hooks;

/**
 * When this function gets run by the addfilter hook below, the filter passes it the block settings or config file
 * @param settings
 */
 const filterBlocks = ( settings ) => {
	if ( settings.name !== 'core/details' ) {
		return settings;
	}

	const newSettings = {
		...settings,
		edit( props ) {
			return (
				<NewDetailsEdit
					attributes = {props.attributes}
					setAttributes = {props.setAttributes}
					clientId = {props.clientId}
				/>
			);
		},
		save( props ) {
			return (
		 	        <NewDetailsSave
					attributes = {props.attributes}
				/>
			);
		},
	};

	return newSettings;
};

addFilter(
	'blocks.registerBlockType', // hook name
	'example/filter-blocks', // arbitrary
	filterBlocks // function to run
);

This works... this way I get a core/details block that has an additional wrapper div both in the editor and the front-end. My question is: is this how this kind of markup extension for core blocks, or potentially core-block-variations is supposed to be done?

I understand that changing the markup will lead to validation errors for extisting blocks, and that it may be simpler to just fork the details block into a custom block.

But still, this seems this is working method to achieve core block markup changes both in the editor and the front end. Is this how it's supposed to be done? Or maybe there's an even better method I'm unaware of?

Thanks for your input!

[bacoords]

I think a much simpler approach would be using a block variation to preload a Details block with a group block inside of it:

wp.blocks.registerBlockVariation( 
    'core/details', 
    {
		name: "details-with-div",
		title: "Details with div",
		innerBlocks: [
			[
				"core/group",
				{
					className: "this-is-my-container-div",
				},
				[["core/paragraph", { placeholder: "Summary" }]],
			],
		],
    }
);

Reference: https://developer.wordpress.org/block-editor/reference-guides/block-api/block-variations/

[ts-mz]

Yes, that is much simpler! Thanks for your input!

[bacoords]

Nice! I updated the snippet a bit to show the whole function for anyone else. If this works, then please mark it as the answer for others.

[justintadlock]

And just for good measure, here's how you can create the variation with PHP in WordPress 6.5+ if you prefer to avoid JS altogether:

add_filter( 'get_block_type_variations', 'themeslug_block_type_variations', 10, 2 );

function themeslug_block_type_variations( $variations, $block_type ) {

	if ( 'core/details' === $block_type->name ) {
		$variations[] = array(
			'name'        => 'details-with-div',
			'title'       => 'Details with div',
			'innerBlocks' => [
				[
					'core/group',
					[ 'className' => 'this-is-my-container-div' ],
					[
						[
							'core/paragraph',
							[ 'placeholder' => 'Summary' ]
						]
					]
				]
			]
		);
	}

	return $variations;
}

[bacoords]

Yep that should work, too! With the current issues with the PHP registration process for a handful of blocks, I haven't been recommending it yet: https://core.trac.wordpress.org/ticket/60856

[ts-mz]

I wonder if isdefault should also be specified in this case, so as to actually override the core block with the newly created variation? I understand that this can run into problems if more than one variation is marked as "default" , but that way it would truly be, at least from a user's perspective, a core block replacement.