Reusable block: Adding more functionality to Settings

[critterverse]

Hi all, I’m looking into a couple of different issues that are currently being tracked in Improvements to Reusable Blocks #27890:

• Ensure post revisions are enabled for reusable blocks Revisions missing for reusable blocks #19149
• Allow users to see and navigate to posts using a given Reusable blocks from the post type management screen Settings
• Allow deleting a reusable block from the inspector Allow deleting a reusable block from the inspector #28355

Reusable blocks are both a post type and a type of block. Typically, the options for each are separated in the Settings sidebar via a content/theme type tab (left) and a block tab (right). The functionality proposed in the above issues (Revisions, “Move to trash”) is usually shown when viewing options for a content/theme type, such as a Post or a Template.

Note that theme elements like Templates and Template Parts currently show these options when accessed via the management screen in wp-admin, however not when accessed from the FSE navigation.

A common thread is the "Status & visibility" panel but those options feel sort of confusing in the context of Reusable blocks (and possibly Template Parts). I wonder if there could be a different panel shown in these instances that emphasizes the custom name field and other locations of the given block (and other options if needed):

advanced-panel.mov

The existing tab logic in the Settings sidebar works well within a proposed isolated editing view, where the Reusable block can be viewed as a content/theme type:

It gets a little weird when the Reusable block is viewed in its regular context as a block — but maybe RB's are a special case in which panels usually related to a content/theme type (like Revisions) also appear as block inspector panels.

In that case, the division/hierarchy between primary and secondary tools when editing a Reusable block could be:

Toolbar (primary)

• Transform to
• Convert to regular block
• Save changes (see Show save button in the Reusable Block toolbar if there are changes #29871)
• Edit block in isolated view (ellipses menu)
• Manage Reusable blocks (ellipses menu)

Inspector (secondary)

• Advanced panel
  • Custom title
  • Location menu
  • Manage Reusable blocks
• Revisions
• Move to trash

I tried separating out the “Move to trash” item at the bottom of the inspector to see if that reads as a more universal action. Note that this would take the user to the post type management screen, where they can undo/recover items from the trash.

Here’s a Figma prototype stitching everything together.

Open questions:

• The "Move to trash" action mirrors the current behavior of deleting a content/theme element but maybe it's not necessary to take the user back to the post type management screen if there's a snackbar that allows for an immediate undo/recover from trash
• Is having links to "Manage Reusable blocks" in both the ellipses menu in the toolbar and in Settings overkill? Both are one-click removed from the default view so I included it in both locations for increased discoverability 🤔
• Thoughts on the ability to view other locations of the given block as a part of Settings vs. within the post type management screen? The thinking was that this could be another opportunity to reduce the back and forth between the editor and wp-admin.

[jameskoster]

I still don't think that converting to regular blocks is a primary action, but it's not a hill I will die on :D

maybe it's not necessary to take the user back to the post type management screen if there's a snackbar that allows for an immediate undo/recover from trash

I think the snackbar approach would feel more streamlined. Especially if you consider situations where there are unsaved changes to the document. If we were to send folks to the RB list view on trash, we'd first have to ask them if they want to save their changes. It could all get very convoluted very quickly.

Is having links to "Manage Reusable blocks" in both the ellipses menu in the toolbar and in Settings overkill?

I think this is fine :)

Thoughts on the ability to view other locations of the given block as a part of Settings vs. within the post type management screen?

Despite breaking a convention (somewhat – it's not really a setting), this doesn't feel un-natural. Then again I wonder if there's all that much value in displaying the actual entities. Are there any common flows that would lead a user from editing one post consuming the RB, to another?

Taking another step back, when is it important to know how many instances of the block exist? I'm probably missing something, but I think I'd be most interested in this when trashing the block – I'd want to know how many posts/pages will be affected. If the value is minimal then perhaps its not worth breaking the convention?

[critterverse]

I did some further exploration based on helpful feedback from @jameskoster about it being slightly weird to highlight the other locations of the given block directly from the inspector (as it’s not actually a setting).

I imagine the most common flow for the location menu would be to do a gut check across other instances to make sure that the changes you’ve made to the Reusable block in one location look ok elsewhere. Maybe a better placement for this menu is the top toolbar within the isolated editing view (typically used for template information in the FSE)?

isolated-top-toolbar.mov

As for the remaining functionality in the Settings sidebar, I tried out a fun idea that incorporates the custom name field into the block description area (for Reusable blocks and/or potentially any block with custom naming ability). Borrowing the “ellipses” treatment proposed by @javierarce in issue #29575 [comment], additional actions could be incorporated into this area via a popover menu:

rename.mov

There could potentially be multiple ways to access the live text area — by a “rename” action in the ellipses menu and by double-clicking (similar to the way custom naming works in Figma, Photoshop, etc). This could help to integrate the custom name field (which is currently kind of an outlier/doesn't appear within a panel) while tying it to other global options that appear in the popover menu.

Lastly, I looked at the “Moved to trash” snackbar approach, which seems to work well for the main editing flow. (However, I wonder if it does still make sense to send the user to the post type management screen when trashing the block from an isolated view.)

trash-snackbar.mov

Here’s a prototype looking at all of this together.

Other notes:

• I haven’t incorporated the unsaved changes flow explored in Show save button in the Reusable Block toolbar if there are changes #29871 but "Save" and “Discard changes” will likely be needed somewhere in the inspector
• In the inspector, we may want to revisit showing the ellipses persistently (not only on hover) for higher discoverability (view comment)

[jameskoster]

Putting the consumption locations in the top bar works quite well. I can see the same pattern being used while editing a template part to outline the top level templates that consume it. I wonder if the labels could use a little more clarity though?

Ellipsis and trashing seems good too. I'm just a little anxious about not having some kind of confirmation upon trash. Is it clear and obvious enough that this will affect other content?

[jameskoster]

Just driving by to add weight to the idea of putting the consumption locations in the top bar. I've been exploring something similar to indicate which items of content use the template being edited:

[critterverse]

Thanks @jameskoster, moved this discussion over to #30622 for the potential Reusable blocks and Template Parts implementation 🚀

[skorasaurus]

re: Toolbar convert to regular block - there's an issue for that at #30993

[jordesign]

Closing this issue as so much has changed in the form of Reusable Blocks/Synced Patterns that much of this seems to be resolved. With no further discussion in 2 years - any remaining issues can be opened again referencing the current state.