Site Editing: Restrict block editing capabilities based on editing context

[jameskoster]

In site editing, we will soon have a need for blocks to be aware of the context in which they are being edited, and their capabilities restricted accordingly. IE:

• Whilst editing a template, it should not be possible to directly edit the content of a post
• Whilst editing a post and viewing the template (Post editor: Provide a way to view the template while editing a post #27847), it should not be possible to directly edit the Header

On a per-block basis this will help to indicate whether the scope of the selected entity is local to the current document, or global.

There are two parts to this issue on the design side:

1. In the scenarios above, we'll need a UI pattern to indicate how the blocks are restricted (perhaps a scrim/overlay on content, faded-out Toolbar icons, etc).
2. It should be possible switch between editing the content and the template, intentionally bypassing the restrictions ad hoc.

Additional bonus part: Visual distinction for template parts due to the unique position they occupy in all of this.

---

This is quite complicated, but closely related to the above, so I'm adding it here for now and acknowledging that it may need to be split out in to a separate issue:

Different properties of the same block may need to be governed by different contexts. For example the alignment of the Featured Image block should be governed by the template, but the URL to the featured image should be governed by the post. It should also be possible in some cases for posts to "override" template-governed properties without needing to spawn an entirely new template, although that should also be possible when desired.

[jameskoster]

Here's an initial take on this:

content.template.mp4

The idea here is to display all block controls while editing content, but apply some kind of "disabled" visual treatment to them. Adjusting the opacity is probably easiest, but there are most likely other options to explore as this may not be accessible enough (color contrast). I'm keen to get the flow right initially and focus on these finer details later.

You can navigate directly to the tempalte via the ellipsis menu on the block.

Alternatively, clicking any "disabled" control will open a dialog asking the user if they'd like to edit the template, and briefly reminding them of the implications of doing so.

The transition to template editing view is made clear via the UI changes proposed in #27849 (IE the inverted top bar). Let's not dwell on that in this issue.

In template editing view the previously "disabled" controls are now enabled and you can make any changes you need to. However, the contents of the block ("Hello World!") is locked since we are now editing the template. To get back to editing the content you can click the "← Return to post" link, or simply double click on the text.

Any changes to either the post or the template will be surfaced in the multi-entity save flow.

[jameskoster]

I shared this concept in the show and tell for January and got some excellent feedback. Noting here:

• Overall flow felt OK
• The "disabled" controls negatively reminded folks of "pay to unlock" design patterns
• Suggested to explore an opposite approach – instead of displaying all controls just show a single "edit" button that would take the user directly to the edit template view
• What if we let people edit the template in the post editor and asked them on-save if they'd like to push their changes to the "master template" or keep them local to the current document (IE spawn a new, more specific template)?
• Inverted toolbar in template editing view is possibly overkill

[jameskoster]

Suggested to explore an opposite approach – instead of displaying all controls just show a single "edit" button that would take the user directly to the edit template view

Here's a take on that approach:

content.template.mp4

I think it works quite well. The main trade-off for the cleaner UI is that I have to enter template editing mode to understand which block options are available.

---

What if we let people edit the template in the post editor and asked them on-save if they'd like to push their changes to the "master template" or keep them local to the current document (IE spawn a new, more specific template)?

Here's a take on this one:

update.template.mp4

In this concept the user is able to manipulate all the template blocks while editing content, but receives immediate visual feedback when they do so in the form of a notice. The notice text informs them that they've edited the template and outlines the subsequent implications. From there the user can choose to update the template (dismiss the notice), create a new template for the content they're editing, or perhaps even revert any template changes.

The option they select would basically update the radio control we intend to present in the dedicated template editing view.

I like how unobtrusive this option is – the user can action the Notice in their own time, or even ignore it altogether. The drawback is that after the initial template edit – when the notice appears – subsequent templates edits are obfuscated.

[ridesirat]

I like the 2 approaches. What about a mix?
Since the majority of the times we would won't to edit the template too, there could be a "T" button/icon here (image bellow), allowing to change the block template. If pressed the block menu bar would become black.
We wouldn't need to be confirming all the time. Just edit. If white it's only that one, black the template.
If any changes to the template, a "Preview" black button would appear near the "Save". If pressed, all the changed blocks could be highlighted with their black menu bar. We could revert any block with a back button (replaced "T", for instance).
And finally hit "Save" - which become black too if any changes to the template were made.
This could be explained in a first visit. But I think it's quite intuitive.

(sorry for the hand drawn, I hope it's understandable)

[jameskoster]

Hmm, are you suggesting to transform to template editing on a block-by-block basis? I think that could be interesting to explore, but feels like potentially a 'v2' enhancement type of thing.

Dedicated template / content editing views would still be required, so a per-block control feels like an additional layer of complexity on top of that.

[paaljoachim]

I went ahead and suggested a Page/Post <-> Template switcher here:
#27849 (comment)
(Perhaps not the correct place to add it. I can of course move the comment.)

[jameskoster]

This may require a separate issue but I'll note it here for now...

Some pages or templates might contain blocks that should be locked down in some way:

• The Page for Posts should contain a query that cannot be removed.
• The Query block should be mandatory on the Archive, Category, Tag, etc, templates
• The Post Content block should be mandatory on the Single, Singular, Post, etc, template
• The Index template should include mandatory blocks that are respective the Home Page and Page for Posts settings

[jameskoster]

If we use the Reusable Block patterns for Template Parts (as suggested here) that solves the Template Part portion of this issue.

Due to the flexibility of these patterns, I think we can use them for content editing as well.

If I am editing a template and content from a specific post has been loaded in, we can apply the same treatment to the Post Content block:

• Click-through overlay
• Save button on the toolbar
• Snackbar on save
• Dots to indicate unsaved changes

[youknowriad]

I feel this is solved with the new "template" and "page" modes in the site editor? Anything missing?

[jameskoster]

Yes 🚀