u3a-siteworks-development / u3a-siteworks-core

The core plugins
GNU General Public License v2.0
1 stars 0 forks source link

OP1045 u3a blocks do not implement support for additional CSS classes #80

Closed nicktrosnant closed 1 month ago

nicktrosnant commented 3 months ago

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

$blockattrs = get_block_wrapper_attributes(['class' => 'u3a-eventlist']); // the class name we want
$html = "<div class=$blockattrs>\n";

If XTRACLASS is specified as an additional CSS class names this would render as:
<div class="u3a-eventlist XTRACLASS wp-block-u3a-eventlist">

mike99christie commented 3 months 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!

nicktrosnant commented 3 months ago

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!

nicktrosnant commented 1 month ago

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

nicktrosnant commented 1 month ago

Propose that this change should be applied to the following blocks: