Add CPTs and taxonomies for: blocks, block examples etc

[bobbingwide]

In q.w/hm I started documenting Gutenberg blocks as CPT's created using oik-types. I now want to formalise the definitions of the CPTs. For oik plugins the most sensible place to do this is in the oik-shortcodes plugin.

Type	Plural	Singular	Description	Hierarchical?	Archive?
block	Blocks	Block	WordPress Blocks and their mapping from meta boxes	Y	Y
metabox	Meta Boxes	Meta Box	Meta boxes used in the Classic Editor	Y	Y
sidebar	Sidebar boxes	Sidebar box	Side bar boxes appear as Settings.	Y	Y

The new CPTs also require a number of fields.

Note: wp_block is a core CPT used to store reusable blocks. It has the same labels as block.

[bobbingwide]

Note: In Gutenberg v4.5.1 Sidebar boxes are known as Panels. There are Document panels, Advanced panels and, I assume, Block panels.

[bobbingwide]

Fields for the block CPT are:

Field	Type	Notes	Example
_block_name	text	Unique block name	oik-block/wp
_block_icon	sctext	Icon for the block	[bw_dash wordpress SVG64]
block_category	category	Block category	static, dynamic, server side rendered

[bobbingwide]

Looks like we'll need Block examples ( similar to Shortcode examples ) before Meta boxes and Sidebar boxes / Panels.

[bobbingwide]

We also want to add a Blocks tab to any plugin that delivers Blocks.

[bobbingwide]

There are two co-requisite changes for adding the Blocks tab.

• Issue #61 adds the [blocks] shortcode, based on the [codes] shortcode.
• https://github.com/bobbingwide/oik-plugins/issues/15 adds the Blocks tab.

[bobbingwide]

Some minor changes:

• Some of the CPTs need post_type_supports author.
• The _block_icon field is no longer required.
• We need to display the Block Categories as a field in [bw_fields] / the Fields block.

[bobbingwide]

For the time being at least I reckon that Blocks and block examples should be included on the Home page blog. This will help with SEO for oik-plugins.com ( and .co.uk ), bobbingwidewebdesign.com and possible wp-a2z.org

[bobbingwide]

Having started populating https://blocks.wp-a2z.org with some of the plugins that deliver blocks, I now want to be able to generate the basic structure of each instance of the block post type for all the blocks that these plugins deliver.

For the following 9 plugins there are 144 blocks. Once each block has been created it'll be easier to see them all listed on the Blocks archive.

Plugin	Blocks
Advanced Gutenberg	18
Advanced Gutenberg Blocks	14
Atomic Blocks	11
Caxton	11
CoBlocks	20
Ghost Kit	29
Kadence	9
oik-blocks	20

Do you have any idea how many different Accordions and Buttons there are already? We'll find out soon enough.

Proposed solution

• [x] Create a template for the block CPT, registered using PHP
• [x] Create a batch routine to generate a basic block with the same structure as the template

[bobbingwide]

May as well create a template for oik-plugins while we're at it.

[bobbingwide]

I think I need to change the block_category taxonomy to be used to store the Category field defined for the block. The taxonomy to be used for the current data will be block_classification.

It may also be necessary to create a CPT called block_plugin, which documents the plugins and extensions delivered by plugins/themes. E.g. Yoast SEO, GhostKit, CoBlocks. I.e. the things registered by registerPlugin. These are similar to Panels, about which I’ve done nothing yet.

[bobbingwide]

The currently registered blocks have taxonomy terms for block_category We could either automatically change these to block_classification or perform the update manually. The required SQL is:

update wp_term_taxonomy set taxonomy = 'block_classification' where taxonomy = 'block_category';

This would need to be run about the same time as updating the plugin. There aren't that many to do, and since the blocks would need manual updating anyway it might not matter if we forget. The SQL should only be run once... when there aren't any terms for block_classification.

[bobbingwide]

Now that we have multiple taxonomies we should improve the display of the Blocks tab to show a more complete summary of the registered blocks. i.e. Change from [bw_list] to [bw_table fields=title,excerpt,block_category,block_keyword,block_classification].

For the block icon to be displayed the Excerpt should be left blank and the more tag be after the block info block. The block info block need only display the block's icon and description. All the other fields for the block info block are belt and braces; being cross references to block title, block type name and block category and block keyword taxonomies.

[bobbingwide]

The [blocks] shortcode should be able to display a list of blocks identified by their block type names.

e.g. [blocks core/paragraph,core/list]

This shortcode can then be used in documentation for Transforms, Nested and reasons to create links to blocks. We may need to be able to deal with the block_type_name being multiply defined. As Core and Gutenberg both use the namespace prefixes core and core-embed.

It's time to create a new issue for this.

[bobbingwide]

To support plugins which provide their own documentation we should add a _block_doc_link field for the Block CPT. This should be displayed after the Block type name.

WordPress.org does not have an individual page for every block. In this case we should just point to https://wordpress.org/support/article/blocks/

[bobbingwide]

The code was delivered to wp-a2z.org in v1.35.0. This can now be closed.