WordPress Gutenberg from an agency perspective

13 minutes

read

Gutenberg was in the making for quite a while and the default editor in WordPress since some time. I personally listened to a lot of talks at WordCamps. I’ve built a couple of websites with Gutenberg and wanna show you what I learned and what new possibilities the editor brings. At the same time, I’m also a little bit worried about the endless possibilities we now get (especially for custom websites we build as an agency).

Our workflow before Gutenberg

Let’s show you really quick how we worked before Gutenberg. All our websites are based on Advanced Custom Fields. On a very small amount of our websites, we use flexible fields to give the customer the most flexibility. Most of our sites have a fixed order of fields they can fill in. Not to much drag and drop. Not too many options. Because we created the design and just want to give the customer the possibility to fill in the content. That’s what a Content Management System (CMS) is, right?

My worries

No frontend like experience

The CMS is there to fill in data. It does not need to replicate the frontend. The customer is not the designer and doesn’t need to care about the layout and styling. We just want the data and make the beauty in the frontend. With Gutenberg this line gets blurry. There are a lot of possibilities to change stylings inside the editor. Most of the things we leave up to the web designer. So we need to get rid of these options.

We also do make sure we don’t provide frontend like styles inside the editor. The customer needs to know that he/she is in a CMS and needs to fill in the content. At the same time, I know that it’s more user-friendly to provide a certain amount of similarity between front- and backend. So that’s the thin line we play on top since the WordPress 5.0 release.

Give enough similarity to the frontend, but don’t recreate it.

Recreating the frontend is a way to go and it’s absolutely possible inside Gutenberg. But I don’t share this philosophy and it means a lot of work. Our customers don’t have the budget for that I guess. To give the client a slight hint about what’s going on in the frontend while editing, I like to place the elements in the same layout as the frontend. Meaning place something side by side if it’s also that way in the frontend. We already did this pre-Gutenberg with ACF.

Too many possibilities

We consciously decided most of the time against a super flexible layout in the backend to give the client not too much power. We generally don’t use ACF Flexible Content on the very basis to create a custom layout. Meaning we don’t create everything in its own blocks. If it was that way, Gutenberg block would be a great solution and this same philosophy is baked into WP core now.

If we used ACF Flexible Content for everything, then Gutenberg Blocks would be the same, but just baked into WordPress core

We need a solution to continue building predefined layouts inside Gutenberg if we want to stay compatible in the future.

We also need to remove all these extra options provided with Gutenberg. For example to align content. Used on the correct item is very powerful, but just everywhere is just too much for us.

Have a look at the image block provided by WordPress. A lot of options a regular user doesn’t have to care about. “It’s implementation detail”, a developer would say. Hide it somewhere for the more advanced users or remove it completely.

“Decisions, not Options” — that’s a core philosophy of WordPress. In my eyes, Gutenberg violates this.

The complexity of a block

We do client work on a quite small budget. Creating custom blocks on our own seems like a lot of work. But at the same time, we don’t want to use these customizable blocks which we can get from the WordPress Plugin repo.

ACF Blocks could be a solution for that. The simple fields we need, provided in a block. When creating blocks with ACF it’s super easy and we can use all the fields we’re used to when we worked with ACF before. The feeling for the user is not 100% the same as with the core blocks since the plugin adds their own styling and overlays to it. But it’s fine to fill in the content.

What’s next?

We wanted to stay up to date with the latest technical improvements and possibilities. Gutenberg is definitely a huge improvement.

The easy solution, for now, is to install the Classic Editor Plugin. But what happens in the future? At some point the plugin gets deprecated and that’s inside the lifespan of a normal website today. So when starting a new project today, you most certainly get problems later.

The Classic Editor Plugin is not a solution for new websites

Installing the plugin on active sites is alright for now. On a later refactor or rebuild the content can be ported to blocks.

My Solutions

I’ve created a couple of websites with Gutenberg. As I was talking about my issues and worries before you can tell that I’m not completely sold by the new Block editor in WordPress core. Nevertheless, there’s not really a way around it if you wanna continue to use WordPress as a CMS. So here are some times from my experience so far.

Don’t remove custom post types

Theoretically, with blocks, we can remove custom post types completely. For example a team page. We can create a person block and repeat it to create a team page. In this case, I would still create a custom post type to create team members. This keeps the data separated and reusable. To bring the team inside a page I would then create a block which composes all post types into the view. With this solution, we can keep the data structured and still have a lot of flexibility. For example when adding a filter later to it.

Post_meta is not dead

While the content of blocks is stored inside “post_content”. This is fine in general. Since blocks are content and content. Post meta is not used for content. Back then, when Advanced Custom Fields, Carbon Fields or CMB2 were important, they throw all data into post meta which is kind of a hack. But in some cases, content needs to be shared across the page or reused on different parts. That’s where post meta still kicks in. Gutenberg even supports this usage and I highly recommend you do build certain blocks in this fashion.

Use blocks for content and leave meta in custom fields

Blocks are here to create content. Meta-information has to go somewhere else. A good spot to put this meta information in are custom fields or the common thinks like feature image, template, category, which WordPress still provides. We have a strict split between content and metadata now. Everything which is shown in one block is content and the stuff around it is metadata.

I think with this shift we are back to how it should be. Metadata, eg. “custom fields” are for additional information (meta) and blocks are for content. Over the years we started to move our content into meta fields because the possibility we had to create content was just too limited. This has changed now. Sadly under the hood, there is no new layer for blocks. Blocks are still composed into a single content field (post_content) like it used to be.

Markup and data gets blurry

Gutenberg blocks introduced a special way to store content and meta information. You can hate it or not, but the content is already rendered in HTML and stored like that in the database. No normalized data. Block meta is also stored inside HTML-comments in a JSON object. While this is also very powerful and backwards compatible with the old classic editor, a block is always tied together and we can’t use just a single field from the block (like a mail address in a person block). For me, this is something I can’t fully wrap my head around.

WordPress stores blocks as fully rendred HTML in the database. This makes the markup uneditable unless you edit the posts.

A block has to include all data in isolation

Getting data from a block and adding to the title of the post is not gonna work because the block has no idea about the post itself. This makes a block very isolated. If you wanna mix those data, it’s better to use the block just as an interface to input data and store the actual data inside post_meta. Then the data is decoupled and can be used everywhere on the page with the context of the current post.

Use post meta inside blocks

By default, the content of a block including all its options are stored inside the block itself. While this makes the block a reusable and encapsulated building block, it can introduce a lot of repetition later down the road. But listen, blocks can also use post meta to store data. Which is very nice and opens up block.

Dynamic blocks are mostly a better option

All the content of a block is rendered before saving and stored as an HTML chunk with some optional extra JSON. I’m sure there are a lot of reasons why the developers decided to solve it in this way. But in the end, we lose the flexibility to make small markup changes. Maybe we wrapped our content in a div with a certain class. That class you can’t change on blocks which are already stored in the database.
That’s why ACF Blocks are always dynamic blocks. They take a template and render it on the fly before outputting it. They’re like shortcodes. In the post_content there’s only a small piece of HTML which will be converted dynamically to the final HTML which is the output on the page. This brings the flexibility back, but at a small performance cost. I still would go for it mostly.

Think in components

What a surprise. Blocks can be used autonomously. So if you were thinking about your website as one thing. Or maybe header, content and footer. Now it’s the time to split it up into more standalone components. A block has to work regardless of what is before and what comes after. That’s not more work to do, that’s just another mindset.

A website is not one big block. It’s time to shift your mindset and think in components

Flexibility here we come

Don’t like a block? No problem — create your own and reuse it across multiple projects. We, as developers, can create almost anything. React allows us to customize the Block Sidebar, the Block Inspektor, the Block content itself and how the content gets outputted to the frontend. You see, the flexibility is huge, so is also the work to create one. The good thing — there are some really nice boilerplate out there which reduces the work tremendously. And hey, you create it once and just drop it into your next project.

If you’re gonna stick to WordPress for a while, you should invest time to build your basic blocks by yourself and reuse them

If you’re working for an agency or running one. I would suggest to take some initial time and build blocks for yourself which you can reuse later in your upcoming projects. This keeps you very flexible and you’re the one who decides which options the customer will see or not.

To conclude — to Gutenberg or not to

Just another WordPress agency?

Since the title of this article is “Gutenberg from an agency perspective” I would say go for it. Take the effort and build your custom blocks which you can reuse. It only makes sense if WordPress is your CMS of choice. By customizing core blocks you get all the flexibility and you’re able to show only the useful customizations you’re clients need to do. The editing interface will be very nice and fluid. But to get to this point it’s a lot of effort, keep that in mind. It’s an investment and a good and legit selling point (USP).

If you put in the initial effort, building websites based on Gutenberg will be a brize and your clients will love it.

ACF-Blocks — for the quick solution

If you’re building a website with WordPress once upon a time then you probably wanna use ACF Blocks. They’re very convenient to build with as we know from the Custom fields. But they’re not native Gutenberg blocks. Which means you’re stuck in a wrapper and don’t have all the possibilities.

Run, find a better solution

If you never were excited by the possibilities WordPress gives you with different content types and you’re not looking forward to using WordPress heavily I think it’s time to have a look to another CMS. WordPress won’t make you happy. Maybe have a look at Craft CMS or Kirby. Both very developer-friendly and with great documentation. And most important, they have a large amount of build-in fields. They’re not trying to recreate the frontend in the backend and provide a very flexible solution for developers to build custom interfaces.

Maybe WordPress is not the right solutions anymore. We have very good alternatives nowadays

Great project, but not solved

WordPress initiated a great project. The idea was not new. Medium.com had such an editor for years now. There it works perfectly. But combining that idea with a full-blown CMS is not an easy task to solve.

The problem of providing a simple framework for developers to build blocks and a nice interface for users with just the right amount of customization is not solved.

Disclaimer

I’ve been using WordPress for 10 years now and I’m happy with it. The community is huge, we can find solutions for everything (also solid and professional once) and it’s not too bad to work with.

Since I’m not working in an agency which is building websites on a daily basis, it’s not the right solution for me anymore. If I stayed with my former company, WordPress with Gutenberg would definitely be a candidate to stick to.