🐉 Full Site Editing: Editor interface prototype [13] 🐲

[vindl]

The purpose of this task is to conduct an exploration of possible technical approaches for "editor-in-editor" interface. For start, it should allow us to edit the site header and post_content in one interface. This doesn’t need to be seamless at this stage. An explicit save interaction like we have for saving reusable blocks within the a parent post is allowed.

For reference, see this reusable blocks related core exploration: WordPress/gutenberg#14715

Note: it's fine if multiple squad members start researching this in parallel - we want to gather as much different ideas as possible initially.

[mattwiebe]

Some questions:

1. Are we going to try to make this work in the context of our plugin or should we prototype in a fork of the Gutenberg plugin itself?
2. Are we aiming for editing the post within the context of its template here or is that more complex than we're prototyping here?
3. The MVP already allowed us to "edit the site header and post_content in one interface" but I don't think this is what we're after here. I guess that one constraint here is to not have the header saved into post_content?

[rodrigoi]

1. Are we going to try to make this work in the context of our plugin or should we prototype in a fork of the Gutenberg plugin itself?

I think that this should work on the context of the plugin (and the template blocks). Using a fork will add a maintenance overhead we are striving to avoid. We can always contribute back to core if we need to expand the API surface of the blocks API.

2. Are we aiming for editing the post within the context of its template here or is that more complex than we're prototyping here?

I think we do, yes. I was thinking of using the post_content filter here to add the template when we edit a post type and the FSE plugin is active, and the blank theme is selected. But I'm still figuring if some limitation with the way we load plugins for API calls will affect us.

3. The MVP already allowed us to "edit the site header and post_content in one interface" but I don't think this is what we're after here. I guess that one constraint here is to not have the header saved into post_content?

This is correct. When we save the post, we should only save the actual post content. And when we modify the template part, we should only save that. I'm exploring some options to work around the block API to have this effect.

[mattwiebe]

I think that this should work on the context of the plugin

Seems fine to me.

When we save the post, we should only save the actual post content. And when we modify the template part, we should only save that.

Yup - I think this will be difficult without some core modifications but I guess that's why we're doing this. :)

I was thinking of using the post_content filter here to add the template when we edit a post type and the FSE plugin is active, and the blank theme is selected. But I'm still figuring if some limitation with the way we load plugins for API calls will affect us.

Hmm, interesting approach. The MVP did some filtering stuff via the API and it worked fine, FYI.

[vindl]

Are we going to try to make this work in the context of our plugin or should we prototype in a fork of the Gutenberg plugin itself?

The more we can work out in the context of the plugin - the better. Although I would be surprised if it didn't require some core adjustments in the end. Working with Gutenberg docker setup might be helpful for this (and volume mapping for the plugin), because you'll be able to introduce ad-hoc changes to the core editor code.

Are we aiming for editing the post within the context of its template here or is that more complex than we're prototyping here?

Ideally - yes, we should be able to edit both the template parts (e.g. header, footer) and the actual post content in the same view. If that turns out to be too hard, I think an acceptable scoped-down solution might be to just show the template parts grayed out (visible, but not editable in the same screen), and allow easy switching to template editing view. I'm also open to other proposals for scoping this problem down.

The MVP already allowed us to "edit the site header and post_content in one interface" but I don't think this is what we're after here. I guess that one constraint here is to not have the header saved into post_content?

That's right, I think the header should be saved into associated wp_template in the background.

[vindl]

Some points raised in this discussion are also relevant paAmJe-mS-p2. If possible, template parts should only be editable in the page editing view, and not accessible directly.

[apeatling]

To highlight a recent discussion, for the first editor interface interactions a unified save button I think is perfectly acceptable (just like the MVP and figma) assuming you can hook in and save everything in the correct place.

[dmsnell]

1. Are we going to try to make this work in the context of our plugin or should we prototype in a fork of the Gutenberg plugin itself?
2. Are we aiming for editing the post within the context of its template here or is that more complex than we're prototyping here?
   I was thinking of using the post_content filter here to add the template when we edit a post type and the FSE plugin is active, and the blank theme is selected.

If we make the blank theme a prerequisite we should be able to always load the plugin and only start interacting iff the blank theme is the selected them. Also the more we stay focused on a plugin without core modifications the easier it will be to harmonize across Calypso, Jetpack, and Atomic.

3. The MVP already allowed us to "edit the site header and post_content in one interface" but I don't think this is what we're after here. I guess that one constraint here is to not have the header saved into post_content?

We should eliminate any solution which stores layout content/headers/footers inside of post_content. We should be able to switch themes and hav the page work as expected and we should be able to perform an export/import and get a reasonable site. We shouldn't depend on any Automattic-specific API plugins to strip lingering content.

---

researching this in parallel

One of the unknowns I think about is how we present editing the theme pieces. The current design mockups don't offer much in terms of editing the theme outside of a given page which somewhat limits the scope but we know we'll need to build that out eventually so we want to at least make sure we have a plan for how to handle the more dynamic parts of the template hierarchy.

How much of the hierarchy do we carry forth?
How much do we present those details to the customer?
How do we constrain that choice for the designed page builder while working within that model?
How much do we do in JS vs in PHP?

[vindl]

To highlight a recent discussion, for the first editor interface interactions a unified save button I think is perfectly acceptable (just like the MVP and figma) assuming you can hook in and save everything in the correct place.

@apeatling if I understood correctly this is most likely going to be our ideal flow for the long-term solution too? It's also the one that will be hardest to get right technically (highest number of unknowns at this point).

[apeatling]

@apeatling if I understood correctly this is most likely going to be our ideal flow for the long-term solution too? It's also the one that will be hardest to get right technically (highest number of unknowns at this point).

What other solutions have you investigated so far? The figma shows this as the long term solution also. Is any of @mattwiebe's work to hook into the save action reusable here?

[mattwiebe]

Hooking into the save action isn't too hard. The SettingsHelper component in the MVP just listens to isSavingPost and isAutoSavingPost from the core/editor store to fire off its own save events.

[vindl]

What other solutions have you investigated so far? The figma shows this as the long term solution also.

Only that one as part of this issue. During previous prototypes we used editing of templates and content in separate screens (which seemed like a good stepping stone). It just sounded like this solution was perceived as a scoped-down one, while I think of it as a full-fledged one.

[apeatling]

Is there anything to look at on this yet?

[vindl]

Is there anything to look at on this yet?

@rodrigoi is going to publish a P2 post with some preliminary explorations so we can get the discussion started as soon as possible (@mattwiebe feel free to add your explorations to it).

I think it would be valuable to outline both the approaches that seemed viable, and the ones that proved to be a dead-end for some reason.

[rodrigoi]

Let's bring the discussion over to paAmJe-p3-p2

[vindl]

@rodrigoi Now that the post is up, I think we can close out this issue once more specific subtasks for it are created.

[vindl]

After some comments on the exploration post, I'm reopening this issue so we can conduct an exploration of an alternative approach proposed in paAmJe-p3-p2 (#comment-1013).

[vindl]

After some thought, I think that the follow-up issues that @rodrigo created are generic enough to allow for investigation that assumes the second approach too. Let's continue the work in them instead:

• Full Site Editing: Merge Template and Post Content #33394 - Merge Template and Post Content
• Full Site Editing: Edit Template and Content [?] #33395 - Edit Template and Content
• Full Site Editing: Preserve changes on Template Parts and Post Content #33396 - Preserve changes on Template Parts and Post Content

For reference, you can also check out the initial exploration in this PR: #33325 and in paAmJe-p3-p2.

[apeatling]

Could the above three issues be broken down further? They are still big with scoping explained at a high level.

Team AJAX are doing a great job at breaking their work down into really small chunks (once they know what they chunks need to be) and its helped them distribute work more easily as a team. /cc @vindl

[mtias]

The key technical part for this puzzle is that you need to elaborate your own editor from the pieces core provides, including a separate EditorProvider for the post content area. It is exactly Gutenberg's intention that you can create your own editors. This is the only way I imagine you can do this cleanly and reliably. Is this something you have looked at and decided was not feasible?

I'd then focus on 3 sub-milestones:

• An editor provider with two blocks, the page_title and the post_content. The content is handled within its own editor provider. This is the simplest possible augmented editor.
• Expand the editor provider above to read from a wp_template composed of header, page title, content, footer.
• Allow editing all the elements specified by the template and the content in their respective providers.

More in detail...

SM1

Your Own Editor

• Create your own editor that represents the page title as a block (is not saved in post_content) and the content is passed to another inner block with its own editor provider. (Inspiration).

To handle this you'll need a custom template supplied to your root provider that has a page title and content blocks. I'd start with a locked template so that ordering cannot be changed (title cannot go under content).

SM2

Template Definition

• Create a simple template in wp_templates that has header, page (page title, content), footer.
• Use this definition to serve pages instead of the theme provided page.php.

Header and footer have only static content as defined in the wp_template.

Editor Display

• If the theme can handle wp_templates, take over editor intialization expanding on M1 groundwork.
• • Title is already present as specified by the template. No longer a hard-coded field but a "post title" block.
• • An inner editor provider is initialized with the post ID for post_content block.
• • Header and Footer are areas defined in wp_template and rendered in the top level provider.
• Header and Footer are not editable, only displayed.

SM3

Edit Flow

• With the page broken down in two providers (template, and page content), work on saving flows:
• • When focusing on "post_content" blocks, all the editor chrome shifts to be post oriented (publish, etc).
• • When focusing on "header" or "footer", the editor chrome switches to be template oriented (update template, etc). (Blocks like "site title" created by Serenity would use this action to update.)

At this stage, all the ingredients should be in place to iterate on what the ideal editing UX is when working on one area or the other without technical blockers.