Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Align page edit features in Site Editor and Post Editor #52632

Closed
24 tasks done
jameskoster opened this issue Jul 14, 2023 · 31 comments
Closed
24 tasks done

Align page edit features in Site Editor and Post Editor #52632

jameskoster opened this issue Jul 14, 2023 · 31 comments
Labels
[Feature] Site Editor Related to the overarching Site Editor (formerly "full site editing") Needs Design Needs design efforts. [Type] Enhancement A suggestion for improvement. [Type] Tracking Issue Tactical breakdown of efforts across the codebase and/or tied to Overview issues.

Comments

@jameskoster
Copy link
Contributor

jameskoster commented Jul 14, 2023

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.

@jameskoster jameskoster added [Type] Enhancement A suggestion for improvement. Needs Design Needs design efforts. [Type] Tracking Issue Tactical breakdown of efforts across the codebase and/or tied to Overview issues. [Feature] Site Editor Related to the overarching Site Editor (formerly "full site editing") labels Jul 14, 2023
@youknowriad
Copy link
Contributor

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
Copy link
Contributor Author

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

@youknowriad
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

ntsekouras commented Nov 21, 2023

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
Copy link
Contributor

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

@jameskoster
Copy link
Contributor Author

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:

Screenshot 2023-11-21 at 11 59 58

@youknowriad
Copy link
Contributor

@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
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Site Editor Related to the overarching Site Editor (formerly "full site editing") Needs Design Needs design efforts. [Type] Enhancement A suggestion for improvement. [Type] Tracking Issue Tactical breakdown of efforts across the codebase and/or tied to Overview issues.
Projects
None yet
Development

No branches or pull requests

8 participants