What are the best practices for child theming block themes?


Hi,

last week I shared a video about how to choose the best starter theme for a client project.

One option is to start with an existing block theme (like Rockbase), and then create a child theme to implement your own customizations.

And I got a couple of emails from readers that were running into challenges when using block child themes.

So this week I want to do a deep dive into the topic of block child themes.

Why would you want to use a child theme?

With a block theme, you could just use the Site Editor, and customize the theme that way.

Using a child theme offers additional benefits though:

  1. Prevents your customizations from getting lost by error.
  2. Tracking of customizations through source control.
  3. Additional customization options only possible through code.

A child theme, whether block or classic, can override or extend parts of the parent theme.

Let's look at what this means for the different theme components.

Templates and template parts

Much like with classic themes, you can replace templates and template parts with your own versions in a child theme.

This means that if the parent theme updates a template or part, those changes will not impact the versions stored in the child theme.

You cannot remove template or parts from a parent theme. And if the parent theme adds new templates or parts, those will show up in your child theme.

Patterns

You can replace patterns in the same way as you do with templates or parts. And of course you can add new ones.

But you can also remove patterns but only theme patterns. You cannot control unsynched or synched patterns stored in the database.

One thing to be mindful of is that themes might include patterns in a programmatic way through the Pattern block.

If you look at the Ollie theme, this is the content of part/footer.html:

<!-- wp:pattern {"slug":"footer"} /-->

So if you were to unregister the footer pattern, the footer template part would be empty.

Therefore there are two options here:

  1. You can replace the pattern reference with the blocks from the pattern. And then you can unregister it.
  2. You can copy the pattern to your own theme, and then add Inserter: false to the pattern header. This keeps the pattern registered, but hidden from the user.

How to delete a pattern

Before unregistering a pattern, I recommend that you search for all templates and template parts stored on the hard disk and inside the database for the pattern slug.

Once that is done, you can use the following snippet:

<?php
function wpdc_remove_core_patterns() {
  $block_patterns = [
    'theme-whatever/pattern-1',
    'theme-whatever/pattern-2',
  ];

  foreach ( $block_patterns as $block_pattern ) {
    unregister_block_pattern( $block_pattern );
  }
}
add_action( 'init', 'wpdc_remove_core_patterns', 11 );

It’s important to use 11 or any other priority needed to ensure that this callback runs after the theme has registered all patterns.

This approach uses a denylist (or blacklist) approach. Which means that if the parent theme adds new patterns, those will show up in your child theme.

To work avoid this, you can use a allowlist (or whitelist) approach. Here you select the theme patterns that you want to keep, and all the rest is removed.

This code snippet is more complex, but if you are enrolled in the Block Theme Academy, you can find the solution in this lesson.

Theme.json Settings and Styles

Working with theme.json in a child theme can be a bit confusing. That is because WordPress takes the parent and child theme.json file contents, transforms them arrays, and then merges them.

So the rules are those of an array merge in PHP. Which can lead to not so easy to understand side effects:

  1. If you override key-value pairs, the child theme value overrides the parent theme value.
  2. If you override an object, the parent and child values are mixed.
  3. If you override an array, the child value overrides the parent value.

Here are examples for each:

  1. If you set settings.color.custom to false, the child theme will disable the custom color selector.
  2. If you add a new custom page template to a child theme, both the parent and child templates will show.
  3. If you add a new color palette in a child theme, this will override the parent color palette.

When it comes to styles, those are objects and key value pairs, the child styles will override or extend the parent styles.

Preventing new block settings to appear on WordPress or theme updates

WordPress might add new block settings in future releases, and you might not want these to show up in your child theme.

To avoid this, I recommend setting appearanceTools to false. Because this acts as a signal to WordPress that you want to have all possible block settings present.

Fair warning that if the parent the has set appearanceTools to true, and you set it to false, then various block settings might disappear. So always double check, and selectively enable the settings you want.

To avoid the parent theme from adding new settings, make sure to set every unwanted setting to false. You can refer to the Barebones Starter theme inside of the Block Theme Academy for a list of those properties.

functions.php: Block styles, block variations, stylesheets

A block theme is still a theme. So every capability that you are used to from a classic theme is still available.

When it comes to block themes, this means that all the features that use PHP functions to be enabled can be disabled.

Happy theming!

Those were all the questions I got. But if you are still unsure about an aspect of block child themes, just hit reply.

Cheers,
Fränk

P.S. I'm offering limited time Purchase Power Parity deals for my Block Theme Academy course with discounts from 10% to 60%.

Fränk Klein from WP Development Courses

Every Sunday, I send out tips, strategies, and case studies designed to help agencies and freelancers succeed with modern WordPress. My goal is to go off the beaten path, and focus on sharing lessons learned from what I know best: building websites for clients. 100% free and 100% useful.

Read more from Fränk Klein from WP Development Courses

Hi Reader, This week, I stumbled upon this post on X: I was prepared to scroll past, as it just seemed to be yet another attempt at bashing modern WordPress. But then I saw this follow up: So, really, it's not about WordPress; it's about the customers of this particular plugin. But I found this fascinating because it gave me insight into the thinking of a plugin author. I've wondered for a long time why plugin authors are not more proactive with adding proper block editor support to their...

Hi Reader, summer time in Europe means holiday season. And that means lots of time spent traveling. So why not benefit from all that time you need to sit in a car, bus, train or plane, and learn something? Which is why I'm sharing four podcast episodes I recently listened to, and enjoyed a lot. A Deep Dive into Block Bindings, APIs, and the LSX Tour Operator Plugin with Ash Shaw In this episode of Woo DevChat, hosts Zach Stepek and Carl Alexander chat with Ash Shaw from Lightspeed about the...

Hi Reader, what you are reading now took me a long time to write. In fact I started over three times. The question I'm trying to answer is simple: What's it like to be a WordPress developer in 2024? And by extension of course trying to deduct the future from that. The challenge here is that I want to: Warn about the dangers for your career without wanting to create panic. Encourage you to grow your skills without sounding too negative about your current situation. It's not about Full-Site...