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