When a new WordPress core editor Gutenberg came out over a year ago, it rocked the WordPress community and converted everyone to WordPress.
Not surprising, considering the fact that over 36% of the top ten million websites in the world are WordPress websites.
From the moment it arrived, Gutenberg caused a lot of buzz—some positive but mostly negative. Why is that so?
Why do we love to hate Gutenberg?
Let’s make one thing clear. It’s not just the new editor and its features. It’s the nature of people.
People love to hate in big groups! There’s even science behind it.
The same thing happened with the new WordPress editor.
The fear of the unknown was very real with Gutenberg.
Back in 2018, when the first outlines of the new editor became clearer, a lot of people wondered how it would affect them. For example:
- Content editors were worried if they’ll lose the well-known word-like environment and if the content writing flow would be as it was before—focused just on the content.
- Developers were worried because there was a whole new library and language to learn (React.js).
- Salespeople were worried because they would need to devise new and interesting ways to sell it.
- WordPress agencies were worried because they would need to educate their developers and clients and do updates to potentially a whole plethora of their sites.
- Theme developers were… well, they were sort of blissfully ignorant. Especially theme developers on wordpress.org, where I’m currently a representative.
Gutenberg was a plugin, and even when it came out in December 2018, all blocks aka the new content building parts, were confined to plugins.
“Blocks don’t concern us,” or so they thought.
Phase one of Gutenberg
The landscape of themes didn’t change much on wordpress.org. There was a minimum set of functionality that could be added in the customizer, some page templates, and for the really enthusiastic, there was (and still is) the option to make a theme compatible with specific plugins, like WooCommerce or maybe Events Calendar.
Not many theme authors made their themes ‘block compatible’.
If existing styles are set up global enough, it’s possible to just scrape through with blocks, as they will inherit font style and sizes. If something is broken, a support question will probably arrive so it could be fixed in the update.
Plus, blocks cannot be bundled in themes, so why bother?
Life was fine.
Until phase two of Gutenberg started to happen.
The end of themes as we know it
Phase two of the Gutenberg development started to extend the editor outside of the editor screen.
First, the widgets were ‘blockified’. Then the menus got to be a part of the blocks family. The last part, which is currently in development, is the full site editing and global styles part.
And the development is a rapid one, spearheaded by the Automattic, a company behind wordpress.com (not to be confused with wordpress.org which is an open-source project behind the WordPress CMS).
How does this affect themes?
In short, the core editor already (to an extent) allows users to use blocks in order to create static page elements and layouts. Full site editing improves on this and also changes the way the themes render templates.
Traditionally, templates were written in PHP. With full site editing, they’ll become HTML templates containing a so-called block grammar. These templates will then be visible and editable in the Appearance part of your WordPress admin.
All this can be explored by installing the Gutenberg plugin and enabling these experiments in its settings.
Global styles would, as their name suggests, enable editing the global site styling using the editor. A theme would have a preset in the form of a json file that could be provided, but the user could edit these default settings from the admin to their liking.
Instead of having a lot of different customizer options, that authors had to add using PHP code in their theme, they’ll have an interface for providing these settings.
Suddenly themes became more involved in the grand scheme of things. Or maybe their ‘power’ is slowly being taken away from them and moved into the WordPress core? These changes caused some concerns in the WordPress theme community.
What will happen to themes once we have all this bundled in the core? Will there even be a need for one if the core is doing everything?
How can we, if we can at all, influence the direction where all of this is going?
Paradigm shift
One thing is clear: Things will change, and change is scary.
But it’s a natural part of our life. Likewise, things change and evolve in the WordPress ecosystem.
This has already happened, not once, but 4 times. WordPress had four big releases, and with each one, things changed. We can’t, and in my opinion, shouldn’t fight it.
Blocks introduced a sort of a paradigm shift, in that they forced developers to look at their sites, and at their content in a different way. I like to think that the introduction of CSS grid helped us move towards this way of thinking.
And we cannot forget the site builders that have existed for many years now. They used this way of building sites long before Gutenberg did. The only difference was that they were optional plugins.
Full site editing and global styles will change the way we build our themes. The authors will have to learn how to use the most of it.
In a way, it will force them to be more creative. To experiment a bit. To test the limits of the new way of building sites, and maybe break them and create new and interesting layouts we didn’t see before.
Ways of contributing
It might feel discouraging to contribute to an environment that is changing so rapidly. Every few weeks, there are new releases and it’s a bit hard to keep up.
Unless you’re being sponsored, it’s hard to contribute any sort of code.
And if you are not tech-savvy the amount of code in development can be daunting.
But, that’s not the only way you can contribute.
Contributing doesn’t just mean making pull requests to core or Gutenberg.
Contributors are testing things, participating in meetings, and commenting on what has been developed and how it’s progressing.
They are helping with documentation. They are assisting people in forums or on Slack. They are assisting with a lot of interesting packages and projects. And they are also experimenting and giving feedback on these issues and also building their own blocks for instance.
At Infinum we started preparing for blocks a while ago, and we are using them in a few of our projects. We already have a great WordPress boilerplate that enables you to build a theme or a plugin with modern and testable PHP code.
And recently, we started writing our own blocks and frontend library, and have made a huge stride with the documentation)—you should check it out!
And then there were themes
So while the future is a bit scary, there’s no reason to worry. We’ll adapt, and themes will exist in the WordPress ecosystem as they have, but in a different capacity.
While most of the heavy lifting will be done by the core, they will finally be the presentational wrapper they were intended to be. Developers can think of them as a view part in an MVC pattern (like a gross oversimplification, but a fair comparison I think).
And the theme author’s role will shift more to a designer one than a developer one, and not just UI design (making stuff pretty), but to a UX design role—looking into the ways to make an accessible theme that will fit their clients’ needs and maximize its usability.
One thing is certain, the future of WordPress themes will be interesting. Start contributing now if you want to be a part of it!
