Updated default block categories for Automattic blocks

[simison]

In Gutenberg 8.3.0 we have updated default block categories (WordPress/gutenberg#19279). Those are now running on edge sites, and within a week on production. These new categories are now in production.

We'll need to match Automattic block categories with new categories.

We'll also need to keep supporting old default categories for Atomic sites which might not run Gutenberg.

The tasks needs:

• Updating blocks in Jetpack (Block Categories Updates jetpack#15708) (Update blocks categories jetpack#16363)
• Update categories in full-site-editing plugin (FSE: Update blocks categories #43670)
• Dealing with CoBlocks somehow (perhaps a script that re-organises them, or perhaps they have new versions with updated categories?). Tweak categories in support of new categories within the Gutenberg plugin godaddy-wordpress/coblocks#1535
• Update categories in wpcom-blocks (https://github.com/Automattic/wpcom-blocks/pull/178)
• Update categories in block-experiments (Update blocks categories block-experiments#110)
• Pulling in Create-focus designer to figure out where each block should go in new categories (feel free to suggest!)*

*We announced this initiative and asked for feedback here: pbAok1-18e-p2

Screenshots

The goal is just to illustrate what the change is about and how it reflects in the UI. If you'd like to know all categories that have been changed, check the PRs linked above.

image-compare (Jetpack)

GB with legacy categories	GB with updated categories

a8c/layout-grid (block-experiments)

GB with legacy categories	GB with updated categories

[sirreal]

Gutenberg ships with some compatibility mappings (PHP and JS) that will ensure legacy categories aren't broken.

I'm slightly more concerned about using the new category names where we may not be on a recent editor version. I did some quick testing and it suggests if categories are updated before the plugin, the block won't be registered. Instead, you'll see a consol error like The block "my-block/name" must have a registered category.

It may be best to go slow on this change. Legacy categories are compatible with updated categories, but updated categories are not compatible with the legacy ones.

[sirreal]

I asked if there are recommendations about how block authors should handle this in core-editor slack: https://wordpress.slack.com/archives/C02QB2JS7/p1591974296075900

[sirreal]

Here's the recommendation: WordPress/gutenberg#19279 (comment)

Namely, check if the category exists before you use it:

var hasFormattingCategory = wp.blocks.getCategories().some( function( category ) {
   return category.slug === 'formatting';
} );

wp.blocks.registerBlockType( 'my-plugin/my-block', {
   category: hasFormattingCategory ? 'formatting' : 'media',
} );

Note that example checks for a legacy category. I'd have expected to check for the new category and fallback to the legacy category otherwise.

[richtabor]

var hasFormattingCategory = wp.blocks.getCategories().some( function( category ) {
   return category.slug === 'formatting';
} );

wp.blocks.registerBlockType( 'my-plugin/my-block', {
   category: hasFormattingCategory ? 'formatting' : 'media',
} );

This is what we're doing in CoBlocks (godaddy-wordpress/coblocks#1535); looking to go out in this week's release.

[sirreal]

With Automattic/block-experiments#110 handed off and everything else merged, I think we're good to close this. Thanks @fullofcaffeine!