Filter Blocks Types that are Exposed in Gutenberg for a Predictable Headless WordPress API
There are dozens of options available in Gutenberg for building a post, the amount of data coming through the Headless WordPress API can make it hard to manage presentation on the front end. To handle this we can filter out blocks that we won't use so that we can reasonably expect what data will be coming through the API.
In this lesson, we will limit the blocks available in the editor by adding the allowed_block_types filter.
Instructor: [0:00] In the Gutenberg Editor, we have options of lots and lots of different block. Since our aim is to receive these blocks headlessly and style them on the frontend, it's worth thinking about which of these blocks we want to keep, and which of them we want to leave behind.
[0:20] Let's head back to our functions.php file. This is found wherever your local app has installed your WordPress. For me, that's in my users directory local sites headless WordPress. We're now go into app/public/wp-content/themes. The theme, that's currently active, and we're looking at the functions.php file.
[0:44] Good practice would post some of these functions out separately. Let's do that. Let's create a new folder lib directory and let's call it headless.php. This is where we're going to keep all of our separate functions.
[0:56] What we'll do, back in functions, is we're going to require wants. I'm going to get the template directory, and I'm going to append to that lib/headless.php. We want to add a filter, and specific filter we want to add is the allowed block type.
[1:15] This needs to take a name function. I'm going to create a function called headless allowed block types. Let's create that function, function headless allowed block types. That function would hit an argument of allowed blocks, and it will return an array of the allowed blocks.
[1:36] The first thing we'll do is return an empty array, and see what happens. I can see I have no blocks present here. None have been allowed. If I go back now, I'm going to add a few blocks in. Let's add in core image as a block. Refresh this page.
[1:53] You can see I've got one block which is core image. Let's add some paragraphs to build the other paragraph. Let's add, headings, and then add list. You can see paragraph. It's the default block which I land on, won't add anymore blocks.
[2:09] I can use the menu and I've got these four to choose from. Having a more limited blocks at makes it easier to style on the frontend. We can more reasonably expect what we're going to receive, and we can process those in the way that we want to in our frontend.
Super helpful, Simeon! Thanks for sharing. I'll think about how best to communicate that.
Thanks for the course, really interesting! Do you have a list or can suggest what types of blocks filter for an average blogging experience?
Hey!
Glad you've enjoyed the course so far.
It really depends on what you want. It's worth having a look on blogging platforms like Medium, Hashnode, etc. and have a think about what you'd like on your platform.
For me it would be something like:
- Headers (maybe three levels)
- Paragraph
- Divider
- List
- Image
- Code block
Yours might be different, though.
I am sure using child themes is outside the scope of this course, but you should at least mention the risks of editing a theme directly.
When using a theme developed by someone else they will occasionally have updates posted by the developers. If you take the update, your changes could be overridden. So it's always a good idea to make a child theme before starting to make changes. Then your changes can be protected for future updates to the parent theme.