This is about WordPress and the static site generator Gatsby, not the Gutenberg and Gatsby you might know. I’m not sure where that post would go.
Anyway. Parsing Gutenberg blocks in Gatsby turns out to be much more straightforward than I thought it would be. Not that it’s completely straightforward, but I didn’t find it horrible. I’ve done it the cheap and cheerful way, porting over the circle text and code highlighting blocks from mjj-why as components and styles and doing the minimum needed to get the attributes out of the raw content.
I’m currently getting the raw (as opposed to rendered) content for the posts from WP GraphQL – this is the content with all the block editor html comments which include attributes and everything necessary to parse the block.
Those attributes in the comment, that stringified JSON object, is what I need to render my server side rendered blocks. I also need the block name, it helps to know which block to render. Happily, there’s a package for this! The block serialization default parser.
Running the raw content through that gives me a list of blocks (supposedly an array but coding-wise it dies if I don’t treat it as an object) which I can iterate over. Each block contains:
- the block name
- the saved attributes
- any inner blocks
- the inner html
For core blocks, all I need is the inner html and I’m good. For things which aren’t a block, the html I need is also in the inner html but with a null
block name.
My blocks still need to be rendered. But first a quick aside about why the mjj-why blocks are server-side rendered rather than saved in the content. The short *and* the long answer is that I mess around with them too much to have something I can’t tweak on the fly. I know there are ways of deprecating old save functions but it would be embarrassing how big those functions would get. So I server-side render. There usually is a jsx component floating around there somewhere for use by the block too, I would much rather do it all in js than have to piss about replicating what I want in php. Having to do it in php is a downside to this decision for me.
To parse my blocks and get the html I need from the others, I’m using a utility function through which I run the content. (In this function createLocalLinks
swaps the links to the WP install to links to its current home on Netlify.)