The new WordPress block editor, more affectionately known as Gutenberg – is nothing short of amazing. The amount of effort that has gone into ongoing development prior to its launch in December of 2018 – as well as the efforts that have gone into it since then – are astounding.

More and more of our work at Zao these days includes customization of Gutenberg for our clients – especially clients who deal with a lot of content every day.

One of our more recent clients had a very specific need that stretched Gutenberg’s capacity – but thankfully, the block editor is designed to be stretched.

The content and editorial team wanted a special term list from a custom taxonomy to be displayed automatically, within the block content. The catch? They didn’t want to have to manually add it as its own block, and it wasn’t a simple task of adding it to a template file, as they wanted it to always be shown after the last paragraph (or “paragraph-like”) block – allowing for custom blocks to be rendered after this term list.

In the past, we would have had to consider shortcodes, telling the client “Sorry!”, or some really bizarre regex/DOMDocument hacking of the the_content filter. Thankfully, not with Gutenberg ?

WordPress ships with a block parsing class, WP_Block_Parser. This class is passed through a filter called block_parser_class, which allows for very easy extension of this class. Let me show you how, in less than 100 lines of code, we were able to accomplish the task outlined above.

In the gist above, you can see that the first 20 lines are essentially us just overriding the core block parser with our own sub-class. The parse function is the primary function that WordPress uses when parsing blocks, so we need to override that to ensure we do what we are intending to do. Finally, the real work happens in parse_output. This is where we get our article tags, iterate through our blocks, and append the tags to appropriate block. You’ll note an important data structure reality here – each block has a representation of both innerContent and innerHTML. Replacing both is important here, and noting that innerHTML is an HTML string, while innerContent is an array of key-value pairs, where the value is generally the identical string, is the key to making this example work as intended.

As you can tell, the block parser class is a foundational part of how blocks are rendered with Gutenberg, and using it judiciously can be a really powerful way to achieve incredibly helpful editorial workflows.