Wp-calypso: Updated default block categories for Automattic blocks

[simison]

In Gutenberg 8.3.0 we have updated default block categories (https://github.com/WordPress/gutenberg/pull/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:

• [x] Updating blocks in Jetpack (https://github.com/Automattic/jetpack/issues/15708) (https://github.com/Automattic/jetpack/pull/16363)
• [x] Update categories in full-site-editing plugin (https://github.com/Automattic/wp-calypso/pull/43670)
• [x] Dealing with CoBlocks somehow (perhaps a script that re-organises them, or perhaps they have new versions with updated categories?). https://github.com/godaddy-wordpress/coblocks/pull/1535
• [X] Update categories in wpcom-blocks (https://github.com/Automattic/wpcom-blocks/pull/178)
• [ ] Update categories in block-experiments (https://github.com/Automattic/block-experiments/pull/110)
• [X] 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: https://github.com/WordPress/gutenberg/pull/19279#issuecomment-635982767

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 (https://github.com/godaddy-wordpress/coblocks/pull/1535); looking to go out in this week's release.

[sirreal]

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