Default attributes for block-support properties don't apply on dynamic blocks

[ryelle]

I'm building a dynamic block, which supports a handful of the built-in style settings (colors, spacing, etc). I can set defaults in block.json that apply in the editor, but when I view the front end, it's like nothing is set. get_block_wrapper_attributes only returns the block class name, none of the color classes are set, and no style attribute.

It appears that the default attributes don't exist in parsed_block, which is what apply_block_supports uses to render the values in PHP.

Editor, appears correct:

Front end, no styles:

An example block.json

This sets a default width, colors, and padding, but none of those are applied.

{
	"$schema": "https://schemas.wp.org/trunk/block.json",
	"apiVersion": 2,
	"name": "wporg/local-navigation-bar",
	"title": "Local Navigation Bar",
	"icon": "ellipsis",
	"category": "layout",
	"description": "A special block to handle the local navigation on pages in a section.",
	"textdomain": "wporg",
	"attributes": {
		"align": {
			"type": "string",
			"default": "full"
		},
		"backgroundColor": {
			"type": "string",
			"default": "blueberry-1"
		},
		"textColor": {
			"type": "string",
			"default": "white"
		},
		"style": {
			"type": "object",
			"default": {
				"spacing": {
					"padding": {
						"right": "var:preset|spacing|60",
						"left": "var:preset|spacing|60",
						"top": "16px",
						"bottom": "16px"
					}
				}
			}
		}
	},
	"supports": {
		"align": false,
		"color": {
			"text": true,
			"background": true,
			"link": true
		},
		"spacing": {
			"margin": true,
			"padding": true
		},
	},
	"editorScript": "file:./index.js",
	"editorStyle": "file:./editor-style.css",
	"style": "file:./style.css",
	"viewScript": "file:./view.js"
}

I think this is the same root issue as #50027, but it affects more than just the alignment.

[talldan]

It appears that the default attributes don't exist in parsed_block, which is what apply_block_supports uses to render the values in PHP.

From what I understand, the default are only usually returned when using an instance of the WP_Block:
https://github.com/WordPress/wordpress-develop/blob/1bd815adbbbb48d486a5519ed2a3d34eefe6a407/src/wp-includes/class-wp-block.php#L165-L192

This looks like the code that sets the $parsed_block:
https://github.com/WordPress/wordpress-develop/blob/1bd815adbbbb48d486a5519ed2a3d34eefe6a407/src/wp-includes/class-wp-block.php#L252-L263

I don't really know the code well enough to offer suggestions on how to fix it in a backward compatible way. This code has been untouched for years by the looks of it, but @youknowriad last modified it, so might be able to offer suggestions.

[youknowriad]

How do you set defaults in block.json? Do you redeclare the style attribute manually?

---

This issue looks like a symptom of the fact that the block parsing in the server is not done "fully". It's just the grammar parse. Unfortunately, there's no solution for that at the moment as introducing the full HTML parsing is too impactful.

I'm not really sure why we made sure the default attributes available when using $WP_Block instance, this feels like a hacky fix for me but there's a precedent, maybe we can find a way to use that in apply_block_supports as well?

[ryelle]

How do you set defaults in block.json? Do you redeclare the style attribute manually?

My block.json is in the issue description. I'm setting some attributes directly, and for spacing, I set style, following the docs for using block supports.

If it helps, for output my render function is simply:

function render( $attributes, $content, $block ) {
	$wrapper_attributes = get_block_wrapper_attributes();
	return sprintf(
		'<div %1$s>%2$s</div>',
		$wrapper_attributes,
		$content
	);
}

[dutchigor]

I'm encountering the same issue. See a minimal plugin demonstrating the issue here: https://github.com/dutchigor/wordpress-block-supports-render-callback-test

[colorful-tones]

I just hit this issue today. I would be keen to see some traction.

[SantosGuillamot]

This issue was also reported in this ticket: here. I've been able to reproduce it as well. Any clue/idea how can this be fixed?

[youknowriad]

The solution fix can be as I explained here #50229 (comment)

Make sure to include the default attributes to the "attributes" that are passed to apply_block_supports calls. I don't like this fix personally but also don't like the same fix that is present in WP_Block instance either (not sure when this was introduced) because it feels like we're hacking the code because we don't have a full "parser" in the server.

One potential approach as well would be to update parse_blocks in the server to always include the default attributes but it can be seen as a small breaking change as well.

[spencerfinnell]

I am running in to this as well.

If a block's style attribute has been touched/modified the attribute is saved in the block markup, otherwise it's not. Then accessing $attributes in the render_callback shows a mix of the default block.json value (unparsed) and the CSS preset variable that corresponds with the editor setting:

// Attribute is unchanged in the editor.
["style"]=>
   array(1) {
    ["spacing"]=>
      array(1) {
        ["blockGap"]=>
          string(7) "0.44rem"
        }
    }

// Attribute is changed in the editor.
["style"]=>
   array(1) {
    ["spacing"]=>
      array(1) {
        ["blockGap"]=>
          string(21) "var:preset|spacing|20"
        }
    }

Some additional discussion about default style attributes in block.json: #53603