Unlike routine testing rounds for the FSE Outreach Program, Anne McCarthy threw a bit of a twist on the Make WordPress Test blog earlier today. The announcement asks users to think about what they would like to see when switching between block themes. The test is open to anyone who wants to participate through September 29.
The steps are loose and not required. The goal is to get people thinking and discussing what the theme-switching flow will look like over time. McCarthy asked several questions, but they are merely a starting point for a more open-ended discussion.
While I sometimes need structure, I tend to break the rules anyway. The format of this test suited me well today.
I am not one for switching themes. Since I learned how to design for WordPress well over a decade ago, I have never moved from one theme to the next. At least not in the same way that the average user would. Instead, every time I have added a new coat of paint on my websites, I have simply switched over the foundation to whatever I had been working on at the given moment. WordPress themes, for me, were always just an iteration upon the last project.
One of the cornerstones of programming is to reuse your code, and it is a principle that I have taken to heart. Even now, as I continue to explore block theme design, I am doing so from a gutted version of the last WordPress theme I built.
When I think about switching themes, it is not an experience that I am accustomed to. Even when I started working for WP Tavern, the site already used one of my themes with some customizations. It feels like I have missed out. Throughout my entire journey with WordPress since version 1.5, in which the platform first introduced themes, I have never truly experienced the theme-switching process in the most fundamental way. I will soon, but we will talk about that on another day.
When I have “switched” themes, I have done so in test environments for writing about them or running tech support for end-users.
The call for exploration mainly focused on global design-related features. However, in my experience, these tend to matter far less than what a user’s content will look like. The first thing I do when testing any theme is to load a demo post. Lately, this has been the “Welcome to the Gutenberg Editor” test post. The primary question: Can I read the content comfortably? If I do not get past this stage, I simply deactivate the theme.
For this experiment, I chose three themes:
I started with that foundation of testing how easy it was to read a simple blog post.
Overall, each theme performed admirably. However, Quadrat’s use of the featured image on a single post view felt out of place.
One question that keeps me up at night is how cross-theme compatibility will work on the content level. Default block output should translate from one theme to the next with little or no issues. However, custom block styles, font sizes, colors, and the full range of presets are already a problem area.
This is not a new conversation. There is an ongoing discussion on standardizing some features. But the cat is already out of the bag and running loose through the house.
Global styles and templates are features that themers have been dealing with for years in some form or another. The new systems are just different ways of doing the same thing.
However, when design elements merge with content, switching themes becomes more complex without an underlying, standardized system. To illustrate this point, I checked all three of my test themes against a post that used custom block styles, gradient colors, and font sizes. I wanted to push the boundaries beyond a simple blog post.
The content was built with my custom theme and an “open canvas” template. Quadrat had a similar template for hiding the post title, but TT1 Blocks did not.
The result was, ahem, rough:
Of course, my custom theme looks as it should. This is not to say that TT1 Blocks and Quadrat are poorly designed. They are actually two of the best block themes available at the moment. The problem is that they do not share the same block styles and presets. WordPress and Gutenberg are also missing some fundamental layout tools that could make it easier to carry this design from one theme to the next.
The most complex piece of the design is with the opening Cover block pattern:
Technically, this is a Cover block within another. The bottom layer has a background image with a duotone filter and sets the inner content to 90% width of its parent. The second layer has a theme-defined gradient background and sets its inside container to the left at 50% width. Plus, it has a sprinkling of custom font sizes.
These layout controls are only possible through custom block styles or some hacky uses of the Columns block. I chose the former because it was easier, but it also means they are broken when used with any other theme.
While I called this the most complex piece of the design, it is 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 this the longer we wait.
The open discussions on standardizing presets like font sizes and color names may bear fruit that could help with the more trivial parts. However, I have not seen gradient names pop up in this discussion.
I do have at least one ulterior motive for this test. I have long wanted to try more experimental post designs and layouts here at WP Tavern. However, I know that we will eventually switch themes. That voice in the back of my mind always reminds me that those custom-designed post layouts will likely break when that day comes. The tools are not advanced enough for me to take the plunge. Not yet anyway.
At this point, I am sure that I am no longer following the intended direction of the call for exploration. However, I am just letting the journey take me where I am meant to go. My destination is an addition to my wish list: more robust layout tools that work from theme to theme.
Like this:
Like Loading…
