In the past, customizing the appearance of a WordPress site was limited to themes, custom CSS, and plugins or editor styling. However, things have changed, and now a more comprehensive approach is needed beyond just themes and styles. So what happens to the term ‘theme’? How do we function now and where do we look to move with it?
Is the paradigm needed?
There was a conversation on Twitter that I would like to revisit and contemplate. Although it represents only a few individuals’ opinions, it reflects some threads that others have spoken around.
Throughout the history of WordPress, there have been instances where individuals have claimed that themes are no longer relevant. For me, this isn’t one of them, personally, I see them simply adapting and that the problem lies in people’s current perception of them rather than the concept itself. This is also all my own view, so let’s dive in.
The theme as a package
There are many sources for styling beyond just the theme. You can draw from a full site editing setting, a pattern, a custom block style, a copied-in style, or a generated pattern. The theme is the bundler, the package – the wrapper that all this great stuff gets put in to share and activate. That is what ‘the theme as the package’ means, it is the method to carry everything and it’s almost a de-escalation of the term.
The importance of generators
When it comes to styling, themes are no longer enough. They may serve as a basic foundation, but they are often merely a collection of pre-existing components. If you are someone who works with clients, my suggestion is to utilize a generator that can gather patterns and various theme.json files and create customized themes for each site. This approach is similar to what _s or generators have been doing for some time. The end result might be a package, but it starts from a library, a collection of pieces that bundle into the theme.
Just add confusion
If you are deeply interested in themes or enjoy participating in related discussions, what they are or not called can be emotive, engaging. That isn’t the majority. These discussions are probably not beneficial for those who are still learning about themes or trying to determine which one is right for them.
A recent question asked by Brin Wilson on Post Status Slack, regarding the naming of themes highlighted the fact that people who truly matter may not be aware of or concerned with such details. They need clarity. Ultimately, they don’t need to know or care about these differences. They need to know if their theme works or not and if they can take advantage of all the features today they want.
Changing names confuses
Over the past few years, various names have been assigned to themes, ranging from classic, block-based, block themes to full-site – what even is a full-site is a debate as that can be a sliding scale. This isn’t a new thing either, anytime changes happen in themes a label has been put and often added to confusion. Although this is always done with good intentions, what it does is presume all ‘block themes’ are equal. It also presumes everyone is going to agree.
Even if we eventually agree on a specific term, it still doesn’t address the underlying issue of defining what kind of support in that theme is being offered. This is where plugins have proven records, and that concept works.
Tags become important again
The concept of viewing themes as a package and what it supports is not a new idea, as it is already being applied in the WordPress theme directory. However, this approach changes how we discuss themes. Full-site editing encompasses global styles, templates, and template parts, but the level of support for things including the design tools varies amongst those themes. Therefore, it is inaccurate to assume that all themes are equal. To use one term and say ‘all themes are that type’. People can’t be sure one theme will have everything.
One part of this will mean the tags in themes likely become important for those looking for certain features. If you look at this in the theme directory it makes a lot more sense to then filter what the theme truly does.
You can actually see that now and with more features coming across phases, and design tools – you can imagine that scaling. Tags in themes become really critical for themes. After all FSE is a sliding scale not a one size fits all. Therefore the term ‘block themes’ even if agreed doesn’t tell you what is supported or not in that theme.
An interesting point is the feature filter for ‘block themes’ also then shows the feature ‘Full Site Editing’ which compounds this confusion for some, if you move down today into tags for filtering. That’s understandable as a feature and to call out a term today being marketed. It does add confusion though when discovering this. It does mean tags need to consistent on theme directories no matter where they are so it’s clear.
Where now and next?
Now is not too different. I would encourage you to start saying what the theme supports. Because, as noted, you can’t say ‘block theme’ and know everything is – that sets a false idea up for those you are explaining to as it’s not generally supporting everything. You probably need to call it something today, though, to distinguish.
We are in a space that isn’t comfortable to explain, that’s problematic. However, we need to focus on talking about features, moving away from focusing on classic, block and dividing – the focus on features also excites and opens to discovery those who are going to use themes.
In the future, I have less assured feelings the concept of themes will become even a discussion topic or need a type label. A bundle, and wrapper will be needed, so that naturally could become the theme, but if that is the case it again is about what it supports more importantly. Core has more and more built-in, tools like create a theme and generators mean less is done from theme zero so the notion adapts – there is no need to distinguish in that future.