I’m a huge fan of the Gutenberg project. It’s a bit of an unpopular opinion in the community, but I love building WordPress websites with React and JSX. So naturally, I was excited to discover that the core team has been working on ways to enable Gutenberg block placement outside of the post content. This not only puts the potential final nail in the coffin for Advanced Custom Fields (ACF) in my workflow, but further re-enforces the separation of skin vs structure relationship that seems to be developing between themes and gutenberg block plugins.
The “Block Areas” plugin
It doesn’t seem clear at this time when this feature is coming to core, and the syntax is far from set in stone. Because of that, I’m exploring this idea through a free plugin aptly titled “Block Areas”. The plugin creates a simple experience in the dashboard for creating block areas, and provides a very succinct php script for defining the placement positions inside of a WordPress theme.
Install the plugin through the WordPress dashboard under Plugins > Add New, or download the plugin files here. Once you have it installed, inside the dashboard, navigate to Appearance > Block Areas.
There should be two default items: “Header” and “Footer”. I don’t suggest trying to serve entire components of a theme using blocks like this, but I think it does make sense to define areas for individual child elements within a parent component.
For this example, I’ll enable a block area for the main branded logo of a site. Also, my logo is an svg, so I’ll use a core html block to render it as an inline element.
If you want to use a raster image, you can use the standard “image” block in place of the “html” block I’ll be using.
Inspecting the theme
Before we create the block area, let’s first take a look at the theme files and figure out where the block area should live. Opening up the header.php file, I have a pattern that currently works with ACF’s options page functionality. I typically use this to store global options a theme would need that I also want a marketer or end user to be able to easily modify (without contacting me).
Elements like the header logo, social icons and urls, phone numbers and addresses, are all much easier to manage if the values are organized in one place (and aren’t hard coded into the theme). I’ll remove a lot of the existing code that isn’t going to be relevant anymore, and leave an empty space for the block area’s script.
Creating the block area
Flipping back to the WordPress dashboard, navigate to the block areas view (Appearance > Block Areas), and remove the default “Header” and “Footer” areas. Just like any other post type in WordPress, look for the “Add New” button at the top of the screen, and create a new block area titled “Header Logo”. Inside the editor, add an html block and copy / paste in the logo’s svg code.
Modifying the theme
The script format provided by the plugin is short and sweet (just as it should be):
<?php block_areas()->render( $slug ); ?>.
$slug (all lower-case and spaces replaced with hyphens) is the name of the block area you’ve created. For this example, the
$slug is “header-logo” resulting in:
<?php block_areas()->render( “header-logo” ); ?>.
Revisiting the theme’s header.php file, you might’ve noticed the conditional logic that determines the logo’s parent element type. The idea is to render a
<div> if the user is already on the front page, and an anchor
<a> for every other page.
This just keeps the logo from linking to a page that the user is already on, and creates a quick and intuitive way for the user to get back to the front page if they’re anywhere else on the site. Because both elements render with the same class, styles are only defined once.
Because of this, however, the block area needs to be placed in both positions, like so:
Now, we should be able to refresh our front-end and see the logo rendering appropriately:
It’s a basic first step, but you can expand the idea to many other places within your theme’s template files, opening them up to more comprehensive customization without the necessity of a developer.
Hopefully we’ll soon see what Automattic has in store for the core implementation. I’m always looking for ways to reduce my dependency on plugins and continually pursue native approaches for all my development requirements.