Working with InnerBlocks in BlockTypes

• goldhat

• October 30, 2020 at 4:07 am

Here is the scenario, you register an ACF BlockType and you provide the <InnerBlocks /> component in the preview so that users can drop blocks inside your custom block. But instead of just letting these blocks render themselves as blocks usually do (each being somewhat self-directed at rendering), instead you want the parent block to have some control over rendering the child blocks, and you want the child blocks to be context-aware that they sit inside a parent block.

More specifically we have a block type in our plugin ACF Engine which integrates block type building through a UX, which is an AcfRepeaterGallery. The idea is the user drops in the AcfRepeaterGallery block, it has a field group to specify a repeater field. That repeater field will have subfields such as “image” and “caption”. The block type supports inner blocks so the user can drop in an AcfImage block (and set it to use the repeater subfield image). Then they drop in an AcfText block to display the caption. What then happens is we use the Inner Blocks only as a “template” for the loop over the subfields of the repeater field. We do not really want to render them. We just want to run parse_blocks() and render_block() on them after iterating over the rows in the repeater field. The end result is we construct slides from each row in the repeater, and those slides have the content specified by Inner Blocks.

We already have this working, but the way it works is that it relies heavily on using PHP globals. Because the callbacks for ACF Blocks does not give us the inner blocks in their original form. Instead it gives us the $content variable as parsed html. We need the original blocks, because we want to manually run render_block after dynamically switching the content.

How we do this currently works on the front-end, because we don’t print out <InnerBlocks /> (that is only needed in the Gutenberg editor). So what happens is when when the parent block (AcfRepeaterGallery) renders, it loads the $post, runs parse_blocks() on the $post->post_content, then loops over the blocks, pairing them to the InnerBlock templates the user chose, and renders those inner blocks in a loop.

What would help us do this type of “dynamic loop” without having to set variables in PHP globals, is to have for instance in the callback a new argument $inner_blocks. Or perhaps easier to integrate, under the first argument $block which already has [‘data’] and other properties in the array… add $block[‘data’][‘inner_blocks’]. And to clarify this would not be “parsed blocks”, what we need is the original “unparsed blocks contained in inner blocks”.

I am not clear on exactly how (in react/js) this data is available, but threads on stackoverflow and elsewhere including gutenberg discussions on github suggest that “context-awareness” for inner blocks and “parsing inner blocks from parent block” are topics being worked out right now.

For instance this thread has some suggestions in the answers regarding “is there a way to know if a current block is inside inner blocks” https://wordpress.stackexchange.com/questions/317003/gutenberg-is-there-a-way-to-know-if-current-block-is-inside-innerblocks

The second request would be support for the inner block to have some awareness of it’s parents and to have that available in the callback for instance an argument like $is_nested_block or $inner_block_nested. Ideally again the $block array passed to the callback would have a property that provides the transversal tree of parents to the block such as $block[‘data’][‘parents’] = [parent_blocks].