Default block alignment class is not in get_block_wrapper_attributes

[warudin]

Description

I created a block, the settings are below in the block.json.

The block should have a full width alignment by default (mentioned here in the documentation: https://developer.wordpress.org/block-editor/reference-guides/block-api/block-supports/#align)

This works good in the editor. But in my render file, the get_block_wrapper_attributes() function is not outputting the align class.

The align class is only returned when I configure another block width then the one that’s in the attributes (so ‘none’ or ‘wide’). The default alignment is never returned, even after toggling another one and going back to the default alignment.

block.json:
{
	...
	"attributes": {
		"align": {
			"type": "string",
			"default": "full"
		}
		...
	},
	"supports": {
		"html": false,
		"align": [
			"wide",
			"full"
		],
		...
	},
	...
}

Step-by-step reproduction instructions

1. Configure a block to have a specific alignment (i.e. 'full') by adding it as a default value in attributes.align in block.json;
2. Configure and create a PHP render template file in block.json;
3. Use get_block_wrapper_attributes() to output the classes in the wrapper div;
4. Add the block to the editor and leave the default alignment configured, save the editor;
5. Check the classes being output in the front-end, the configured alignment will not be in the list that's being returned by get_block_wrapper_attributes().

Screenshots, screen recording, code snippet

No response

Environment info

• WordPress 6.2, Gutenberg 15.6.2, custom template (full site editing boilerplate)

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

[marcoluzi]

I got the same problem. Did you find a solution for that @warudin ?

[colorful-tones]

I would love to see this prioritized for the WordPress 6.5 release. Several issues are related, and it may be worth aggregating into a parent task.

@ndiego @gziolo, do you have any insight on the priorities here, please?

Some related issues:

• Style default attributes for block supports are not respected in dynamic render #52600
• Default attributes for block-support properties don't apply on dynamic blocks #50229
• Dynamic blocks: default values for attributes aren't converted into html comments #7342

[mrinal013]

I trapped on same situation as @warudin says. However, it may be fixed in upcoming release. In the meantime, I find out a temprary solution. My render.php is like

<div <?php echo get_block_wrapper_attributes( 
    array( 
        'class' => 'align' . $attributes['align']
    ) );  ?>>
<?php
echo $content;
?>
</div>

[michaeljansse-getsturdy]

This is exactly the same issue that I run into. I use ACF to be able to use render.php files for rendering my HTML. My block.json contains this:
"attributes": {"align": { "type": "string", "default": "left" }, }

But when I use get_block_wrapper_attributes(), the class alignleft is not added to the classes by default.
I hope this issue is fixed soon. The workaround I have now is to use the filter render_block_data() and add these default settings by default from the .json file if they are not present. That works, but is not the best solution...

[gziolo]

I confirmed the problem with the following unit tests that fails:

	public function test_dynamic_block_with_default_attributes() {
		$settings = array(
			'attributes'      => array(
				'content' => array(
					'type'    => 'string',
					'default' => 'Default content.',
				),
				'align' => array(
					'type'   => 'string',
					'default' => 'full',
				),
			),
			'supports'        => array(
				'align' => array( 'wide', 'full' ),
			),
			'render_callback' => function( $attributes ) {
				return '<p ' . get_block_wrapper_attributes() . '>'  . $attributes['content'] . '</p>';
			}
		);
		register_block_type( 'core/dynamic', $settings );

		$post_content =
			'before' .
			'<!-- wp:core/dynamic --><!-- /wp:core/dynamic -->' .
			'after';

		$updated_post_content = do_blocks( $post_content );
		$this->assertSame(
			$updated_post_content,
			'before' .
			'<p class="wp-block-dynamic alignfull">Default content.</p>' .
			'after'
		);
	}

[gziolo]

The fix:

diff --git a/src/wp-includes/class-wp-block-supports.php b/src/wp-includes/class-wp-block-supports.php
index c90b5e0c54..71d6b49691 100644
--- a/src/wp-includes/class-wp-block-supports.php
+++ b/src/wp-includes/class-wp-block-supports.php
@@ -104,7 +104,7 @@ class WP_Block_Supports {
 		}
 
 		$block_attributes = array_key_exists( 'attrs', self::$block_to_render ) && is_array( self::$block_to_render['attrs'] )
-			? self::$block_to_render['attrs']
+			? $block_type->prepare_attributes_for_render( self::$block_to_render['attrs'] )
 			: array();
 
 		$output = array();

I will fix the issue in the WordPress core and file a related Trac ticket (if there isn't one already).

prepare_attributes_for_render validates attributes against the current block schema, populating defaulted and missing values.

[gziolo]

Fix: WordPress/wordpress-develop#7438
Trac Ticket: https://core.trac.wordpress.org/ticket/62114

[gziolo]

It should be resolved after WordPress 6.7 gets released in November. Related commit: WordPress/wordpress-develop@7d0e751.

[odyn]

It should be resolved after WordPress 6.7 gets released in November. Related commit: WordPress/wordpress-develop@7d0e751.

I don't think it got resolved in 6.7. At least it's not working for me.

[gziolo]

@odyn, could you share more details about your use case so we could debug what’s happening?

[odyn]

Ok, sorry. I'm quite a beginner, but here it goes.
I'm using Wordpress 6.7, installed localy via Studio. Only the plugin I'm developing is active. I'm following the Block development Handbook.
This is my current block.json:

{
"$schema": "https://schemas.wp.org/trunk/block.json",
"apiVersion": 3,
"name": "create-block/vst-dogodki",
"version": "0.1.0",
"title": "VST Dogodki",
"category": "widgets",
"icon": "calendar",
"description": "Display event dates and times.",
"attributes": {
"showTicketLink": {
"type": "boolean",
"default": false
}
},
"supports": {
"color": {
"background": true,
"text": true
},
"html": false,
"typography": {
"fontSize": true,
"lineHeight": true,
"textAlign": true
},
"align": true,
"spacing": {
"margin": true,
"padding": true,
"blockGap": true
},
"ariaLabel": true
},
"textdomain": "vst-dogodki",
"editorScript": "file:./index.js",
"editorStyle": "file:./index.css",
"style": "file:./style-index.css",
"render": "file:./render.php"
}

In the GUI I DO get the options for the Colors, Typography (Size and Line Height) and Dimension (Padding, Margin and Block Spacing), but not for either textAlign or for align.

I may however have a bug somewhere, since I cannot click the block in the editor to select it, but only in the Document Overview.

[gziolo]

I may however have a bug somewhere, since I cannot click the block in the editor to select it, but only in the Document Overview.

In the editorScript (index.js) in the place where you have your edit component defined, did you integrate useBlockProps hook on the wrapper HTML element? More about the block wrapper in the handbook.

[odyn]

Well, I do have this in index.js:

import Edit from './edit';
import metadata from './block.json';

/**

• Every block starts by registering a new block type definition.
• @see https://developer.wordpress.org/block-editor/reference-guides/block-api/block-registration/
  /
  registerBlockType( metadata.name, {
  /*
  • @see ./edit.js
    */
    edit: Edit
    } );

and this in edit.js:
import { useBlockProps, InspectorControls } from '@wordpress/block-editor';
...

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

return (
    <div { ...useBlockProps }>
        <InspectorControls>
            <PanelBody title="Settings">
                <ToggleControl
                    label="Show Ticket Purchase Link"
                    checked={ attributes.showTicketLink }
                    onChange={ ( value ) => setAttributes({ showTicketLink: value }) }
                />
            </PanelBody>
        </InspectorControls>
        <ServerSideRender
            block="create-block/vst-dogodki"
            attributes={ attributes } 
        />
    </div>
);

}

So I'm guessing yes?

[gziolo]

Can you try the following change?

- <div { ...useBlockProps }>
+ <div { ...blockProps }>

[odyn]

Hm no ... that returns an error: " This block has encountered an error and cannot be previewed.".

…

On Fri, Nov 22, 2024 at 9:42 AM Greg Ziółkowski ***@***.***> wrote: Can you try the following change? - <div { ...useBlockProps }>+ <div { ...blockProps }> — Reply to this email directly, view it on GitHub <#50027 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AASXB3CUXDQ2NSNLTPWTA432B3U6JAVCNFSM6AAAAABOIACTBOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOJTGE4TONJSGM> . You are receiving this because you were mentioned.Message ID: ***@***.***>