-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Edit: Redo save feature for Reusable blocks. #28931
Comments
Just renaming as 'save function' will be confusing for devs who think it's related to the JavaScript function |
I agree that it should be less easy to accidentally edit reusable blocks. I switched off the Gutenberg plugin when seamless reusable blocks were introduced, trusting that it would be revised before making it to core. Right now I think it's not obvious at all what is happening when you edit a reusable block. This change feels like a step in the wrong direction. |
It's good to see this issue is being thought about/discussed. Just a thought: besides some of the UI improvements being considered here, could there be some role-restriction for seamless editing of reusable blocks? If nothing else, it would be great to have some way to prevent reusable blocks from getting inadvertently edited because someone accidentally dragged/dropped something in or out of there. On this page, someone posted some CSS that used pointer-events: none to try to prevent everyone from doing seamless editing, but now with Wordpress 5.9 having the ability to drag/drop into the List view, this once again opens up the possibility that things get inserted into or moved out of the reusable block (and I haven't yet been able to identify a way to target these and prevent this with a similar approach). Even something as simple as requiring the click of an 'Edit' button before making any changes to a reusable block could go a long way. I'm not a fan of the checkbox under "Are you ready to save?" that you get if you seamlessly edit a reusable block and then try to update the page. A save button that's much closer visually to the reusable block being updated would help I think (especially if it appears as soon as you've made some change - a visual cue). |
I have EDITED (Saturday 20 Feb) the below information.
Description
From what I noticed the following method is also being added to WordPress 5.7. I would recommend to either revert this change or make the process of saving a reusable block far easier than this new method.
It is too easy to make a change inside a Reusable block, and then remove the change and still see the dot beside the Publish button. One will have to resave the Reusable block as part of the publishing process to be able to publish the page.
Step-by-step reproduction instructions
The difficult UX part here is the mixing of saving a change to a reusable block into the Publish procedure of the page/post.
Expected behaviour
I did not expect a dot in the Publish button.
I did expect a way to easily save the change to the Reusable block, and if I did not want to save the
change being able to easily publish and disregard the change.
Actual behaviour
Not able to easily publish page.
Stuck on a Publish and Save screen.
Screenshots or screen recording (optional)
It becomes harder to publish a page/post that includes a save to an adjusted reusable block.
Reusable-block-publish.mp4
Making it easier to save a change to a reusable block.
Keep things separate.
When adjusting the block(s) information inside a Reusable block it needs to be simple to save the change.
A few suggestions:
Adding a save button closer to the Reusable block. (Not making it a part of the Publish page process.)
Adding a Save and cancel button in the toolbar settings.
Adding a Save button directly to the toolbar which shows up when a change has happened.
The above solutions would bring back a save process that is associated directly to the Reusable block.
Another method would be to disregard changes in the reusable block directly in the Publish/Save screen.
@bph @youknowriad
Improvements to Reusable block tracking issue:
#27890
The text was updated successfully, but these errors were encountered: