All block themes are built on the same foundations. So, unlike with a classic theme, it’s much easier not to start from scratch.

This makes them a great option for WordPress developers and designers building custom websites. You can use an existing theme and extend and adapt it to the needs of your clients.

Assuming, of course, that you choose the right theme to start with.

But once you have selected your theme, should you take complete control by forking it or playing it safe with a child theme?

In this article, we’ll examine how to decide which of these two paths is best for your next build.

Child themes: past and present

WordPress introduced child themes to allow developers to customize a theme’s behavior and functionality without modifying the original theme files. This is because customizations made directly in the theme files risk being overwritten when the theme is updated.

With block themes, this risk is no longer present. The Site Editor stores any customizations in the database, so they are safe from any negative side effects caused by theme updates.

But this does not mean that child themes are now obsolete. This is because of two reasons:

1. You don’t want to rely purely on the database as a professional. Instead, you want to export customizations and store them as theme files. You can then track in source control and generally have better control over the codebase.
2. The Site Editor is a powerful tool, but it doesn’t expose all the functionality that can be achieved with code. This code is best placed in a child theme.

So, we’re all in with child themes, and the case is closed? Not so fast because child themes are powerful but limited.

Starter themes: past and present

Like many of you, I used the Underscores theme (or _s) as the basis for all my themes in the past. It offered templates with great markup and efficient CSS and handled all the boilerplate code needed in a classic theme.

But that is now a thing of the past. You can use the Site Editor to create templates in minutes. You only need bits and pieces of CSS, and the boilerplate is handled for you.

This has changed the way that we select starter themes. Now, we can start further in the process and choose a theme with a design that is close to what we want to achieve.

The word “close” is essential. These themes can lead you further in the right direction, but you still need to adapt the design.

In this scenario, you would “fork” the theme, which means you produce a separate version of the theme that evolves differently from the original.

This way, you can get the desired head start and the freedom to customize every aspect.

Child theme or fork: which to choose?

My rule is this: unless you already know that you’ll need a very different design and functionality, default to a child theme.

Then, once you reach the limits of this customization approach, you can always fork.

This is because child theming allows you to get updates on the parent theme and access to support in the case of a premium (paid) parent theme.

That said, when does child theming stop making sense? Let’s examine the design and technical reasons for forking a theme.

Design limitations of child theme customizations

When you choose a block theme, you select a design system. This system is made up of three foundations:

• The typography, so the font families and font sizes.
• The colors, meaning the color and gradient palettes.
• The dimensions or spacing, which includes the spacing and margin presets, as well as block spacing.

As with any system, you can change parts of it—but only to a certain point, at which point the changes cause the system to break.

So, how far can you bend the design rules before they break?

Typography

You can change font families, but you need to choose similar fonts. The shape of the characters impacts the ideal line length.

This is a crucial piece of the puzzle. Too many or too few words on a line can make content unreadable.

Let’s look at these two typography styles from the Twenty Twenty-Five theme:

Of course, you can then adapt the line length, which in a block theme is the content size. But this will have a knock-on effect that is likely to break the entire design.

Another consideration is font sizes. You can add font sizes, but it’s hard to remove existing font sizes or even change them. This is again because the size of characters impacts spacing. A large font without sufficient whitespace looks off.

(On a side note, this is also why I don’t believe in the “one theme with a gazillion interchangeable styles idea”).

Colors

When it comes to colors, the situation is similar to that of typography. You can replace colors if you keep the number and lightness the same.

Of course, you can add colors and choose where to add them to your designs. But removing colors is complicated and sometimes even impossible.

Spacing

The white space in a design must be proportionate to the filled space. So, the typography plays a crucial role here as well. Whenever the font family or font sizes change, the spacing also needs to change.

Of course, you can add more spacing sizes to a design, but removing them is difficult.

Technical limitations of child theme customizations

Technology, design, and user experience are closely related to a block theme. While specific adaptations are technically possible, they will or might negatively impact the user experience.

Block editor curation

This is a big one in the context of client services.

When we talk about “curation,” we mean the ability to select which features our clients can use. As you can imagine, this is tricky when using a child theme.

This is because of three reasons:

1. The theme expects features like certain blocks to be present, so removing them might break the theme.
2. Curation options like template locking are stored as block metadata in the template, template part, and pattern files. Overriding these is possible, but of course, it will prevent them from receiving updates from the parent theme.
3. Controlling available templates, parts, and patterns can become a whack-a-mole game. Future versions of the parent theme might introduce new elements, requiring you to decide whether to keep or unregister them.

Changing font size and spacing palettes

WordPress has an established convention for naming font and spacing sizes. It follows the same approach that we use to name clothing sizes.

This means that if you introduce a new size, you have to rename all sizes that are larger.

It sounds abstract, so let’s look at an example. Let’s take a simple three-size palette:

• Small: 1 rem
• Medium: 2 rem
• Large: 3 rem

And we want to add a new font size between 1 rem and 2 rem, which uses 1.5 rem. The 1.5 rem size is now the new medium: medium becomes large, and large becomes extra large.

To achieve this change, updating the font size palette is not enough. You must also rename all size usages in the Global Styles and the per-block styles to reflect the change.

Else, you will change the design of the theme, which will look unbalanced.

Changing block instance styles

You can freely update any styles handled through the Global Styles system, meaning they are stored either in the main theme.json file, or section or style variations.

But when it comes to styles added through the editor interface, this is impossible in a child theme because these instructions are added as block meta data and CSS classes.

The markup below is from the OllieWP theme. Take note of the has-* classes that reference colors from the color palette.

<!-- wp:group {"metadata":{"categories":["ollie/call-to-action"],"patternName":"ollie/call-to-action-card-with-buttons","name":"Call To Action Card With Buttons"},"style":{"spacing":{"padding":{"top":"var:preset|spacing|large","bottom":"var:preset|spacing|large","right":"var:preset|spacing|large","left":"var:preset|spacing|large"}},"border":{"radius":"5px"}},"backgroundColor":"primary","textColor":"base","layout":{"type":"constrained"}} -->
<div class="wp-block-group has-base-color has-primary-background-color has-text-color has-background" style="border-radius:5px;padding-top:var(--wp--preset--spacing--large);padding-right:var(--wp--preset--spacing--large);padding-bottom:var(--wp--preset--spacing--large);padding-left:var(--wp--preset--spacing--large)">

So, to change them, you would need to search-replace all HTML files in the theme. This would impact templates, template parts, and patterns. Any file that was changed this way would be prevented from receiving updates from the parent theme.

Conclusion

Choosing between forking and using a child theme depends on the level of control you need for your project.

A child theme offers a more straightforward path to customization with the benefit of inheriting updates, making it ideal if your customizations stay within the original theme’s design system.

However, when significant design or functionality changes are required, a forked theme provides the freedom to fully adapt every aspect without limitations, though it comes with added maintenance responsibility.

Ultimately, the decision is about balancing customization needs with the theme’s ability to evolve.

Forking gives you complete control but detaches you from parent theme updates, whereas a child theme offers continuity with the original design and codebase.

Choose the option that best supports the project’s goals and your workflow, allowing you to deliver a polished, maintainable end product.