Let themes be themes

Let themes be themes

This talk was given at WordPress Cheltenham on 18th August 2021.

Right at the end, I will share a list of resources, so you can be sure to grab them all. This is not going to be a demo, there are going to be some things shared, but this is more an overview with some talking points.

Themes?

A lot of what I am going to share is still a work in progress. There have been some releases, but the road is still being shaped, and that’s where we all get to collaborate.

The past

Before considering how easy something is or not, it’s essential to look at how hard it was and its situation in context. Like many, I’ve been around themes for quite a long time. Those of us that have been worked around issues that we felt got better in each release. What we thought was getting easy often was getting further from a starting state, not the process itself. The ‘WP way’ was said half as a joke, mainly as a reality of the acceptance you had to do things a particular way to workaround.

The past: for themes

When I talk about the past for themes, this really is for theme builders, those that created themes. Call them developers, theme designers – whatever title – they were people who often had a combination of skills because they had to.

It often feels like it started with Kubrick. Whilst themes as a concept were around before, really many got their ‘theme moment’ with that’. It’s what people learnt from, explored and dove into to understand.

Things rapidly seemed to get complex. However, it often was a case of working around WP. How many times did you say ‘it’s the WP way’ or see compensation to workaround?

Some chose to adopt a framework; these sprung up seemingly everywhere because they made sense, but often they were a closed ecosystem, so you had to choose your path carefully. Others went for _s or other ‘untheme’ options.

Meanwhile, the working around issues continued. Options piled up. Themes had to compensate more and more. It almost felt like a never-ending cycle, and the line between a theme or plugin became incredibly blurred. Theme developers had incredible technology debt and stacks to maintain.. it just was all a lot and very far from the simple concept of a theme.

Themes had become everything. Themes had become less about design and more about how much could they do. Designers stopped getting excited; developers stopped being interested as much. I don’t say this to be harsh; I say this because I saw it and experienced it. Those that were still creating themes did so in not easy situations. Something had to change, the creativity was being lost under the complexity.

The past: for creators

But all of that was about those that created themes.. what about those that wanted to create content? To change something? Well, it was even more complicated.. often constrained.

They often had to know a framework or secret combination of plugins. If they picked a theme, they would end up often without knowing buy into a framework. Then that framework often was like learning a new system on top of WP because it was working around the WP way by doing its own way.

If they didn’t have time to DIY, they had to pay to get even the simplest update done. The concept of an open source space where you owned your content and could easily edit was a lie in that case.

If someone did change themes, often everything would get lost or change in the worst possible ways. The entire concept of themes is that you should have content split from style, but that wasn’t the case. Everything was so tied it was a tangled knotted mess that many feared to go near.

I sometimes think of the problem like this Swiss army knife. It was created as the ultimate tool, but it’s pretty useless because it has too much.
It wasn’t the intent of themes to become that, but often, they became hard to be just a theme because of having so much. To present content – which is the one job a theme should do well. They were so busy trying to do all the things and be everything.

The present

Something had to change. Something did change in the editor. Gutenberg was released.

Now, this didn’t change themes, but it put us on a path to get there.
It’s worth noting that many involved in the project come from theme backgrounds, the passion for themes are strong in WordPress, unlike many open source projects. It’s one of our biggest appeals that we embrace the designer/developer hybrids. We have this form that can celebrate creativity and allow people to express the individuality of their site with a simple click.

It was time to return to that.

The present: experience

Whilst WP has changed, so has the world outside WP. How people expect to create and interact has adapted, grown. The editor recognised this with the content itself by focusing on the block – which is a natural way to process content if you think about pattern recognition. This also translates nicely into how you can start to think about building up a visual site too.
People want more art direction, tools and the ability to ‘make it like that’ themselves, not have to pay someone to do it. The world is full of services enabling them to do that, and WP has to bring some of that enabling from a market sense.

The present: tools

Let’s dive into what is now available, as it’s a great point to start considering where things are going and how themes can be allowed to get back to being just themes.

Notice

Before I go too much further, it needs saying. If you want the latest features, you will have to use the plugin; not just WP release itself. This is how you get the experimental features and everything. It’s the current state, but you are setting up for the future if you start using these things now.

Theme.json is one of the biggest of the new features. To sum up, what this is, it would be a recipe for the theme. By having it in your theme, it ‘activates’ full site editing along with the design tools of blocks.

How does it work? Think of it as setting those settings up that appear for things like global styles, things that a block supports, and then you activate through this. Global styles if the interface for theme.json.
You can also turn on and off features, setting boundaries for customization – granular control is handy.

When I talk about block supports, what do I mean? Well, it’s things like colors, fonts. For example, color palettes and custom color support, or link colors, borders are another one.

There are also some experimental settings. Experimental is a flag used to indicate if something is a feature still a work in progress. Currently, this includes settings such as flex or font family. Block.json is a treasure trove for each block to discover things; for example, this is from group one.

You can also declare custom values in your theme.json to use throughout, for example, margins or colors.

Patterns are, in simple terms, a collection of blocks. These are powerful, and you can both declare them in a theme or even provide them in a plugin. There’s even a directory for them. I mention them here as they are a crucial part of themes in the future; by allowing complex structure like this not to have to be inside the theme files, to be swappable between any theme, that’s incredible. Even more than that, someone can browse, click and add a pattern easily into any theme they are using is so empowering.

Templates aren’t new to WP. We’ve had page templates for a while, and now they are front and centre of the experience. You not only can declare them still in the traditional way. You can have unique styling created right there on the page using the site editor for that content. For example, you can create a custom 404-page template or a template just for a post that displays coding examples. There are so many possibilities, and this really opens up a lot of art direction. You can also declare these in a theme. There is an interface to access these both in the site editor and in the editor.

Another feature is template parts. Suppose you think of these as little pieces of swappable micro templates. Header/footers are a good example that you can reuse across your site examples. You might have a theme with a few headers or with a few footers. Perhaps you have several options along the way for content to swap in and out. That’s what template parts enable you to do. You can swap these in the site editor.

Exploring

All of that is a lot of theory; how does this work in practice? Let’s try to look first at the editor itself and then some code examples of a theme I have been working on.

Here is the full site editor. It’s not that unexpected from the content editor itself. Global styles are powered by the theme.json, being the interface. Remember all those block supports we talked about? Those are at the side.

As you edit, you are saving site-specific parts and templates. These aren’t impacting the theme itself. So you aren’t overwriting anything in the theme. A theme will provide defaults, but if someone has access to this, they can, for example, create a new header or footer. Styles are also saved; they are specific to this site.

One key feature is the ability to export. This is actually a beneficial process. You can create things, export and put them in your theme if you want to create, learn and then add to your theme.

As we are talking about themes in this talk, let’s move rapidly into looking there. The structure isn’t unexpected from many themes. The biggest point is how light the theme is. Now, this will be different for everyone. Some FSE themes have more CSS, some use Sass, some don’t. Right now, everyone is exploring their own route. Some use child themes, some don’t.
Here is an example I am creating which I’ll go through to show how things could work. This is intended to use as little CSS as I can, as many of the new features as possible and be an experiment.

The theme.json is again the recipe. It’s got the elements, the colors, palettes, duotone – everything set up. It’s also worth saying you can limit things in theme.json as to if on/off. For example, want to turn off custom colors and just limit to a branding palette? No problem, you can do that in the theme.json.

Theme.json works with block specific styling. Here, you can set the way a code block outputs and all code blocks will do that.

You can also use variables that you declare and use throughout your theme.json, styles and everywhere – how cool is that?

Templates are HTML files – very simply, you can see here the blocks themselves and inline styling also. Note, these here come from exporting, as mentioned earlier.

Template parts can also be seen in this section; you could have more than one to pick from. Remember, these are defaults to be used; the person using the theme can have their own as they create without impacting the theme.

The functions.php file can have macro control over what is on/off also.
For example, you can set some of the more custom features.

The future

We’ve looked at the past, and I’ve shared what is happening now.
What about the future?

The future: experience

The experience needs to take notice and continue to adapt constantly. At one point, WP was out of step, but it’s rapidly back in step with what people expect. This is great, but we shouldn’t forget how easy it was to get to a place where themes weren’t what they should have been in the first place.

Themes can be simpler if we let them; the experience can be too. This means not showing everything to everyone all at once, for example, or overwhelming them.

There is the ability to enable people through true art direction, from patterns to global styles. This puts capabilities into people’s hands that previously felt incredibly out of reach. With great power comes responsibility though, it’s up to those creating themes and the experiences to create something that doesn’t confuse and allows good defaults.

Patterns allow someone to “make it like that”, see something, browse and add it to their site. This is incredible and powerful. It will also only get more empowering once patterns explore the functionality and connect with plugins more closely.

The biggest excitement about the experience has to be that themes can switch seamlessly. This honestly has never really been that possible once you get beyond default content, even though we always hoped for it.
Imagine if a theme was as easy to change as your t-shirt. No matter your mood, you can change it, even bring back those theme switchers of the early 00s. Themes can return to being about style, beautiful, experimental and delightful pieces of art.

The future : tools

What about the tools, specifically for those creating themes. I tend to think about theme creators, not theme developers because that’s then including those who use the site editor and those who will dive into the code itself. Themes are open again for as many as possible, resulting in a wider range of designs and theme art.

Design tools are something inspiring. What do I mean by those? Well, they are tools that activate across blocks to allow the creation of designs. From adaptive design through to color controls – there are many coming, and it is fascinating. By having these tools everyone can use, they have an interface people can trust. Theme creators can know to support them, but also those using the themes can learn once and use them often. That’s empowering. You only have to learn one way.

Each block area should be intrinsically responsive allowing blocks to compose together, wrap, stack, and organize themselves to fit the different spaces and screens. For this to work well, container blocks need to absorb more layout controls……

…..Typography tools need to become more fluid and internally support algorithmic clamping. Whenever possible, patterns should just work and accommodate themselves.

make.wordpress.org/core/2021/08/13/preliminary-road-to-5-9/

The blocks themselves need to have better control. Matías talked in his post about intrinsic design principles. This has long been awaited. It will also be a huge step forward for everyone, and avoid using a stack of plugins or ways around. It’s also truly responsive as opposed to getting stuck at breakpoints.

Full site editing is just getting started. It can feel tempting to judge what we have now, but it’s more of a prototype that we are all getting to help shape. Think of it as the clay; we are all forming together in a public workroom. That’s why it’s only activated when the plugin is, why this a lot is under experimental flags. As things mature, that’s when this gets very exciting and powerful.

In the end, the biggest part of this is to let themes be themes. They won’t have to be everything anymore. People can learn WP; they won’t have to learn another framework to change the design. Or be locked into an ecosystem.

There’s a lot of business opportunities also beyond what was before. Themes have become a chore to maintain, and this all means a freeing of the medium. A return to what they were always meant to be, a style you applied to your content – your site. We are about to have a kit of incredible tools to use in our work, and it’s an exciting time to create themes again.

Here is where you can find a link to a list of resources.