Using Global Styles and Settings (theme.json) for client projects

To build maintainable websites for our clients, we need to a set of predefined styles and settings to be used across an entire website.

In Classic themes, this was CSS. Page builders use presets, an abbreviation for predefined settings.

In the WordPress block editor world, we talk about Global Settings and Styles.

In this article we’ll look at the following:

What are Global Settings?

Global Settings are a unique approach to solving these challenges:

  1. How can users have access to the customization options they want without being overwhelmed by too many options?
  2. How can developers configure the WordPress block editor interface to fit the requirements of each project?

The result is a system made up of different components, that all work together to solve these challenges:

  1. All blocks, whether part of Core, a plugin, or custom-built, can declare support for customization settings. This is done in the block.json file.
  2. The active theme decides which of these settings are available. This is done through the theme.json file.
  3. The block editors (Site Editor and Post Editor) adapt the interface to display only each block’s supported and enabled settings.

So, unlike with a page builder, the available settings for each block depend on the active theme.

The Paragraph block settings in the 2024 theme.
The Paragraph settings with the Twenty Twenty-Four theme.
The Paragraph settings with the Barebones Starter Theme.

This might confuse freelancers and agencies that have experience with page builders.

The key differences are this:

  1. You can choose whatever builder you like. But you are not supposed to pick and choose what you like about it. By using a page builder, you are buying into its vision of building.
  2. The page builder is the central piece of the building system. The theme is nothing but a canvas on which you paint.

WordPress, however, considers the theme central to the customizing experience. And in that sense, classic and block themes are very much alike.

What are Global Styles?

Global Styles are a system of styling blocks that solves these challenges:

  1. How can you manage block styles from one central place and apply them across the entire site?
  2. How can you create styles for individual blocks while keeping the design consistent?

To achieve this, the Global Styles integrate tightly with Global Settings.

The Styles panel in the Site Editor is where you create styles that apply to all elements across all pages.

The Site Editor showing the Twenty Twenty-Four theme with the Styles panel open.

This tool offers you the same settings as individual blocks. Meaning all color, typography, and spacing settings are there for you to choose from.

But the integration goes beyond just the interface. Let’s look at this sample font size style for a heading level 1, as it appears in theme.json:

"h1": {
"typography": {
"fontSize": "var(--wp--preset--font-size--xx-large)"
}
}

One might expect to see a value here, like 2rem. But instead we see a CSS variable: var(--wp--preset--font-size--xx-large).

WordPress generates these CSS variables for all style options defined in settings. And when you choose from one of these predefined options, the style references the CSS class.

This applies both to Global Styles, which are stored in theme.json, and per block instance styles.

For example if you change the font size of a paragraph, this is the generated markup:

<p class="has-xx-large-font-size">I'm XXL!</p>

This tight coupling of presets and styles allows you to change a website’s visual presentation with the same speed and ease of use as CSS.

And whenever you need to write additional CSS, you can also reference these classes. They are available both in the editors in the backend and frontend, allowing you to write the same CSS for both views.

What’s the role of theme.json?

The introduction of the Site Editor was done in two phases. WordPress 5.8 first introduced the settings and style system, but without any interface. That was only added in 5.9.

This meant that for months, you had to manually edit JSON files during theme development. There was just no other way to create settings and styles.

So, instead of referring to Global Settings and Styles, most tutorials just referenced theme.json. The two terms became almost synonymous.

But there’s a major difference between the two:

  • The Global Settings and Styles represent your design and user experience choices as a theme author.
  • The theme.json file represents these in a machine-readable format.

And with the WordPress interface getting better, and the developer tooling improving, this distinction has become clear.

For now, settings like font sizes and color palettes still need to be added manually to the theme.json file. But others, like font families, now can be managed entirely through the Site Editor.

With a plugin like Create Block Theme, the values for theme.json can be exported from the Site Editor.

This way, you can benefit from a faster development process using a visual builder. However, you can still track the entire theme in source control and deploy it like any other theme file.

What are the two types of settings?

We can divide settings into two different categories:

  1. Enabling and disabling controls.
  2. Configuring the options exposed by style controls.

A lot of thought is given to the disabling of controls.

There are two cases here:

  1. Controls which you don’t want, like the font size picker.
  2. Controls that you don’t need, like drop cap.
If enabled, users can set whatever font size they want for a block.
Drop cap is present by default, but it’s a niche feature which you likely don’t need.

To some, this seems extreme. Especially those who look to popular free and premium themes as inspiration.

But remember that a theme meant to be used on thousands of sites needs to be flexible. If a user wants to pick colors, font sizes, font families, etc., that don’t fit the design at all, that’s his freedom.

You, however, are developing a theme for a single site that needs to present a consistent design. Not only now but also in the future. So you can’t allow users to pick random design elements.

This is not to mention that a well-designed theme also makes it easier for users to create content and update sites. Don’t just throw stock WordPress at your client and expect him to figure it all out on his own.

You need to provide guard rails, which are:

  1. Color presets: Color and gradient palettes.
  2. Typography presets: Font families and font sizes.
  3. Spacing presets: Predefined margin, padding values, and the correct default block spacing value.

These elements allow you to keep a consistent design system across all pages.

But keep in mind that you also might need to enable controls.

The link color selector, for example, is not displayed in default WordPress. For this setting to appear, you need to explicitly enable it.

WordPress hides the Link color control by default.
WordPress hides the Link color control by default.
By using theme.json you can enable the Link control.
By using theme.json you can enable the Link control.

How to start every project the right way

Not selecting the correct settings right from the start is the biggest mistake freelancers and agencies make.

That is both the case for those who create a theme from scratch, and those that start with an existing theme.

By now, you are aware that the best approach is to configure Global Settings and then build Global Styles from them.

But even I have failed at this in the past. I forgot to implement a key aspect of developing quality websites: clear and repeatable processes.

So, I implemented a checklist I now go through on every project setup. It’s a Google Sheet so that I can make a copy for each project.

The checklist covers directories, block types, block styles, and block settings. It contains information on why to remove a feature and links to all the code snippets needed to remove or configure these features.

I find this more flexible than a starter theme. Because not all the items on the list make sense for all projects. Because it is a Google Sheet, I can fill in when I diverge from the default. I keep this sheet stored for future reference, so that I have a trace on the decisions I took at the project start.

You can find this checklist and all associated resources inside of my Block Theme Academy course.

Fränk Klein Avatar