Cooking with Full Site Editing

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.

Before and after building a theme in Full Site Editing

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.


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.


Decided I am going to use this site to build my first Full Site Editing WordPress theme.

So all HTML, JSON and CSS. No PHP (well some PHP obvs, it’s still WordPress. You need (for now at least) functions.php so you can add stuff like a custom CSS file and other stuff). I’m going to use this theme by Fränk Klein as a starting point, turning everything off so I can gradually turn it back on again.

I’ve been building themes since 2004, maybe even 2003. It’s going to be weird. 18/19 years of pretty much the same syntax. No idea when I’ll launch it, but sometime soon.

Sleep well sweet prince.

<?php if (have_posts()) : ?>		
	<?php while (have_posts()) : the_post(); ?>
		<?php the_title(); ?>
		<?php the_content(); ?>
	<?php endwhile; ?>
<?php endif; ?>

Website goes to 11(ty)

I’ve been playing around with Nunjucks and various static site generators (SSGs) over the last couple of years now. Building my smaller non-CMSy sites,, using a mixture of techniques and build scripts.

I’ve loved it, its’s like olden days web development, HTML, CSS, Javascript but with super powers. Gulp scripts taking the mundane tasks such as image resizing and optimisation, favicon generation, script and styles pre and post processing and much more.

Around a year ago (I think, pandemics have destroyed my concept of time) I started to use 11ty after playing around the edges for a while. It’s even more of a delight, it get’s out of the way, taking care of all the hard stuff so wonderfully. Local and remote data becomes such an easy thing. It’s concept of ‘collections’ is excellent, here’s my content type based on a local data file (say an object) or remote fetch (API, graphQL), here’s the template I want it to use and voila here’s the output.

A list of folders

You can use Nunjucks natively (or Liquid, Markdown, Moustache, Handlebars and more). Passing front matter into the markdown files allows for page / folder specific variables.

Anyhoo, after converting a couple of my sites to 11ty and both with data defined locally I wanted to try out something I’ve been meaning to do for a while….headless WordPress 💪.

And where better (and safer) to start than this blog as the source data.

There was a bit faffing about but I took a lot of inspiration from these articles / repos: How to use 11ty with Headless WordPress and deploy to Netlify, WordPress & Eleventy part one: WordPress, 11ty-wordpress-graphql.

So I now have a mirror site for this blog all built in 11ty.

I’ve blocked search engines from indexing it obvs. I tried to have the smallest footprint for it as well, so no client-side JS, 26KB of CSS. I even used some Tailwind (don’t generally like it, too many class names for this ageing brain) but I really liked this approach to typography. Just using the classname ‘prose’ on the container. Nice. I eschewed my goto build using Gulp and just do it all the build with npm built-in scripts.

I would like to trigger a build of the site when I hit publish on a post from WordPress, but given I post about once a decade running npm run build and git add commit push is not exactly a big deal.

Update: I rebuilt the 11ty instance and now this post, in a sort of hall of mirrors type afair, exists on the 11ty instance. 👻👻👻

2023 2022 2021 2020 2019 2017 2016 2014 2013 2012 2011 2010 2009 2008 2007 2006 2005 2004