Full Site Editing Design

[epiqueras]

( state ) 📔

Per the Roadmap (#15068) and our current phase's, phase 2, scope (#13113), lots of work is being done to bring full site editing into Gutenberg.

A lot of the foundational work for Defining Content Block Areas, has been merged or is in progress (see Label: Full-Site Editing) and can be tested by enabling the Full Site Editing experiment in the Gutenberg => Experiments page.

Now we are at a point in which development work is slowing down due to hard to answer design questions that we need to discuss.

const questions = [...] ❓

Here are the general questions we need to answer.

How do we present block template selection and navigation?

As explained in #17512, block templates are the block equivalent of theme template PHP files. They will have higher priority in the template hierarchy and will be editable by users. This question will be one of the toughest to answer. For example, I envision having some sort of view or overlay in the editor, that can even be accessed prior to selecting an actual post to edit, that shows the user their templates:

Such a view or overlay would allow users to answer the following questions:

• What templates are being provided by my active theme?
• What templates are customized by me and what themes did I originally fork them from if any?
• What templates am I missing that I could create and how do I create them?
• How do I fork a template into a higher granularity template, e.g. Category => X Category or Post => X Post Type.
• If I am editing a post, which of my templates will it load into and how do I preview and/or edit it in each?
• If I am editing a post, how do I assign a fixed template to it?

How do we connect the navigation block to the templates?

The navigation block needs to integrate with template selection and navigation. Potentially, clicking on a link could take you to edit the template/page it links to, maybe even in the same editor, on a new tab. Think of it like the back end equivalent of front end site navigation.

How do we expose blocks used for template building (Template Parts, Site Title, Post Title, Post Content, etc)?

These blocks are different from any we already have in the block inserter.

• Is a new category in the block inserter enough?
• What should be the name of this category?
• When should the category be exposed?
• Can the inserter be smart about automatically adding any of these blocks in given situations? For comparison, this is what happens in the navigation block.

How do we present placeholders for post blocks when no individual post or page is loaded?

This won't just be needed for editing singular page templates; for example, when editing an archive page, we'll be adding a combination of fixed post blocks, which render specific posts, and query/posts blocks which each render a list of posts, using the layout of its block children as a template. Part of these block children will be post blocks that need to show placeholder content in this editing context.

How do we orchestrate the change/save flow of multiple entities in the same editing context?

When doing things like editing a post within a template.

• How do we show whether the post is dirty, the template is dirty, or both? Block outlines?
• When does it make sense to have block-specific save buttons instead of unifying saving with things like checkboxes for each entity and its changed properties?

const answers = questions.map(...) ✅

Here are the questions and the issues/PRs in which they have been or are being answered:

• How do we present block template selection and navigation? [#]
• How do we connect the navigation block to the templates? [#]
• How do we expose blocks used for template building? [#]
• How do we present placeholders for post blocks when no individual post or page is loaded? [#]
• How do we orchestrate the change/save flow of multiple entities in the same editing context? [Explore Multi-Entity Saving #18029]

[pagelab]

I envision having some sort of view or overlay in the editor, that can even be accessed prior to selecting an actual post to edit, that shows the user their templates.

Maybe this should be treated simply like the block navigation panel:

This would allow a quick look at key information about the templates. An overlay or edit screen with specific details about the template would open only after clicking the template link in the overview.

[scruffian]

Is a new category in the block inserter enough? What should be the name of this category?

What about "Site blocks"?

[Addison-Stavlo]

I think @pagelab's idea fits well for showing the heirachy and blocks that will be inserted. But I think having some sort of visual preview to what will be inserted will help greatly for browsing. Perhaps an overlay that shows the preview image and block composition pattern/heirarchy would be the way to go?

What templates are being provided by my active theme?

I like to imagine the overlay you mention would be search/filter-able so a user could browse by different means. They could search "homepage" block templates of all themes they have imported, search all Block Templates of a specific theme (or active theme), or some combination of criteria. This way, it would be easy for a user to mix & match Block Templates from across the wide variety that will exist between different Themes in whichever way is most meaningful to them at the time.

What templates are customized by me and what themes did I originally fork them from if any?
What templates am I missing that I could create and how do I create them?

Perhaps the way to handle this to have an option of any block containing children to be saved as a 'custom' Block Template. Whether made by building blocks individually from the ground up or by inserting a Block Template from a theme and further customizing, they could then click the parent Block somewhere to give the option "Save custom block template." The custom template could have 2 values such as category and theme, where category could be a value like "homepage" or "social" and theme would default to "custom" (or even "$themeName-custom" if it had originated from a specific theme), allowing them to be easily found in the above search/filter idea.

How do we connect the navigation block to the templates?

I do like the idea of it linking to that page to edit and loading it within the same editor. But how do we signify that clicking that button will take them to another section of the editor without adding something visible that will be inconsistent from the front-end? Perhaps we add a confirmation modal (or small popup link on mouseover to "edit this page") instead for the link inside the editor, so it doesn't load a different page to edit on someone who was just trying to select or edit the nav block itself.

[paaljoachim]

Is this issue still valid?