If you haven’t already, check out part 1 of this series – https://brentjett.design/2018/12/20/a-fresh-look-at-customization-part-1/

In the first post of this series I showed some examples of a new site customization space that I think would improve several areas of WordPress. In subsequent posts I’m looking at different technical aspects of theming to make those ideas either possible, or more manageable. I strongly believe that themes and customization are two sides of the same coin and during this Gutenberg Phase 2 exploration time, both should be looked at together.

So we have blocks now. Gutenberg’s atomic unit is the block and the post content makes great use of it. The question of where blocks go next is certainly being thought about and this question directly impacts themes. How will themes expose new editable regions? Where do these initial block layouts (because nothing should ever look empty) come from? Matt alluded to these ideas in his State of the Word keynote in December. As the concept of blocks has the potential to subsume previous structures like widgets and nav menus, there’s a companion idea that has equal potential. Block Areas.

A block area is a portion of the overall page layout where blocks exist. This is both simple and extremely powerful at the same time. We need a way for themes to designate regions of itself that can be manipulated with blocks if the user chooses. Themes also need to be able to specify what the initial block structure of those areas is. Let’s look at an example.

The image above highlights a nav menu area that could be edited with blocks. It isn’t hard to see how a block area might replace the traditional Nav Menu Location. Themes simply specify a block area called “Main Nav” for example, and optionally include a block layout for the initial menu structure. The code for adding a block area might look something like this:

<?php
do_block_area( 'main-nav', [
  'label' => __('Main Nav', 'example'),
  'scope' => 'theme',
  'layout' => [...]
]);

This declaration tells the system where the block area is placed, what to call it, where to save its data when edited (we’ll talk about scope in a bit) and what its initial state should be (a block layout).

Block areas could be useful for more than navigation though. Remember that good ole’ content loop we’ve been writing forever? Have you ever tried explaining the post loop to a new theme author that has never programmed before?

<?php
if (have_posts()) :
   while (have_posts()) :
      the_post();
      the_content();
   endwhile;
endif;

What if instead of that, we just wrote this:

do_block_area('content');

Wouldn’t learning theming be much easier? And block areas don’t need to be any less capable than explicit code. What if we exposed a way to give these areas a “no content” layout, for example and let the system decide when to show what? There are many many ways the core system could make this experience simpler.

Scopes and Capabilities

Block areas can be used for quite a few different things, but one important aspect to define is scope. A block area that outputs the post content is different on every single post, and any changes made to it’s layout should be saved to the post_content field in the database. Conversely a nav menu might exist at a global level, the same on every page and thus should be scoped to the ‘theme’ or ‘site’. Telling a block area how to save itself when changes are made through UI is essential.

Here’s another example. Let’s say your page layouts have a “hero” area. This hero area might show and hide based on whether the author adds a featured image to the page/post. But why make this separate from the content layout at all? Well, what if the technical details of how the hero works weren’t up to the author user? What if the admin wanted to lock that capability away? Block areas offer an intuitive user role barrier between different sections of a layout. This way any content author can add a featured image or not, but an editor or admin has the ability to edit the block layout of the hero itself, and do something totally different in that space when they desire. The content author never needs access to that particular area. If an admin edited a post, he’d see the full set of blocks defining the hero and can change them as desired. Defining this block area might look something like this:

do_block_area( 'hero', [
  'label' => 'Hero',
  'scope' => 'post',
  'capability' => 'edit_others_pages',
  'layout' => [...],
]);

There are so many different things block areas could be useful for:

• Header & Footer Parts
• Nav Menus
• Widget Areas
• Heroes and Pre-Footers
• Modals and Interstitials
• Post Archive Layout
• Login Page Layout
• 404 & Maintenance Layout

Block areas offer a simple mechanism to make the theming APIs more concise, easier to learn, and yet more powerful at the same time. New customization experiences could be built on top of an API like this and a new generation of themes could make WordPress even simpler to approach and use.

In part 3 of this series I jump into how to set a more solid foundation for themes. https://brentjett.design/2019/01/01/a-solid-theme-foundation-customization-part-3/

If you’d like to see all the mockups I’ve done for this series, I’m throwing them in Dropmark for now and will be adding some new ones along the way. https://brentjett.dropmark.com/617450