Update: I’ve reverted this theme right now back to a hybrid theme as I need to add rel=me atrribute to my Mastodon accounts and the WordPress social links block doesn’t support that right now
As mentioned in my last post, I declared I would use this site as the basis for road testing WordPress’ Full site editing feature.
Et voila.
Before & After.
So how was it?
Well. In classic developer parlance ‘It depends’. Some initial thoughts (I’ll add and edit this post as I think of more things that occurred to me)
Losing my <head>
With FSE you have templates and template parts and from what I can see no way of controlling the full DOM. As such where I might tweak things like meta tags, preload, scripts, Google tag manager, URL params, PHP variables etc. I don’t have access to this out of the box. There are a number of functions I could use I guess but it was weird suddenly not having control over the full DOM.
DX
There I said it. Always felt the term DX was a little bit narcissistic but the DX of the templates are crunchy. It’s all DIV/JSON soup. These all get passed to the admin interface so that does make sense, but oof.
<!-- wp:group {"align":"full","style":{"spacing":{"margin":{"bottom":"0px","top":"0px"},"padding":{"top":"1.25rem","right":"1.25rem","bottom":"1.25rem","left":"1.25rem"}}},"layout":{"inherit":true}} -->
😱😱😱😱
Old habits die hard
I kept trying to build out structures in semantic name-spaced html via my code editor but the template parts kept breaking.
Styling/layout is done in the admin settings not CSS/HTML. I tried setting the spacing in CSS but realised that’s not ‘the way’ so back to the admin I go. Tried where possible not to use CSS but for some things (container widths / alignment) I found I had to. As the theme development progressed I gradually removed more CSS as I figured out how to do stuff natively in FSE (either via theme.json or the Editor)
But it’s still a bit limited. I found the lack of control a little vertigo inducing at first but then I found I could do more stuff in theme.json like spacing for specific blocks e.g. post-title.
It’s a big paradigm shift.
"core/paragraph": {
"spacing": {
"margin": {
"top": "var(--wp--custom--spacing--baseline)",
"right": "0",
"bottom": "var(--wp--custom--spacing--baseline)",
"left": "0"
}
},
"typography": {
"lineHeight": "var(--wp--custom--typography--line-height--body)"
}
}Design system
There are the beginnings of some nice stuff with theme.json but then the default 22 theme just smashes random spacing in JSON-esque markup in template parts. These are then exposed in the admin and can be changed to your liking but….
Spicey spacer gifs everywhere.
<!-- wp:spacer {"height":180} -->
<div style="height:180px" aria-hidden="true" class="wp-block-spacer"></div>
<!-- /wp:spacer -->😱😱😱😱
Sure, component based design and spacing within a block can be achieved using a mix of techniques. But I found that some blocks are full blown components with elements scoped to a parent container yet some that are just HTML (H2, P). This poses issues when trying to achieve consistent spacing between elements. Say for example I have a cover block as the last item on the page. I want it to be flush to the footer. But if it’s a paragraph I don’t want that. But i might want more spacing than the usual margin. I can’t use last of type. I guess I could use last of type ~ sibling. Is spacer gif the only answer? I guess what I really want is sections of content. Which I could do as a group. But feels like there should just be a content block for headings, para, lists etc.
Who is this for?
At first I went straight to my code editor to try and build out the base HTML. Wrong approach. I started again from scratch and built out the header / footer / query block in the editor and copied the code back into my theme. Much better results.
But here’s the rub, do I expect a client to be editing the query block or even want to. The answer is probably ‘not now’ and maybe that’s the point. But they could. Effectively they don’t need me, they could just read the docs, open up the full site editor and change something (in staging for the love of god) and voila. It’s done. This is potentially very powerful.
Right now clients shudder in horror that anyone with the relevant rights could just delete the menu or change the settings for the blog feed. But maybe that’s okay. Maybe we are on a journey and maybe the destination is a sort of super admin/developer/lower barrier to entry. No build systems. No continuous integration. No legacy code. No engineering degrees.
I kind of like it. But it’s still raw.
What do I want?
I guess cake and eating of the cake. I want the fine control – for example; I had custom gradients on the social SVG icons in the footer before, now it’s these icons or no icons. But I also want my users (editors) to have more control. So overall maybe this is the right direction.
I will gradually Marty McFly into non-existence whilst the all powerful (full site) editor takes over an alternate theme building timeline.
One thought on “Cooking with Full Site Editing”