Justin Tadlock
It was a busy week, and I almost missed one of my most-wanted components landing in Gutenberg 12.5 RC 1. The global style variations feature quietly snuck its way in as everyone else was getting acquainted with WordPress 5.9. The official release of version 12.5 is not expected until next week, but that did not stop me from giving it a test run.
What are global style variations? I will assume you missed my post praising the idea last November.
In essence, a global style variation is user-selectable skin for their currently-active theme. For example, a theme with a default blue color scheme might package green, purple, or red alternatives. The idea is not limited to colors. Anything possible to change through the global styles system is at play, such as typography, layout, borders, and more.
From a theme developer’s viewpoint, they would drop custom stylename.json files under a /styles folder in their themes. Gutenberg and, eventually, WordPress will automatically register these with the system.
The feature was intended to ship with WordPress 5.9, and the Twenty Twenty-Two theme was supposed to be its unveiling. However, it was not complete and is now on the slate for WordPress 6.0.
It did not take me long to build a couple of extra variations for my custom theme. I could change my color scheme and fonts at the click of a button.
If this feels eerily similar to another feature that already exists in WordPress, you are not alone in that feeling. Child theming was born out of this same idea of offering design variations for the same theme.
Child themes were not always possible in WordPress. They grew in popularity via a grassroots effort and a third-party plugin, and their first uses were to supply a different design via the standard style.css file. Users could keep everything about their site intact and add a new coat of paint whenever they wanted.
During the late 2000s, there was a stretch where the child theme industry was booming. The Sandbox theme was among the first to use the feature, and others like Thematic continued pushing the idea forward. Genesis became one of the most well-known to employ child themes over time.
However, child theming became a beast of its own. It steered away from that initial idea of skinning a website into creating full-blown themes as big as — sometimes bigger than — their parents.
Global style variations take us back to that initial foundation. It returns us to something more akin to CSS Zen Garden’s beauty of designing with CSS, one of the foundational promises of child theming.
There is one difference. Variations are housed in a JSON file rather than style.css. The former is a standards-based configuration file that lets users further customize their design via the site editor.
Child themes will still have their place in the world of WordPress. There are times when developers and DIY end-users will need to customize beyond what is possible via the site editor. However, global style variations will offer an enticing alternative in many cases.
It is promising to see this land early in the WordPress 6.0 release cycle. The feature will still need some work before it is ready for core, such as figuring out how to best to save user customizations of style variations.
The block editor handbook already has documentation on global style variations. It is short, but custom JSON files should follow the standard theme.json schema. Not mentioned in the docs is that you need to add the version key to each file:
If I did not add it, none of my variations worked in testing. I do not know if it is a bug or intentional. I expected it to fall back to the setting from the primary theme.json file.
You also cannot overwrite a single value in an array of items. For example, if adding a settings.colors.palette value, it replaces the entire palette.
I am excited to experiment with this new feature, though I am curious what the process is/will be for loading different fonts. Perhaps it might somehow tie into the Web Fonts API that will hopefully make its way into Gutenberg/core?
Justin, I see in your screenshots above, you are using different fonts. Care to share how you managed that?
The Web Fonts API is also likely to happen with 6.0, so that will likely play a major role in handling those. Maybe it will land early too.
For testing right now, I used web-safe fonts in my variations. However, I have some ideas I want to test in the meantime.
It works but there are some issues to be worked out when customizing many settings in the Site Editor, and after you switch to a different json file. Let me explain:
My initial json file was not recognized initially (long day), I ended up copying the initial theme.json file provided by the theme (Hansen is my fav. Block theme – for many reasons…), and made some setting changes to the code to the copy, among other things changing the version numbers to 2, instead of 1.
At this point, Gutenberg finally recognized that there is an additional json file which I could swap out easily. So I did, and customized further (mainly colors of elements) with the Site Editor.
Now this is the tricky part. When I switched back to the original theme.json file, all my previous editing done within the Site Editor were gone, and all the default values stored in the actual file were loaded. This keped repeating every time I swapped the json files. This tells me that in the database, the modifications made to each style were NOT stored separately for each file. If not corrected, it could be wasting time, especially if you are testing different styles and customizing many things within the Site Editor, and going back and forth with different json files.
Another issue that I came across, as an example, changing the color of the Group block which is in the header area, will remain the same even if you make the color change at block level in the Site Editor. If you swap the styles in this example, to automatically have the “correct” header/footer color you have to do it either in the json files, or for each global styles Block customization in the Site Editor. That also causes an issue though… If I wanted to have different colors for the header and footer, this is not possible. Also let’s say in your json file, or later on in the Global style editor within the Site Editor you make the default background color of the Group blocks black, then each time you use the Group block in the content area (post/page/CPT), the background will always start as black, which in many cases you have to manually fix it on block level. A good remedy would be able if we could also set things according to classes not just blocks – is that even possible now?
Nevertheless, to almost any end user, the whole Site Editing experience will be a nightmare – they need to understand many things, file hierarchy, the loop, overwriting correctly CSS settings (Site editor level, block level), etc…
Also, after using the Site Editor, I can export my templates/template parts, and merge them in the initial theme, and package them as a new theme for distribution, why can’t I do to the changes I make to the Global Styles (theme.json)?
Overall though, very promising start, I am impressed thus far… This is one more important feature when done correctly will eat something that non FSE premium themes were doing for years…
Getting this early in the cycle so we can iron out the experience and mechanics. I expect it to be really good in a few iterations. I’m particularly looking forward to breach the theme-bundle wall, since all these variations are inherently compatible with every block theme out there!
Enter your email address to subscribe to this blog and receive notifications of new posts by email.
WordPress Tavern is a website about all things WordPress. We cover news and events, write plugin and theme reviews, and talk about key issues within the WordPress ecosystem…
© All Rights Reserved. Powered by WordPress, hosted by Pressable
