Gutenberg-related commands

[swissspidy]

I just stumbled upon https://twitter.com/johnbillion/status/1071563623280070656 again and was wondering what kind of WP-CLI commands we should add to make interaction with block-based blogs easier.

For example:

• List registered blocks
• List all blocks in post content
• Run block parser against given string

[johnbillion]

There's very little server side interface to Gutenberg, so we're quite limited in what can be done on the CLI. WordPress/gutenberg#4116

Here's some requests I've seen mentioned at HM and elsewhere:

• Ability to filter result sets by block based or non block based posts.
• Ability to convert non-Gutenberg posts to block-based posts (to remove responsibility from the client) along with reporting of non-transformable or potentially problematic markup.
• Ability to fetch IDs of all posts that contain a given block type. Ended up doing it via a regular string search.
• Ability to replace a block instance with another.

[swissspidy]

Ability to filter result sets by block based or non block based posts.

This reminds of the block_version() function which returns the version of the block format that the content string is using. This is something that could be exposed when listing posts etc.

Ability to convert non-Gutenberg posts to block-based posts

This is probably not gonna be possible as all the block transforms are written in JavaScript.

Ability to fetch IDs of all posts that contain a given block type

👍 + including reusable blocks.

[schlessera]

This is probably not gonna be possible as all the block transforms are written in JavaScript.

Easy... => wp eval-js "transform_block( source, dest );" ;)

[dominic-p]

Something else that might be worth considering here is updating non-dynamic blocks when the block definition is modified. Right now, it seems like the only way to do that is to manually open every post where the block is used and resave it.

I've been following the discussion here about this for a little while and WP-CLI was mentioned as a possible solution. Of course, in that comment, he's talking about doing a DB find and replace which is already supported, but that would probably be a bit messy and error prone. If WP-CLI had first class support for this type of operation that might go along way to solving the problem.

[swissspidy]

Something else that might be worth considering here is updating non-dynamic blocks when the block definition is modified.

As soon as that information is available in PHP, sure.

The problem here - as with block transforms available in PHP - is that this will be something all developers have to opt in first. Which means it can take a while until this will be truly helpful.

[swissspidy]

Some updates regarding server-side awareness of blocks:

WordPress/gutenberg#2751
WordPress/gutenberg#13693

[schlessera]

There's more and more work being done on improving the server-side awareness of blocks, so I'm approving the general idea of adding a wp block command here.
It needs to be fleshed out, of course, but we could already start with basic commands that hook into what we got for now. We might want to keep it as a non-bundled command while we're figuring out the interface.

[johnbillion]

Further updates:

• Add block types REST API. WordPress/gutenberg#21065
• REST API: Expose blocks registered on the server WordPress/wordpress-develop#317
• https://core.trac.wordpress.org/ticket/50263

[BrianHenryIE]

I would like to be able to create a page and add a block during the create script for wp-env. I.e. declaratively set up the pages which will be used by my E2E tests.

Currently I have a WooCommerce Blocks-Checkout post_content saved in a txt file which I then import. The single Checkout block comprises of ~22 blocks. (looks like that's how WooCommerce also do it)

Saving the existing one isn't too difficult:

wp post get $(wp post list --post_type=page --title="Blocks Checkout" --format=ids) --field=post_content > blocks_checkout-post_content.txt

And I insert it with:

wp post create --post_type=page --post_title="Blocks Checkout" --post_status=publish ./path/to/blocks-checkout-post-content.txt

But it would be neater to do something like:

wp block add $POST_ID wp:woocommerce/checkout
// or
wp block add $(wp post create --post_type=page --post_title="Blocks Checkout" --post_status=publish --porcelain) wp:woocommerce/checkout

[swissspidy]

Reusable blocks (wp_block post type) are now named patterns. They can probably already be interacted with using wp post --post_type=wp_block, but nonetheless could benefit from some more block awareness (e.g. the blocks included in the pattern, block version, etc.)

Nowadays widgets can also be blocks. I don't know how well that works with https://github.com/wp-cli/widget-command... Probably not at all? So there might be some room for improvement there as well.

Related to that, just sharing https://github.com/spacedmonkey/wp-rest-blocks here as it might be useful.

Also, what about the site editor, wp_template posts, etc.?

At the very least, if things like that can be used already with existing commands, we should provide some good examples in the documentation.

Oh, and wp theme should indicate whether a theme is a block theme or not. Maybe get info from theme.json too?