Site Editing: UI Parity

[mtias]

These are some of the features that are lacking in edit-site at the moment compared to regular editor.

• Add block inserter in the header.
• Undo / Redo. Add undo-redo UI to edit-site and edit-widgets #21955 @jorgefilipecosta
• Ability to toggle and dismiss Inspector.
• Full screen mode Site Editor: add Fullscreen mode #20691 Site Editor: add fullscreen close button #20989 Site Editor: add more menu and fullscreen toggle #21006 @vindl
• Spotlight mode (FSE: Add focus mode and top toolbar modes #22537 @noahtallen)
• Top toolbar (FSE: Add focus mode and top toolbar modes #22537 @noahtallen)
• Add Patterns Use the inserter panel for the edit-site screen #22413 @youknowriad
  • Show them everywhere Site Editor: patterns are not available in inserter for template parts #25915
• Add code editor @jorgefilipecosta Add: Code editor to edit site #37765
• Add Tools section
  • block manager
  • reusable blocks link (Edit Site: Add basic "tools" menu #22539 @noahtallen)
  • keyboard shortcuts (Site Editor: Add keyboard shortcut help modal #37650 @Mamaduka)
  • welcome guide
  • copy all content @jorgefilipecosta
  • help link (Edit Site: Add basic "tools" menu #22539 @noahtallen)
• Add Preview (and devices). Site Editor: add preview options component #21309 @vindl

[vindl]

Full screen and spotlight modes.

Just a note that Full screen mode was added in these PRs: #20691, #21006.

[vindl]

Device preview added in #21309.

[MichaelArestad]

Noting this here (instead of the above closed issue): I would expect parity on the more menu options shown here:

[noahtallen]

PR up for top toolbar and focus mode in #22537

[noahtallen]

Pulling a discussion out of: #22539 (comment) for more visibility. cc @youknowriad & @epiqueras

For the time being, we have accepted that duplicating some code between edit-post and edit-site is acceptable. We don't want to make an abstraction too early which doesn't make sense in the long run. However, when looking into porting the "tools" section of edit-post into edit-site, I realized there is a significant amount of code to copy over.

For two reasons, I wonder if we should not duplicate some of this stuff until we come up with a better abstraction:

• The amount of code is quite large, particularly as relates to the block manager, keyboard shortcuts, and all of the UI options. And all of this code needs to be essentially duplicated and have the same behavior. (So obviously, it makes no sense at all to duplicate it in the long run.)
• Are any of these features really important for us to have this early in development? Things like managing keyboard shortcuts and blocks are tangential to the FSE experience.

In the future, since we would need to un-duplicate it anyways, I think it would mostly just be wasted time.

This doesn't apply to everything. For example, focus mode and the block toolbar in the header are both primarily implemented in the block-editor package, so the majority of the code is reused between edit-site and edit-post anyways.

Additionally, the code editor will need to be updated to work better with multiple entities.

But some of this other stuff seems like a lot of work for not a lot of benefit at the time being.

This leads me to wonder how much of the "basic UI parity" features should be duplicated before we come up with a good abstraction. I don't think "all of them" makes sense because there would be so much to basically just copy over and hook in. And then we have two copies of everything floating around and we aren't any closer to having a better abstraction.

[epiqueras]

A @wordpress/editor-configuration or @wordpress/editor-settings package makes sense now.

[vindl]

Are any of these features really important for us to have this early in development? Things like managing keyboard shortcuts and blocks are tangential to the FSE experience.

I don't think they are that important at this stage. And I agree with you that it would be a waste of time if they are duplicated now.

[noahtallen]

This looks related: #21430

[bobbingwide]

@mtias Perhaps you could update the initial checkbox item "keyboard shortcuts" in the initial comment to reflect the fact that there have been at least two separate issues raised and closed without a fix or any sign of a plan to fix them.
I would suggest either attaching #30294, since it's still open, or re-open the closed issues until they have been fixed.

[annezazu]

I see this checked off currently:

help link (Edit Site: Add basic "tools" menu #22539 @noahtallen)

However, when I look at the experience today, I only see the option to export items but don't see a specific help option in place. Since FSE is so new, it would be advantageous to have a link to support docs built into the interface. Is this something that can be added ahead of 5.9?

[Mamaduka]

I started working on Keyboard Shortcut help modal. Unfortunately, it's a bit late for the 5.9, but we should backport it into a minor release.

[Mamaduka]

@annezazu, do we have a documentation URL for the "Help" button?

[annezazu]

This will eventually be the URL: https://wordpress.org/support/article/site-editor/ This will provide a similar experience as the Post Editor which links to https://wordpress.org/support/article/wordpress-editor/.

[carolinan]

@annezazu I'm out of the loop because of the holidays, does that mean the project agreed to keep using the term "site editor" ?
Is it still only going to be called "Editor" under appearance?

[annezazu]

It's only going to be called "Editor" under Appearance but I'm not quite sure how else to position this. If we reuse the current https://wordpress.org/support/article/wordpress-editor/ doc and add in FSE related content, it'll likely confuse many of the folks who are just using the Post Editor. The best middle ground I could provide was by creating a separate doc for the Site Editor since that matches what was done with the template editor. Open to ideas/thoughts though around how best to proceed here :) In time, I imagine all of this will turn into just the WordPress editor but, for now, we need some in between solutions. Here's the documentation tracking issue here: WordPress/Documentation-Issue-Tracker#93