WordPress is changing fast. Changing the concept of topics, changing Gutenberg. How that will go is not clear. But following the process is pretty fun. NIX Solutions translated a VC’ article, so now we can talk about what is new with WordPress themes over the past year and what we might need to prepare for.
Before and after 5.0
The ultimate goal of WordPress (and Gutenberg) is to enable users to customize every aspect of their site through a block system. Currently, the block system allows you to edit only the content of posts, but as soon as we get closer to full-site editing, each part of the page will become a block. And, therefore, available for change. Imagine a world in which users can place blocks in a footer or header.
One of the steps at this stage was the introduction of Gutenberg. We will not say much about GB itself, but we want to mention the events a year ago that have affected all of us.
Yes, we are talking about the time when WordPress 5.0 brought us Gutenberg, instead of the classic editor. And for many it became a real pain. But, as practice shows, a person gets used to everything, even to Gutenberg’s.
And if you look at it from the positive side, here are a few of the benefits of Gutenberg:
- It will be a definite plus if you started using WordPress since version 5.0 and just did not see anything else.
- With Gutenberg, you do not need to produce dozens of page templates. One or more is enough, and different design variations can be created in blocks.
- Blocks are universal for different types of data. This means that the same block can be used both in posts and pages.
- Developers can write their own blocks. Today there are dozens of plugins that add a variety of blocks to the editor. From simple dividers to complex galleries and feedback forms.
Let’s face it: the classic editor works great with short posts with a couple of headings and paragraphs. But as soon as you need to create a post where there will be several columns without shortcodes, without opening the Text tab at the same time, real problems begin.
Blocks not only in content
As mentioned above, WordPress aims to provide users with the ability to customize every aspect of their site using a block system. Now this system supports mainly editing the content of the post.
To achieve full-site editing, each piece of dynamic site data must become a block. For example, a site navigation block. And the user should be able to place it anywhere. Even in the header, if they want so.
Preparatory work to ensure such a future has been ongoing for more than a year. True, out of the planned 9 projects in 2019, only 2 were 100% implemented and launched, which is not bad in the context of such global changes. From the innovations of last year: all existing widgets were ported to blocks and the Site Health check plugin was added to the kernel to facilitate debugging.
2020 should be the year of full-site editing. You can monitor (and participate) the process in the core-editor Slack channel. And, of course, work will continue on the block directory.
All this gives rise to a very natural question for us: if users can move blocks arbitrarily back and forth, how will everything fit into the themes themselves? And if the site will consist entirely of blocks, do you really need themes at all?
Now for comparison, everything is crammed into the most popular themes with ThemeForest: styles, page templates, and a bunch of options.
Themes are still themes
If you get through the jungle of WordPress, then the themes have always been HTML and CSS. And PHP itself simply mixed the call of PHP functions (for example, template tags) with some structured HTML markup. And if you look at most of the templates that are in the official WordPress directory, you can easily notice that the main markup has remained almost the same old, kind and familiar.
In the block system of templates, too, nothing has changed. Well, maybe just a tad bit. But these changes should facilitate the work of the creators of templates in terms of creating sets of standard elements (blocks). And if everything goes as it should, then they will also help create standards for class names, so that styles can be shared right and left within the framework of the template.
For example, if we need a new component, then on PHP we make some “Block Areas”, and then we create all the areas that the user needs (sidebar, header, footer, etc.) and then assign them to a place in the template.
Instead of conclusions
All of the above has not yet been immortalized on the tablets of history and is under development, to which you can well join. As well as discussions about how to be a style system for blocks, for example, or discussing future patterns. WordPress 5.3 has already gathered around 645 volunteers and it seems that this is certainly not the limit.