Create a block icon & block info block to display a block's icon & information

[bobbingwide]

WordPress / Gutenberg delivers many icons which are used to help selection of the blocks in your content. The SVG for these icons is often hand crafted. Sometimes it's a dash icon, but not often.
In the block documentation in WP-a2z we need to display the actual BlockIcon for the selected block.
For most blocks we can find this using the block name. e.g. core/audio.

Initially this block will be delivered as a static block.

[bobbingwide]

Additional requirements.

• Optionally display the following information for the block:

Field	Example
registered block type name	oik-block/blockicon
title:	Block icon
description:	Displays a Block icon
category:	widgets
keywords:	icon, oik, block

[bobbingwide]

So now I've updated oik-blockicon to optionally display the registered block type name, title and description.

But it breaks the existing oik-blockicon blocks.

I now want to:

• clone the blockicon block to blockinfo,
• revert the blockicon logic to how it was before I started fiddling
• alter blockinfo to use the original blockicon code to display the BlockIcon part
• and use blockinfo code to display the other fields for the Block
• implement the capability to transform between blockicon and blockinfo

Then I won't break existing blockicon blocks.

This is where I currently am with the blockicon & blockinfo blocks

[bobbingwide]

I think I now have a need for a Block icon/info link. This will be a link to the documentation of the Block. The link URL will be constructed using the blockname or automatically found based on the selected block name.

[bobbingwide]

Another requirement is a block showing all the blocks for a plugin in a similar layout to the Add Block dropdown. See the dash icon block. This would be used on the plugin’s home page.

[bobbingwide]

Let's take the previous two comments and produce a Block list. I'll raise a separate issue for this as eventually the Block list block might be moved to the oik-shortcodes plugin.

[bobbingwide]

Time to add the Category and Keywords fields to the Block info block. Default false. This will help with manual setting of the block_category and block_keyword taxonomies.

[bobbingwide]

When I added. The Category and Keywords fields ( toggles ) I set the both to default: false in the hope that this would not break existing blocks. That failed, so I let the defaults be true. It still failed. Blocks which were valid with the previous version of the code are now no longer valid.
One of the annoying things is that it’s the viewBox parameter of the svg tag that appears to be in error. According to WordPress/gutenberg#9898 this bug has been fixed. Not for me. Maybe I’m suffering from a different issue....
WordPress/gutenberg#12932

Perhaps adding some migration logic and/or disabling validation is necessary.

[bobbingwide]

When the block info is displaying an icon for a block which is no longer registered the editor displays a WSOD with the following in the console.

Uncaught TypeError: Cannot read property 'title' of undefined
    at BlockinfoStyled (webpack-internal:///326:33)
    at save (webpack-internal:///323:240)
    at tt (index.js:2)
    at rt (index.js:2)
    at index.js:50
    at index.js:1
    at Ft (index.js:2)
    at Zt (index.js:2)
    at index.js:2
    at Array.reduce (<anonymous>)

Workaround

• activate the plugin
• edit using the classic editor

[bobbingwide]

Add support for the block icons that exist but not as blocks.
e.g. the Classic block icon - which is a keyboard.
Bad example... Classic Block is core/freeform, which does exist.

[bobbingwide]

It would be nice to support multiple sizes for the blockicon block. First stage is to write the SCSS for different sizes: svg100 and svg150.

[bobbingwide]

To tidy things up a bit eliminate the spaces around the content in the additional divs following the icon.

[bobbingwide]

With Gutenberg 5.9.0 a block icon / block info might appear correctly in the editor but disappears on the front end. The SVG tag is not being saved.

• When I upgrade from 5.8.0 to 5.9.0 the block icon is displayed with This block contains unexpected or invalid input.
• Choosing Attempt block recovery appears to fix it.
• Switching to the code editor shows that the SVG tag is no longer present.
• But if you switch back to visual the icon reappears.

Explanation

I don't yet know what's causing the problem.
Perhaps a filter that strips unwanted tags is being invoked.
Is remove_kses_filters() active?
There are also lots of deprecated messages in the console.

Not surprisingly the problem also affects the Block list block.

This might be the same problem as I'm getting for Caxton Layouts block... which fails to display any content created with Gutenberg 5.9.0.

[bobbingwide]

The possible explanation for the problem is that in the Gutenberg Javascript code, deprecation logic is not implemented in the way I've grown to expect it.

The message should be displayed but the original logic should still work.

Changing my code to import BlockIcon from wp.blockEditor worked...
but I believe I shouldn't have had to do this.
There should be a time period where deprecated code continues to work.

See also, Automattic/jetpack#12673 (comment)
which would probably explain why Caxton Layouts doesn't work either.

I've updated my code for my blocks which use BlockIcon.
I'm not sure whether or not I need to change the dependencies in the PHP code calling wp_register_script. Should wp-editor be changed to wp-block-editor or should I add wp-block-editor or doesn't it matter at all?
Hopefully WordPress/gutenberg#16152 will fix the issue for Caxton.

[bobbingwide]

Just noticed in my development environment that my block names are being capitalised in the drop down list for block icon and block info.

Similarly, the prefix drop down is showing capitalisation, but the HTML seems OK.

<select id="inspector-select-control-7" class="components-select-control__input"><option value="core">core</option><option value="core-embed">core-embed</option><option value="editor-blocks">editor-blocks</option><option value="oik-block">oik-block</option><option value="uagb">uagb</option><option value="yoast">yoast</option></select>

Explanation
This is being done by some CSS in the ultimate-addons-for-gutenberg plugin.

.components-select-control__input{
	text-transform: capitalize;
}

[bobbingwide]

When I updated to WordPress 5.3 the SVG for the Group block looks OK in the block info and block list but not on the front end. The inner part of the block is black.
Removing class svg64 doesn't affect the display.

[bobbingwide]

In s.b/oikcom the Advanced class svg64 is not styling the block icon correctly. Is this a custom CSS thing or what?

[bobbingwide]

I think it's time to close this issue. There may still be problems with the blockicon, blockinfo and blocklist blocks but should be addressed as separate issues. v1.3.0 was released on 2021/11/18