One of the most challenging elements to get right in the site editing UX is where and how we draw lines between the different editing contexts.

Until now, no lines have been drawn at all. In both the Site Editor and the Template Editor, if you’re able to see content, you can edit it directly, free of any friction whatsoever. Of course there are benefits to this – direct manipulation is a compelling argument. But as documents become more complex, and template editing more prevalent, drawbacks emerge.

In the go/no go discussion (re FSE in 5.8) last month the Query block came under scrutiny:

I think, also, to be honest, this is a bit too powerful right now. You can essentially modify any of your post’s actual content, feature images, and so on. This should probably not be the default. It should probably be something that you have, like, one more step to get there.

Matías Ventura

The same argument can be made in regards to template editing. Being able to edit the content of a post while also editing the post template blurs the lines between these two very different exercises, and undermines the very existence of separate content and template editors in the first place.

The issue is compounded when you consider the query block. Imagine inserting a Query in a page, then navigating to edit the Page template. Suddenly it’s possible not only to edit the content of every single post on your site in the context of a template editing session, but also to mistakenly drop that query in to the page template itself and potentially break the appearance of your whole site. Similar problems will surface when it becomes possible to edit templates for archives and search results.

You may argue that an experienced user would not make these kind of mistakes, and for the most part I agree. But with the template editing UI coming to 5.8 it will not only be experienced users who have access to this powerful feature.

It is my opinion that we should test some prototypes that add friction to content editing exercises that are outside the context of the current exercise. That is to say: if I open a page and engage the template editor, I should not be able to directly manipulate the content of that page. Likewise, when I insert a query in a post, I should not be able to directly manipulate the content therein.

You can probably guess what is coming at this point… 🙂 Yesterday I opened a draft pull request that serves as a proof of concept. It is very rough, but with some css hackery I was able to spoof making post block content un-editable in the template editor. Here’s a video:

Blocks like the Post Title, Post Content, Post Date etc can be selected, and their attributes can be modified. But their actual content is gated by an overlay UI similar to the one we’re exploring for template parts and reusable blocks.

It doesn’t feature in the PR, but it is quite easy to imagine some simple interactions that “unlock” edit-ability of the content. It might be a double-click, a keyboard modifier, a lock icon in the block toolbar, or a combination thereof.

The objective here is primarily to establish clear definition between content editing and template editing. I’m increasingly of the opinion that this will be a critical pillar of the UX if we’re to pursue dedicated views for these different editing contexts.