Align page edit features in Site Editor and Post Editor

[jameskoster]

There are a number of smaller edit actions that are available in the post editor, but not the site editor. The mis-alignment means users sometimes need to hop between editors, which can be frustrating.

In addition to the Page Inspector, we should consider the new details panel, and the Command Palette when working out the placement for these items.

• Access to revisions: Site Editor → Page Details: Link 'Last modified' detail to revisions #51343
• Switch page template: Site Editor → Page Inspector: Add ability to switch templates #51347
• Create new template while editing the page.
• Add control for renaming a page in the Site Editor #52763
• Make pages trash-able in the full screen editor.
• Include discussion settings / detail for pages in site editor #53188
• Page attributes (parent page, order).
• Edit slug.
• Change Author.
• Unify preferences
  • right click override Editor: Unify right click override preference #57468
  • top toolbar Editor: Unify the top toolbar preference #57531
  • spotlight mode Editor: Unify spotlight mode preference #57533
  • whether the list view opens by default Editor: Unify list view open preference #57504
  • show/hide block breadcrumbs Editor: Unify the show block breadcrumbs preference #57506
  • distraction free Editor: Unify the distraction free preference #57590
  • which panels to show on the sidebar Editor: Migrate and unify the panel preferences #57529
  • showing button text labels Editor: Unify show icon labels preference #57480
  • constrain text cursor Editor: Unify context text cursor preference #57479
  • show most used blocks in the inserter Editor: Add the show most used blocks preference to the site editor #57637
  • block visibility Unify the preferences modal UI between post and site editor #57639
  • default editor (code/visual) Editor: Unify the Editor Mode preference. #57642
• Unify commands.
• Unify publishing flow Unify publishing flow between post and site editor #59878

[youknowriad]

Hello folks, so I've been thinking a little bit about it and shared some comments here #55844 (comment)

I think we've been going about this in the wrong way. We're duplicating more and more components while we could unify both post editor and site editor to use the same code and share components through the existing @wordpress/editor package and ultimately just use the exact same "editor" entirely.

I'm going to start working on some of this and my plan is the following:

• Use the EditorProvider in the site editor (to set the correct postType/postId...)
• Move the UI components one by one from the site editor to the @wordpress/editor package. (which might allow us to remove duplicated components)
• Move the shell of the editor (probably the most complex task) as it requires thinking about extensibilty/preferences...
• Final step: Once all UI components have moved, remove the duplicated state from the site-editor and store and proxy the selectors/actions.

[jameskoster]

Should we close this issue and work on refining the document inspector design in the post editor instead?

[youknowriad]

I think we should keep this open, we can use it to track that work. IT's going to be a bit of a ride but let's see how it goes. We can consider this one some kind of overview for this unification.

[youknowriad]

What about the other way around:

• The different "template" modes are different between the post and site editor, should we have the exact same way to show pages, lock them, switch to template... in the post editor as well ?

[youknowriad]

There's something that also needs design thinking: the way to publish / mark things as private / pending ... differ between both editors, how to align there?

[ntsekouras]

There's something that also needs design thinking: the way to publish / mark things as private / pending ... differ between both editors, how to align there?

It seems to be buggy too(maybe a regression happened at some point). In post editor you have limited statuses available, which can result for example, not being able to make a page a draft again. Unless I'm missing some other UI...

[youknowriad]

@ntsekouras there's a "revert to draft" button that appears in the sidebar for this.

[jameskoster]

Ideally the entire panel needs some design attention, but that's a larger effort.

For status my preference would be the site editor implementation where it is clearly communicated including the private option. It eliminates the need for the clunky "Revert to draft" button, and feels more aligned with the pages data view work.

Same for the template dropdown, especially as it makes the swap flow more visual. We'll need to add the missing "New template" action though:

[youknowriad]

@jasmussen @SaxonF @jameskoster A few questions about aligning the "template mode" of the post editor with the site editor.

• In the site editor we have three modes: template visible but disabled with post, template editable without post, post only (no template). Also the default mode is "template visible but disabled with post"
• In the post editor, we have two modes: post only and template+post both visible and editable. Also default mode is "post-only"

We need to make decisions about how to align these two flows. The UI @jameskoster shared above is a first step which for me means:

• The post editor gets the "template editable without post" mode and drops the "template+post both editable at the same time".
• The post editor gets the "preview template" option to allow "template visible + post and template readonly".

The last remaining question is:

What do we do with the "default mode". Should that be something configurable?

• I think for posts and maybe most CPTs, it's clear that it should probably remain "post-only" in the post editor.
• What do we do for pages? Do we follow the site editor (template visible but locked by default) or do we keep "post-only" mode as default too in this case.

The other hidden question here is:

The site editor is going to get post and CPT editing capabilities at some point as well. So it should probably also be "post-only" by default for posts there. My thinking is that post editors and site editors should probably have the same behavior for all CPTs and that potentially whether "preview" is enable or not initially could be a CPT config.

[youknowriad]

The idea for me is to have the same thing, what's that "thing" is up to you and the rest of the designers :P

[jameskoster]

The big red button in the post editor is perhaps a bit too prominent. It will likely be removed in favor of the menu item as a part of #59689.

[youknowriad]

I think with the Editor component introduced in #62274 and expanded into the post editor in #62339 we can consider this project complete. There are some small things that we can still improve/unify but the biggest part is done. Both post and site editor are using the same code and same UI for all post types.