Closed nicktrosnant closed 1 month ago
Wow! Yet more uncovered corners in WordPress. Well done Nick for finding this! This needs to work even if the callback code is called from the shortcode rather than as a block. I don't know what get_block_wrapper_attributes() does if there is no current block. I know we probably don't want users to use the shortcode version, but it is there in the current documentation!
When processing a shortcode, I guess that there is no requirement to consider the block attributes as these are only available when using the block? Looking at the code, get_block_wrapper_attributes() returns a null string if it can't locate any block attributes. But calling it without a block active may perhaps result in PHP warnings/errors? Need to dig a bit more!
Also noted that the results of get_block_wrapper_attributes() should be escaped using
wp_kses_data( get_block_wrapper_attributes() );
Ref on Stack Exchange
Propose that this change should be applied to the following blocks:
In the render callback code that is used to generate the HTML code for the blocks such as the event list, our current code hard-codes the class name in the opening div for the block being rendered.
For example, the event list block uses the code:
$html = "<div class=\"u3aeventlist\">\n";
This ignores any additional block properties that may have been set up by the user. In particular, any additional CSS class names that may have been specified in the Advanced section of the properties panel are ignored.
The way for the render callback code to properly handle this is for it to use the get_block_wrapper_attributes() call to set the string of attributes for the block's wrapper div.
So for the u3a event list, the preferred approach would be
If XTRACLASS is specified as an additional CSS class names this would render as:
<div class="u3a-eventlist XTRACLASS wp-block-u3a-eventlist">