-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Reusable block: Adding more functionality to Settings #30357
Comments
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
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.
I think this is fine :)
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? |
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.movAs 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.movThere 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.movHere’s a prototype looking at all of this together. Other notes:
|
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? |
Thanks @jameskoster, moved this discussion over to #30622 for the potential Reusable blocks and Template Parts implementation 🚀 |
re: Toolbar convert to regular block - there's an issue for that at #30993 |
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. |
Hi all, I’m looking into a couple of different issues that are currently being tracked in Improvements to Reusable Blocks #27890:
the post type management screenSettingsReusable 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)
Inspector (secondary)
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 text was updated successfully, but these errors were encountered: