Issue with ServerSideRender with additional props

[HardeepAsrani]

I'm using Gutenberg's API to add additional attributes to core blocks, in a plugin like these:

• http://wordpress.org/plugins/blocks-animation
• http://wordpress.org/plugins/blocks-css

Now this works fine with all the blocks but with the ones that use ServerSideRender component. When these additional attributes are passed, the block responds with (sometimes after refreshing the page/editor):

Error loading block: Invalid parameter(s): attributes

I see that I can use block_attributes filter to pass these additional props and its data type, but is it the only way around? Or is it a bug with ServerSideRenderer's REST Route?

Update: Seems like block_attributes filter was removed before 5.0: https://github.com/WordPress/WordPress/blob/bc9dfcfeb1d384e3060ddc25c5755647dbe50985/wp-includes/class-wp-block-type.php#L200

So what to do with these additional attributes when a block user server-side renderer? If they don't work it's fine but the block crashes and that's not ideal.

[justintadlock]

I just ran into this problem myself with a plugin I'm building. Anyone know of a way to check for this so that I can not add my custom attributes to blocks that they wouldn't work on?

[HardeepAsrani]

In case anyone is facing this issue and wants to patch their plugin, this will be of help: https://github.com/Codeinwp/blocks-css/pull/5/files

[aristath]

I just came across this one too while working on a dynamic block...

[itsdavidmorgan]

Also encountered this issue while creating a custom block.

[neojp]

I came across this error by using ServerSideRender with the default className attribute in the advanced settings for the block following these instructions: https://developer.wordpress.org/block-editor/tutorials/block-tutorial/creating-dynamic-blocks/

This can be avoided by adding the className attribute in the register_block_type() function.

register_block_type( 'mynamespace/myblock', [
  'editor_script' => 'mynamespace-myblock',
  'editor_style' => 'mynamespace-myblock-editor',
  'render_callback' => 'mynamespace-myblock-render',
  'attributes' => [
    'className' => [
      'default' => '',
      'type' => 'string'
    ]
  ]
] );

Note: Adding className under the attributes object in the JS registerBlockType() function doesn't seem to help here - seems like defining them in the PHP register_block_type() function is the only way.

[epoplive]

'attributes' => [
    'className' => [
      'default' => '',
      'type' => 'string'
    ]
  ]

thanks @neojp that fixed my issue

[ndiego]

Does anyone know if progress has been made on fixing this in Core, or is the patch still the way to go. Ran into this yesterday in WooCommerce on all their blocks using server side rendering.

[youknowriad]

Is this still an issue? I'm not sure I understand the problem here? It sounds very related to how the core block supports work and now that all core blocks are registered server side we can just retrieve the block type from the registry and add any attribute we want.

[ndiego]

@youknowriad I am not sure, but I will test this weekend and report back. A couple of my plugins are using the patch outlined above, but that might not be needed anymore.

[ndiego]

Yes, this issue still exists. If you want to add your own custom attributes to any block that uses ServerSideRender, you have to 'register' the attributes in PHP using the workaround @HardeepAsrani outlined above. Adding the custom attributes in JS using the blocks.registerBlockType filter is not sufficient. You will get the 'Error loading block: Invalid parameter(s): attributes' error.

[youknowriad]

That doesn't seems like a problem to me, since this is a server side rendered block, it does make sense to register the attribute on the server and you can do so by retrieving the registered block on the server and altering its attributes definition.

[ndiego]

@youknowriad yup that makes sense. I might prepare a ticket for the handbook in the next week or so, because I think we should document, or at least note, that the blocks.registerBlockType filter does not work with blocks that are registered server side. I need to do more testing myself to see if the filters don't work at all, or there is just the attribute issue.

[github-actions]

Help us move this issue forward. Since it has no activity after 15 days of requesting more information, a bot is marking the issue as stale. Please add additional information as a comment or this issued will be closed in 5 days.

[github-actions]

This issue was closed because more information was requested and there was no activity. If this is a bug report and still a problem, please supply the additional information requested and reopen the issue.

[BenceSzalai]

This is pretty much still a problem. (see edit below)

In wp-includes/rest-api/endpoints/class-wp-rest-block-renderer-controller.php the register_routes() method defines the schema as 'additionalProperties' => false, but the editor sends on any additional properties registered in the editor using the blocks.registerBlockType hook with the request. This means that all server side rendered blocks created based on https://github.com/WordPress/block-development-examples/tree/trunk/plugins/server-side-render-block-d26119 will fail to render if any editor plugin added any any custom attributes using the blocks.registerBlockType filter.

Now it makes sense from a certain perspective that if a JS side filter registers a custom attribute for a block, but the server side render function does not declare support for that attribute there is an incompatibility between the server side rendered block and that extension.

In an ideal world a proper solution would be either:

• The server side rendered block should declare support for the given attribute, thus making it sure it is supported during the render, OR
• The editor plugin should exclude the given server side block fin the blocks.registerBlockType hook from adding custom attributes to.

The problem is in reality certain editor plugins would add some "global" settings to every block. For example those could be to control selective rendering based on external conditions etc. Such behaviour can work without explicit support from the targeted block, because a plugin can hook into the render_block PHP hook to for example skip the rendering of any block based on the settings configured in the editor and stored in additional custom attributes of the block. So it is not exactly true that a block would need to know and explicitly support such external attributes.

However by setting the schema definition to use 'additionalProperties' => false, this prevents two such plugins from working together, whereas they could work together just fine without them knowing and explicitly declaring support for each other.

The solution would be to add a filter that a plugin adding custom attributes to all blocks could use to actually enable it's own "additional properties" for server side rendered blocks, even if those blocks would not explicitly support those properties.

EDIT: Nevermind. I've figured I can use the block_type_metadata filter to add any "global" custom attributes to any blocks that are being registered and that way i can prevent the rest_additional_properties_forbidden errors.