-
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: A suggestion for a new revision. #31163
Comments
lock unlock feature is in my opinion an absolute necessity |
I have the exact same issue @joshm33333 multiple reusable block content were deleted + content editor by accident are putting reusable blocks in reusable block because they don't know that there are editing the inside a the block. Lock/Unlock would be a good solution to prevent this |
I'm very happy to see this proposal. The Lock/unlock action seems like something that could work. Not sure the lock icon itself is 100% intuitive / would work in the long term:
I actually liked the way things looked in 5.6. It was very simple and intuitive in my opinion. So instead of adding additional actions and controls to make this work, would it be an option to acknowledge that the old way was actually spot on, and revert back to it? |
Lock/unlock can of course be switched out with a pencil/edit icon. Then at a later point the pencil could be switched out with a lock (for user role purpose). What I tried to do was take elements from 5.6 (which worked very well) and mix these in with some of the newer elements in 5.7. There is work currently happening with a click through #30156 so on initial (first) click it selects the parent and on the next click it selects the inner/child blocks, but it might not be secure enough. As it would be more secure having a pencil/edit/lock in place the user needs to on purpose to click to gain entry to editing the inner/child blocks of the Reusable block. |
I have been looking at bigger changes mentioned in this issue as well as smaller incremental changes improving the current approach we can see in the newest Gutenberg plugins. |
@paaljoachim this improvement is massive. Just to better understand the process: is this just a figma prototype that still needs to be coded? I'm trying to understand if we need to backport our sites to 5.6 or if we'll be able to use this new UX soon enough (even if it's using the Gutenberg plugin) Thanks! |
Hey @xavivars Improvements we will see in WordPress 5.8 is creating a new Reusable block a modal pops up so that we can give it a name. Another improvement on its way is a click through approach: #31109 NB! Edit: I have created a general multi entity saving UI issue here: #31456 |
Here is an issue I just made that suggests adding the lock into the toolbar. Similar to what I suggest above. Do add feedback to it. |
I am bringing over @cpsyctc comment made here: #32461 (comment) into this issue instead. I am trying to keep the general feedback in just a few issues. Thanks for the feedback, @cpsyctc Chris
That has changed in the Gutenberg plugin through this PR: #29040
I totally agree. Notice my comment here: #32464 (comment)
That is why I added this lock/unlock issue. #32461
It does sound like a bug. Do please open a new issue for this.
I agree. Comment added.
I agree. This has not fully been addressed yet. Hopefully some of these things will be addressed in Add Reusable block save button, snackbar on save and Welcome Guide |
I will suggest that people check out the video of a Save button in the Reusable block toolbar and give feedback. The PR is almost ready to be merged. |
From my point of view, the best approach would be to
To me the whole point of a reusable block is that it can be inserted into page content and the new use of the block edited without the default stored original copy of the reused block being affected by amendments made to new instances of the block. This is the natural way to think about reusable blocks: not as a single global widget but as a template for reusable block patterns. I know we now have patterns and reusable blocks but the way Gutenberg uses reusable blocks is very confusing and leads to reusable blocks being accidentally edited. Are there statistics for how widely used reusable blocks are? I bet many creators use them a few times up until they realise their edits to a reusable block overwrite all instances of that block; and how many intuitively realise reusable blocks can be converted to editable blocks after insertion into a post? The save reusable blocks dialog is nice but how many creators actually understand what this save dialog means? On the surface it looks as though everyone should understand the save/not save option but it's meaning is only obvious when you understand that reusable blocks are (currently) meant to either (a) not be edited or (b) edits to them are meant to affect all instances of the same block and (c) that reusable blocks can be converted to editable blocks (and not everyone immediately understands the difference) when edits to reusable blocks are meant to be independent of the block's template. I feel that a nice idea (reusable blocks) has been very badly implemented and many creators are blissfully unaware of its pitfalls. until they realise their 'template blocks' have been overwritten. Can we please just change the default behaviour of reusable blocks? Treat them as templates (or offer the option to do so), use the reusable blocks admin page to manage edits to reusable block templates and make all new instances (uses) of a reusable block be an editable block by default. This would save a lot of headaches and is a lot more intuitive than the current methodology. Lee |
Here is the issue which is a base from where Pull Requests are being created: There are a few PRs mentioned in the above issue. |
Wow! A lot has changed since this issue first opened. For starters, reusable blocks are now synced patterns 💥 . There's also an entirely new flow for the two that includes easy naming, improved management, and soon categories in 6.4: pattern.experience.movIn the video above, I use a synced pattern, rename it, deatch it, and create a new one with a new name. I'm going to close this out as a result since the feedback and problems here no longer match the current experience. |
Thank you Anne for showing how it will work in WordPress 6.4. As for anyone whom come across this old issue will see how things have changed. |
Inspired by Lauras video here: #29178 (comment)
-Not able to figure out how to rename a Reusable block.
I decided to create a new Reusable block prototype based on experiences from WordPress 5.6 and 5.7.
Features:
Inline toolbar block naming and Save button.
Inline toolbar lock/unlock icon to gain access to content. (Can be in relation to user roles.)
Added "Convert to regular blocks" text link to the 3 dots drop down as it can be difficult to notice the icon in the toolbar.
Unlock to edit the contents inside the Reusable block:
Unlock-to-edit-Reusable-block-contents.mp4
Unlock - edit - save.
Reusable-block-Unlock-Edit-Save.mp4
Renaming:
Rename-Reusable-block.mp4
A walk through:
New-revision-Reusable-block.mp4
Test out the Figma prototype:
https://www.figma.com/proto/iz8ZvPpaEqibwUYtHYYFbD/Click-into-Reusable-Block-toolbar?node-id=4%3A26&scaling=min-zoom&page-id=1%3A6
History:
WordPress 5.6
A-Reusable-block-WP-5-6-1.mp4
Naming and saving is done directly in toolbar.
Clicking the Edit button opens up the possibility to edit the contents inside the Reusable block.
WordPress 5.7
Renaming moved to sidebar as an secondary action.
Clicking Reusable block goes straight to editing the contents.
Saving moved to multi entity saving.
WordPress 5.8
What will we see in 5.8?
Additional inspiration:
Link UI: Add and edit links directly within the block toolbar
#23375
On Locking and TemplateLocking
#29864
Can't cancel creation of Reusable Block
#12940
Try clickthrough to edit template part children.
#30156
Show save button in the Reusable Block toolbar if there are changes
#29871 (comment)
Various Trac ticket Reusable block tickets:
https://core.trac.wordpress.org/ticket/52965
https://core.trac.wordpress.org/ticket/52779
https://core.trac.wordpress.org/ticket/52790
https://core.trac.wordpress.org/ticket/52918
The text was updated successfully, but these errors were encountered: