Add block-related post commands #556
Conversation
Summary of ChangesHello @schlessera, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request significantly expands WP-CLI's functionality by introducing a comprehensive suite of commands for interacting with Gutenberg blocks in post content. These new tools empower developers and administrators to programmatically inspect, modify, and manage block-based content, streamlining tasks such as content migration, debugging, and automated content transformations. The additions provide granular control over individual blocks, their attributes, and their placement within posts. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
schlessera
added
command:post
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a comprehensive and powerful set of commands for managing post blocks via WP-CLI. The code is well-structured, and the feature tests provide excellent coverage. I've identified a few issues, primarily related to edge cases and consistency in how block indices are handled across different commands. Specifically, the import command fails on empty block arrays, and the remove command's index handling is inconsistent with other commands and misses some error validation required by the tests. Addressing these will improve the robustness and predictability of the new commands. I've also included a minor suggestion for composer.json to improve maintainability.
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
|
I like the idea of #555 has a some other things that we should also cover here:
How does this work when block attributes are actually mapped to HTML attributes? We should leverage https://make.wordpress.org/core/2025/11/19/introducing-the-streaming-block-parser-in-wordpress-6-9/ if available |
Codecov Report❌ Patch coverage is 📢 Thoughts on this report? Let us know! |
|
Let's add a ignore:
- "src/Compat" |
I'm adding an implementation for this now that will work in the following way:
/**
* Filters a block after attribute updates to sync HTML with attributes.
*
* Allows custom handlers to update block HTML when attributes change.
*
* @param array $block The block structure with updated attrs.
* @param array $new_attrs The newly applied attributes.
* @param string $block_name The block type name (e.g., 'core/button').
*/
return apply_filters( 'wp_cli_post_block_update_html', $block, $new_attrs, $block_name );You can then include custom logic with WP-CLI when you are running an update operation: wp --require=./my-block-handlers.php post block update 123 0 --attrs='{"url":"https://new.url"}'// In a file loaded via: wp --require=./my-handlers.php post block update
add_filter( 'wp_cli_post_block_update_html', function( $block, $new_attrs,
$block_name ) {
if ( 'core/button' === $block_name && isset( $new_attrs['url'] ) ) {
$block['innerHTML'] = preg_replace(
'/href="[^"]*"/',
'href="' . esc_url( $new_attrs['url'] ) . '"',
$block['innerHTML']
);
$block['innerContent'] = [ $block['innerHTML'] ];
}
return $block;
}, 10, 3 );What's more, we can then include a few default handlers as shipped filters for this for the most common use cases: // Built-in handlers registered as filters
add_filter( 'wp_cli_post_block_update_html', [ $this, 'sync_heading_level' ], 10, 3 );
add_filter( 'wp_cli_post_block_update_html', [ $this, 'sync_list_type' ], 10, 3 );Also, this then allows the ecosystem to pick this up. Handlers like that can be in a theme's |
|
Soubds good. I suppose that's the best we can do until core provides a solution for this. |
Add block-related post commands
This PR adds comprehensive block manipulation capabilities to WP-CLI through a new
post blockcommand group and two new wp post commands.New Commands
post block <subcommand>- A new command group for managing blocks within post content:get- Retrieve a single block by indexlist- List all blocks in a post with filtering optionsparse- Parse and output the full block structurerender- Render blocks to HTMLinsert- Insert a new block at a specific positionupdate- Update block attributes or contentremove- Remove a block by indexreplace- Replace a block with a different block typemove- Move a block to a different positionclone- Clone a block to the same or different postextract- Extract blocks to a separate fileimport- Import blocks from a fileexport- Export blocks to JSON/YAMLcount- Count blocks by typepost has-blocks- Check if a post contains any blockspost has-block <block-name>- Check if a post contains a specific block typeUse Cases