Jay Hoffmann

Books, movies, and code

Using Full Site Editing as a Developer

I’m cooking up something new for History of the Web which will take it in a slightly different direction (though a lot of it, of course, will mostly be the same and it likely feels bigger for me than it will be for anybody that visits the site). In any case, this new directions has me experimenting with Full Site Editing.

In my professional work at Reaktiv, I’m often building various elements for the WordPress block editor within a full site editing environment. But I haven’t had much experience using it as a site editor and user. Doing that work has had me re-evaluating the way that I build websites, particularly because I prefer having granular control over every pixel, a luxury that standard block based themes may not offer.

Using the WordPress Full Site Editor

My disclaimer on the above is, the limitations of the editor are a feature, not a bug. They present a system of components for use on a site, meaning you don’t skew too far from your core design. But sometimes I do want to bust out and

I tend to agree with what I think is a popular sentiment, that when full site editing functions smoothly, it’s something akin to magic. However, when it feels clunky and cumbersome, it can bring your work to a grinding halt. Thankfully, my experience has been more of the former than the latter.

But there are frustrating moments. Especially when you are trying to move things around, drag blocks from one place to another and experiment. You end up fighting against the editor, tweaking groups within columns within groups to make sure everything is aligned and arranged correctly. And then sometimes you have to just scrap it and start again.

Need to edit the typography for the site? Pop open the styles panel on the right. Oh, did you mean the overall styles on a different template? Now you’ve got to toggle back to the navigation on the left side. Trying to drag blocks around? Better open the Document Overview to make that a bit easier. But then you’ve got to pop open the blocks sidebar to get a little more control over each block. And round and round we go.

But on the flip side, there is so much I don’t have to do. Comments look great. Posts look great. I can edit a font or a color directly in the editor, and it instantly applies everywhere. I can create responsive columns with a simple drag and drop. At times, I sail through a layout, realizing that I’ve achieved it with minimal effort.

Working with the editor is both sides of this coin.

Finding Block Themes

One of the first questions I had was where even to start. I could build a theme from scratch but for a lot of personal projects I think that’s going to be a mistake. For me, at least, I found that using a theme as a starting point, and then customizing from there, was a lot better.

Themes have opinions. At least, the good ones too. So I’d say the biggest trick is finding a theme that has an opinion that resonates with you, and then going for it.

You could build a theme from scratch, but for a lot of projects I think that’s going to be a mistake. Far better, I think, to find a theme that you like and then customize it how you want. A lot of themes have a sort of opinion to them, and if you like that opinion, then you might as well go with it.

As a reference, here’s a few places I found some high quality themes:

  1. Anders Norén has some fantastic themes. They are definitely opinionated, but beautiful
  2. Auttomattic also has some good block based themes. The theme on this blog (Bitácora) is one of those.
  3. Twenty Twenty Four is incredibly good

I think that starting with Twenty Twenty Four is a solid move. It’s got a theme.json file that’s far more complete than a lot of other themes, and it’s a useful guide for the kinds of things that you might want to customize.

It’s a bit plain, and that’s certainly by design, but if you mix together it’s variations and patterns you have a really good starting point. I think the core team did a great job building it, and if you’re not sure what to turn to for your theme, that’s where I would go.

For me, I turned to a couple of themes that had more of a classic blog feel. My only complaint about Twenty Twenty Four is that it is relatively stark and empty. It has plain typography and clearly wants images to do the heavy lifting. If you’ve checked out my work you know that I like to use a lot of words. So it didn’t really fit for me. Instead, I turned to Bitacora, which has less features to it, but has an opinion on its design that I quite life.

The Secret Sauce is… A few custom blocks

So what’s the difference maker? I’ve adopted an approach that I hardly consider novel or new, but might help other developers with some WordPress coding experience who are looking to ease into Full Site Editing. So here it is:

Create your own blocks.

Small ones. Utility ones. Blocks that cover specific designs you can’t quite fit into the editor. Blocks that pull content from places the query loop can’t quite pull from.

The create-block script is really good. It generates all of the scaffolding you need, and then a lot of code goes into the edit.js file and the render.php file.

The thing about my blocks is I really just need them to do a specific thing. So, there are not many options. In the editor, Sometimes, I might even just put a placeholder inside of edit.js that tells me what it is, and I leave all the rendering to the template.

Would I do this if I was building this out for clients or other people? No, absolutely not. But sometimes I just need a bit of CSS, HTML and JavaScript to weave together something really particular that I want that dragging blocks around just can’t provide.

I’m a tinkerer and a coder and I like to find a balance between a website that does a lot of what I need and granular control. I like Full Site Editing. I plan to keep experimenting with it. But every time I bump up against it, I bring that flexibility back with a block or two.

I recognize that maybe it’s not for everyone. But maybe, it’ll work for you.