Some information about me that you need to know at the beginning of this article is that I’m a WordPress developer.
I use other frameworks as well, but WordPress has been the gateway to web development and still is a major part of my current projects.
For over 10 years I’ve been working with WordPress, well before Gutenberg existed. The default project stack has changed over the years when it came to new websites that are created and not inherited.
Project stack
In the past it started with ACF (Advanced Custom Fields), as the go-to option for templating and offering editing options on the content.
Back in 2012-2013 there weren’t many of visual builders available for WordPress, and those available were pretty buggy. The most common one was Visual Composer if I’m not mistaken. (now they parted ways in 2 different plugins: Visual Composer and WPBakery).
The project stack slowly started to incorporate visual builders in recent years. Currently, the most used approach is a hybrid between ACF and visual builders.
ACF templating
Our approach in the beginning was to always create PHP templates and implement them in a dynamic way using ACF.
This approach had many advantages for us:
- A robust template that can’t be broken by the client
- Clear instructions and details on how content can be edited
- Ease of development once we have layouts in place
- Repeater fields from ACF. This is one of the best possible features
- Flexible fields from ACF. This is the second-best thing
- A single place control for content and layout.
This was and still is one of my favorite approaches. I enjoy a more robust implementation.
It works well with a finished design that you can implement, connect to ACF for the sections you want to edit and that’s it. Add some Flexible Fields to allow sections to be moved around on the pages and you’re good to go.
The biggest disadvantage is that it’s kind of slow to develop new things from scratch. If you need a landing page with different elements that already exist, most likely you would still have to edit/create a template and reference for the ACF fields that you want to use.
Visual builders
I used Visual Composer, WPBakery, Divi, Elementor, Bricks and I hate different parts of all of them.
Some were so badly optimized back in the day that it was almost impossible to edit in “visual mode”, where you get to see the changes in real-time with CSS and JavaScript loaded. You’d go into editor mode, play with the blocks there and after that save and preview. I’m looking at you Divi and Visual Composer.
Things got better with new versions, but often they realized that the structure for certain components needed to change and you’d end up with v2 not being compatible with v3, forcing you to manually migrate some of the elements into the new format. This gave me anxiety when I saw a new release from any of these visual builders.
I guess it’s fair to say I wasn’t a big fan of them, but they have one big advantage: they’re fast for building landing pages and one-off pages.
Create some default classes to apply different styles and play with the visual builder to create a quick landing page.
Not every site is complex. Some clients want a few pages with different layouts, and for them to be able to edit content, color, and font size. This was where visual builders shined.
Just a side note, the aggressive marketing from Divi was a very bad thing in my opinion. You got the client telling you “but look at this amazing ad, and everything can be done by just dragging and dropping - you don’t even need to code”. Sure, until you need the first complex interaction on the site.
Hybrid approach
In recent years we have used a visual builder in combination with ACF and standard templating.
Do you have a custom post type that has repetitive content? Use ACF templating. Do you have unique pages? Use a Visual builder.
Based on that you can start building your project structure. Of course there are variations, you might have shortcodes, you might create custom components for your visual builder and so on.
Gutenberg the first time
I hated it. There was so much talk about it and we didn’t know what exactly will it do: is it just a fancy post editor to replace TinyMCE? is it a page builder? is it a template editor and manager? It was very fuzzy and my perception was that it didn’t have a clear direction.
I shortly interacted with it and decided “No!” and installed Classic Editor each time I started a new project, just so I don’t have to deal with Gutenberg.
For sure I wasn’t the only one who didn’t want to deal with it, and still I’m not the only one. Classic Editor is one of the most installed and best rating plugins on the platform.
On top of that, the documentation was hard to understand. Pieces were missing from the official documentation, you’d find them on the repo but not properly explained, plus the idea that uses React was a bit off-putting for me. My dev path got me familiar with VueJS, but not React.
All in all, given my experience at the time I didn’t see why I would want to use Gutenberg. It wasn’t as good as Elementor, not as useful as ACF, I didn’t see where can it fit into my projects, what was the gap that it would help me bridge over.
Gutenberg now
Things changed when I went to the WordCamp Romania 2024 that took place in Brașov. Since it’s in my home country I decided to go and see what’s about and meet some of the people that are involved in the community.
While talking to people I found out that some use a similar approach to ours (hybrid), the marketing oriented people that are not devs go full visual builder, and a good chunk of the rest recommended Gutenberg.
They were really pleased with it, saying what a good experience it is to implement it in your project now in 2024 (time of the event). And all that without trying to get me to join a cult in the process. It was more like “Just try it, you might like it now.”
First Gutenberg project
With WordCamp finished I came back home and the idea of Gutenberg was still somewhere in the corners of my mind.
Soon enough, in December, a large project come around and it was a total re-vamp of an existing site. That meant I can scratch everything and start clean however I want.
What better moment to try something you never used before?
Using Gutenberg you can go with:
- a hybrid approach: use the standard PHP templating and have blocks to define the content inside those templates.
- OR you can go FSE (Full Site Editing) which get’s rid of the PHP templates and you use blocks for all parts of the site, including templates.
I went FSE, because I felt it will help me learn more about Gutenberg this way. And I was right.
I won’t go into details about how I approached the project (maybe in an another post), but once I got the hang of it and created the structure for some of the components it all went pretty smooth.
It is a pleasure to create blocks that do specific things and see how easy it is to re-use them in different parts of your project, pair them with other existing blocks into patterns, save those patterns and apply them in sync on individually.
I almost feel like there are too many option on how you can go about building something with Gutenberg.
What I would like Gutenberg to have
Responsive controls. Controls for different viewport sizes (mobile) by default.
I know they exist in the documentation and you can implement it in your blocks and give control to the blocks for different viewport sizes. But I would want this feature implemented in the default items that you have from Gutenberg: group, heading, columns, etc.
Giving me the option to control padding, margin, font size based on different viewports right there in the Editor would be perfect. Even if it’s turned off by default and you have to enable it somehow, that is fine.
Right now you need to work around this lack of control from the Editor by using CSS classes.
Conclusion
I like it!
It’s a nice tool to have under your belt.
It has a steep learning curve and there are a lot of options to achieve the same thing, but once you decided on the direction you want to go it gets easy to implement.
I wanna thank Róbert for giving me some very useful pointers on how to start this project using Gutenberg, and also mention a great online resource for FSE which is Full Site Editing.