WordPress Gutenberg – a guide for developers and digital agencies
It’s been 1,5 years since WordPress Gutenberg Editor was introduced to come with WordPress 5.0 in December 2018. It revolutionized the content editor and polarized the community of WordPress users and developers. While some embraced its new potential, others were blunt and blatant about their dislike of the changes. In one way or another, the community was and still is pressing a question: “Do we really have to use Gutenberg? Is it here to stay?” In this post, I’d like to propose an answer to that question. Also, based on our company’s experiences, I’d like to share some insights about taking the opportunities provided by WordPress Gutenberg and point to potential dead-ends that one should be aware of.
What does the community love and hate about the Gutenberg?
On the good side, people say that the new editor makes it easier to build complex layouts. The blocks can be moved around by drag and drop. It is also easy to access them thanks to the search field (in the inserter panel). The front-end editor makes the edited page look more like what the visitor sees. Many admins will find it be a useful tool. Also, the editor updates in real time because it is built on React JS.
On the bad side, people didn’t like the new editor and one of the reasons is because it is… new. Sounds strange, right? Well, it’s true. The new editor doesn’t look like the old one, it’s not an incremental improvement; it is a complete change. Some people don’t like it. Why? Because they have to learn it and change their habits about WordPress. Subsequently, they have to use some extra time for that learning.
Are they being lazy? Maybe…but there is a little bit more to the story. We can hear many of those voices. Especially coming from digital agencies and developers, express concerns about the impact of that change on their businesses. They are concerned about the fact that they will need to spend a lot of time teaching and instructing their clients, who might find the new editor challenging. Another issue is that Gutenberg is not compatible with old WP themes and plugins, so some of the websites might require a migration which is a hazard when it comes to budgeting and estimations.
Do we have to use Gutenberg? Is it here to stay?
Automattic, the company behind WordPress, predicted such problems will arise. As you well know, they introduced the Classic Editor plugin that allows website owners and developers to use the old editor while still keeping their WordPress theme up-to-date. Before Gutenberg was launched, Matt Mullenweg, the CEO of Automattic had said that there are two scenarios when it comes to Gutenberg & Classic editors.
The first one is that when the community embraces Gutenberg and the usage of the Classic Editor drops, the latter will have no official support. The second is that the Classic Editor gains and then retains such a strong position, that in the end, we will have two separate versions of the environment. One dedicated to the Classic WordPress and another - to WordPress Gutenberg.
Which scenario is more likely? The Classic Editor plugin has got 5+ million active installations with an average rate of 5/5 so that might suggest the second scenario. I, however, seriously doubt it. Even though the Classic Editor has got many users, its active growth index is gradually falling.
In October 2019, the active growth index was at 0.6% but in June 2020 it was only around 0.49%. This means that the usage is still growing, but the pace of that growth is diminishing. Matt Mullenweg at the State of the World 2019 conference said that the number of Classic Editor users is decreasing and that it might be even as early as January 2022 when official support for the Classic Editor is finished. Listen to Matt answering a question about that:
The same information was announced on the Wordpress.org website.
Don't panic, think about future
There is a good chance that the official support for the Classic Editor will last longer if the number of users stays high. Otherwise it might continue unofficially supporting by the community without the resources of the Automattic team. There is no reason to panic but it doesn’t mean you shouldn’t think and plan ahead. As it seems, Gutenberg is here to stay, and it’s the Classic Editor’s life that is at stake. It’s also worth considering that if Automatic is planning to abandon the Classic Editor at some point, there is a little chance that the creators of other plugins won’t move on, too.
This is why I hypothesize that as for now we don’t have to use the Gutenberg editor for every website. Unless the projects that we are working on, are meant to stay online for a few years. I think, most of them do. If they’re based on Gutenberg, they may benefit from future updates, functionalities, and plugins that will be developed solely for the Gutenberg environment. I think that if we don’t use Gutenberg for our upcoming themes, we run a risk that in 2022+ updates will start causing issues and our clients won’t be able to use new Gutenberg functionalities. Also, installing new plugins or their functionalities might be hindered.
How to use the potential of the Gutenberg editor?
Here at Chop Chop, we mostly develop custom themes for digital agencies and end clients. So our insights come from this particular area of the WordPress world. Preparing for the new situation, we decided that apart from what we were already doing (tailor-made solutions, easy to use backend, and modular development), we will focus the performance and pagespeed of the themes that we develop.
The performance of the site is measured by Google Page Speed Insights and it is a crucial factor nowadays. Users expect a website to work fast and if it doesn’t, there is a chance they’ll leave and increase the site’s bounce rate index. If a site performs poorly in Page Speed Insights, Google’s algorithm may also “punish” it by reducing its position in SEO ranking and increasing the cost of Google Ads directed to that site. No one wants that. A high bounce rate decreases the conversions too. A few years back, Amazon said that every additional second in page load time, reduced their sales by 1%. That would mean a $1.6 billion loss. BBC found that for every additional second in load time, 10% of users leave.
So, what is our take on Gutenberg? To increase the performance, *we don’t load all of the scripts and styles on every page *. We created functions to load only those styles and scripts that are needed for modules used on a given page. We also use traditional methods like minification, cache, asynchronous scripts loading, adding images in webp format, and lazy loading. If you want to learn the technical details of that setup, read more here. To give you a glimpse, we have built an sample site using these solutions and it reached 99/100 on mobile and 100/100 on the desktop in Google Page Speed Insight.
We’ve been used to building modular themes for a long time (those modules are like lego bricks that you can set in any order you want). We believe that this approach is even more relevant in WordPress Gutenberg. The idea is that a page is divided into reusable blocks that can be arranged in various ways to freely create subpages. This means that if a designer prepares about 10 to 20 modules, then they can be used for creating multiple different pages. Even if a site requires some unique landing pages not based on the modules, it can be done too. This is a good balance between making a theme unique and maintaining a sustainable budget.
We make the best of that approach and bring it to a higher level with our digital agencies partners. In collaboration with them, *we create starter themes that have reusable modules *with very basic look and functionality. Those themes are based on the particular Agency’s ideas and needs. Using the starter themes, our partners create designs taking the base modules as a boilerplate. This cuts down the time and money spent on development. We don’t reinvent the wheel every single time. Each of those projects has got additional unique landing pages to make a site stand out among the competition.
What can be problematic about Gutenberg projects?
One important deadlock is on the development side. Even though there is documentation for coding Gutenberg blocks and there are some resources online, they are not as robust as those for classic WordPress. Frankly they are rather scarce. This means that developers who are new to Gutenberg might encounter challenges before they find an efficient way of developing Gutenberg themes. It took us some time, too.
The development time
Creating custom Gutenberg blocks is time-consuming and may far exceed the development time of an equivalent classic WordPress page. Especially if they are meant to be fully interactive in the panel as native Gutenberg blocks, and if developers are new to Gutenberg. This is why we use Advanced Custom Fields to build most of the new blocks. With ACF, blocks can be built much faster and with code that is much more familiar to WordPress developers than the native blocks implementation. We have also created several premade custom blocks and can use them for a given project; and - as we learn what gets used most often - we are building more. They are reusable building blocks that help us save more time the more we use them.
By now you probably can see that the time and cost is a recurring theme of this post.
Another potential deadlock connected to that lies on the design side. We can see that there are many designers in the business that do not grasp the concept of modularity. I understand that some websites are really unique and there’s a reason for them not to use any reusable modules. If that’s the concept and there’s a budget for it, it is fine and it is a kind of projects we really enjoy ;)
The problem that we see from time to time is that some designers are not aware of the modularity concept at all. And understanding it is crucial because a designer with a modularity perspective can have a better control over the project’s budget. They know that if they design every page to be unique, it will require a much bigger development budget. But they can reduce it by using reusable blocks and then direct more resources into creating fancy landing pages, animations, or interactions. IT projects can get pretty expensive and it’s really important to know the consequence of your choices.
There is a quote about the need for adaptation attributed to Charles Darwin. He never said it but it is still true: “It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is most adaptable to change”. I wonder to what extent it fits the situation of the Gutenberg and the Classic editors. I think it does, but I leave the judgment to you. For sure, the future of WordPress is tightly connected with Gutenberg. I have a feeling that this train is leaving the station and it is good to be on board from the start. Despite the challenges, it’s going to be an interesting ride.