Overview of switching between block themes – WP Tavern
Unlike the routine test rounds for the FSE Outreach Program, Anne McCarthy threw a bit of a twist on the Make WordPress Test blog earlier today. The ad asks users to think about what they would like to see when they switch between block themes. The test is open to anyone wishing to participate until September 29.
The steps are loose and not necessary. The goal is to get people thinking and discussing what the flow of theme change will look like over time. McCarthy has asked several questions, but they are just a starting point for a more open discussion.
Even though I sometimes need structure, I tend to break the rules anyway. The format of this test suited me well today.
I’m not the type to change the theme. Since I learned to design for WordPress over ten years ago, I have never switched from one theme to another. At least not in the same way the average user would. Instead, every time I added a new coat of paint to my websites, I simply replaced the foundation with what I had been working on at some point. WordPress themes, for me, were always just an iteration on the last project.
One of the cornerstones of programming is reusing your code, and it’s a principle I’ve taken to heart. Even now, as I continue to explore block theme design, I’m doing it from a gutted version of the last WordPress theme I built.
When I think about changing the theme, it’s not an experience I’m used to. Even when I started working for WP Tavern, the site was already using one of my themes with a few customizations. I feel like I missed something. Throughout my journey with WordPress since version 1.5, where the platform first introduced themes, I have never really experienced the process of changing themes in the most fundamental way. I’ll do it soon, but we’ll talk about it another day.
When I “changed” the theme, I did so in test environments to write about them or run tech support for end users.
The call for exploration mainly focused on the overall design features. However, in my experience, these tend to matter a lot less than what a user’s content will look like. The first thing I do when testing a theme is upload a demo article. Lately this has been the “Welcome to the Gutenberg Editor” test post. The main question: Can I read the content comfortably? If I don’t go past this step, I just turn off the theme.
For this experience, I chose three themes:
I started by testing how easy it was to read a simple blog post.
Overall, each theme worked admirably. However, Quadrat’s use of the image shown on a single station view seemed out of place.
One question that keeps me awake at night is how the cross-theme compatibility will work at the content level. The default block output should translate from theme to theme with little to no issues. However, there are already issues with custom block styles, font sizes, colors, and the full range of presets.
This is not a new conversation. A discussion is underway on the standardization of certain functionalities. But the the cat is already out of the bag and run free around the house.
Global styles and templates are features that themers have been dealing with for years in one form or another. The new systems are just different ways of doing the same thing.
However, when design elements merge with content, changing the theme becomes more complex without an underlying standardized system. To illustrate this point, I compared my three test themes to an article that used custom block styles, color gradients, and font sizes. I wanted to push the boundaries beyond a simple blog post.
The content was created with my custom theme and an “open canvas” template. Quadrat had a similar pattern for hiding the post title, but not the TT1 blocks.
The result was, hum, rough:
Of course my custom theme looks the way it should. This does not mean that the TT1 and Quadrat blocks are poorly designed. These are actually two of the best block themes available right now. The problem is, they don’t share the same block styles and presets. WordPress and Gutenberg also lack some fundamental layout tools that could make it easier to transport this design from one theme to another.
The most intricate piece of the design is with the opening cover block pattern:
Technically, it’s a Cover block within another. The bottom layer has a background image with a two-color filter and sets the inner content to 90% of the width of its parent. The second layer has a gradient background defined by the theme and sets its inner container to the left at 50% width. Plus, it has a sprinkle of custom font sizes.
These layout controls are only possible through custom block styles or some hacked uses of the Columns block. I chose the first one because it was easier, but it also means that they are broken when used with another theme.
Although I’ve called this the more complex part of the design, it’s actually a simple thing to do with most page builders or with a few lines of CSS. Until WordPress has some type of grid container block, theme authors will rely on custom techniques to make such layouts possible. It can and will get even uglier than that the longer we wait.
Open discussions about standardizing presets like font sizes and color names can pay off and help with the more trivial parts. However, I didn’t see any gradient names popping up in this thread.
I have at least an ulterior motive for this test. I’ve long wanted to try more experimental post designs and layouts here at WP Tavern. However, I know that we will eventually change the theme. That voice in the back of my mind always reminds me that those custom post layouts are likely to break that day. The tools are not advanced enough for me to start. Not yet anyway.
At this point, I’m sure I’m off the intended direction of the call to explore. However, I just let the trip take me to where I’m meant to go. My destination is an addition to my wishlist: more robust layout tools that work from theme to theme.