Cancel

Justin Tadlock

Ask the Bartender: Is There a Starter for Building Block Themes?

I read some posts from “Ask the Bartender,” and I appreciate it a lot! Thanks. I have a question now. :)

I want to refine my WordPress theme development process, which is:

  1. To make a unique-creative design with Adobe XD or Figma.
  2. To convert it to static HTML using VS Code with Bootstrap.
  3. In WordPress, create custom post types with PODS.
  4. To convert the static HTML in WP templates with Timber.

Based on my experience, this process is the best for me, but I want to integrate my themes better with WP-Blocks.

So, my question is: is there some starter-theme ready to use with blocks as the main theme and later extend it with a child theme with my custom theme?

Federico

This question depends on one of two things: Do you want to build classic themes with block support or full-blown block themes? How you approach projects going forward will depend on the answer to that. It was unclear which direction you prefer from your question, so I will tackle both.

It also seems like you are more interested in child theming. For clarity, I consider “starter” themes a starting point for building standalone or custom parent themes. My guess is that you want something closer to a blank canvas parent theme that does not have an opinionated set of default styles.

As for your tools, I have almost zero experience with any of them. I suspect you can maintain a similar process by sticking to classic themes with block support. However, with block themes, you will likely want to switch over to visually designing in the upcoming site editor and exporting the templates. It would cut out a lot of the steps you usually take.

Classic With Block Support

I tend to hype WordPress theming with blocks, but let us be realistic. Most theme authors will not take that step forward when WordPress 5.9 rolls around. And, there is no reason for everyone to dive face-first into something that is not 100% on par with what you can build going the traditional route. So, classic themes are the safest bet for a while.

Starter themes or frameworks are a dime a dozen in the classic theming world. My advice is to continue using what suits you best. Adding block support is mostly a matter of some style adjustments and possibly a theme.json file.

If you want to ease yourself into integrating with blocks, start learning the global styles and settings system (i.e., theme.json). It works with any type of theme, so you do not have to transition entirely over to block theming if you are not ready. This also allows you to continue using whatever setup you are accustomed to with one additional file. It has also been a part of WordPress since 5.8, so you can use it now without relying on the Gutenberg plugin or waiting for 5.9 to launch.

Screenshot of the homepage of the Go theme by GoDaddy. It has a large hero/intro section, followed by a wide image.
GoDaddy’s Go theme.

If you really need a starting point or parent theme in the classic + blocks space, I recommend Go by GoDaddy. The block-first project gets routine updates, supports CoBlocks and WooCommerce, and has a large enough user base to keep the ecosystem around it going.

Building Block Themes

If you want to move forward and put yourself in a solid position for WordPress’s future, block theming is the way to go. Sooner or later, almost every theme author will need to build on top of it. In this context, it also makes it easy to answer your question. And, I have two options for you.

The go-to choice for many theme authors is to learn and build from the latest default WordPress theme. In this case, it is Twenty Twenty-Two. It was supposed to be ready by December 8, along with WordPress 5.9. However, the official release date is now January 25, 2022.

Homepage of Twenty Twenty-Two on the left with a large intro section and latest posts grid below. On the right, is a category archive with offset grid posts.
Twenty Twenty-Two screenshots.

While it has not officially launched yet, it is a solid starting point if you want to release a child theme in the next couple of months on top of the latest default.

The goal is for Twenty Twenty-Two to ship with alternate color palettes and fonts. However, this feature is not ready yet. In the meantime, these custom designs are available as child themes that you can tinker around with. They are just as good of a starting point as any.

However, you may be looking for something a bit more mature — as mature as anything can be for something yet to officially launch. Automattic’s Blockbase parent theme is the easy choice.

Customized dark version (child theme) of the Blockbase parent theme.
Custom Blockbase child theme.

Blockbase has a low-key design that makes it easy to overwrite via child themes. It was literally built for this purpose. The Automattic Theme Team rolled out the Videomaker child theme for it yesterday. That makes six altogether, which are available via the company’s WordPress.org profile. Not only is it a good starting point, but it has plenty of examples to learn from.

Plus, you do not need to dirty your hands with code if you do not want to. By installing and activating the accompanying Create Blockbase Theme plugin, you can build child themes directly from the site editor and export them.

Category: ,
Tags:
6

6 responses to “Ask the Bartender: Is There a Starter for Building Block Themes?”

    • theme.json can be used with both classic and block themes. It’s just used to define styles and settings, which apply to the content editor just as much as they would the site editor.

      For a theme to become a block theme, it must have either a templates/index.html or block-templates/index.html file.

      Create forum topic from comment

    • Yes you can use it in classic themes.

      It depends on how you define a block theme.
      For me, a block theme is a theme built entirely of blocks. All the markup for the webpage comes from blocks.
      Adding the theme.json will not change the markup of the theme: only the markup of the group block.

      What it does, is give the theme author a configuration file for enabling and disabling supported block controls like gradients and drop cap.

      It is a configuration file for colors, default spacing and width for the body element and for blocks.

      It generates CSS custom properties that theme authors can use for HTML elements that are not blocks, but they have to apply that CSS manually.

      Create forum topic from comment

  2. Hey everyone,

    thanks for these recommendations, bartender =)

    While we’re here at the bar, chatting about blocks and theme development, maybe I can also ask the crowd a question I’m wondering about – what’s the “Gutenberg way” for something like an events calendaras an example for a very common, in my case maybe the most common, WordPress workflow?

    Here’s my understanding:

    In the pre-block world, I’d use ACF/custom fields for posts of a custom post type “event”. The data would be saved to the “event” post-meta and displayed with a custom query on a custom page template or post-type archive.

    Now, assuming having to build this with blocks, I would, depending on the suspected amount of “events” either create a block pattern for the individual event info and then manually create a list of said block pattern on a standard page. There is only block markup, and there is no need for a post type as long as there are only a couple of events whose display order can be handled manually.

    But – this approach also means not being able to individually access a single event or rearranging the manually assembled list (save for block-parsing for individual data-points, which I suppose will be complex and out of the question performance-wise). So, if there are more than a few “events” to be displayed, even in a block world I still need a post as container of a single data unit and probably a custom post type “event” to get a queryable list.

    I’d then need to write and lock a block template to limit the block editor to a single instance of a custom “event”-block (or “event” block pattern) for each “event”-post, and I’d still have to save as post meta the values of at least those blocks I want to use for the custom query. In other words: in terms of the data structure necessary, the custom block/ block pattern / block template combination is mainly a replacement for a custom fields metabox UI like ACF.

    For the output I can then either use the standard query block or, more likely, a custom “display events” block that queries, creates and outputs the list of events (so basically, the functionality of the events page template or post type archive is moved into one of these blocks. Something similar would have been possible in the non-block world by moving the page template funtionality into a short code, but here the dynamic back end rendering is an obvious advantage.)

    How you would go about this kind of use case in the block world? Am I missing something, potentially something important?

    Thanks for any comment/ idea =)

    Create forum topic from comment

You may also like

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.