Skip to content
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

Gutenberg site-wide options are stored by saving post #14396

Closed
louiswolf opened this issue Mar 12, 2019 · 8 comments
Closed

Gutenberg site-wide options are stored by saving post #14396

louiswolf opened this issue Mar 12, 2019 · 8 comments
Labels
Needs Dev Ready for, and needs developer efforts [Type] Enhancement A suggestion for improvement.

Comments

@louiswolf
Copy link

Gutenberg options behave unexpectedly from the user perspective: you can disable various 'panels' and save these settings by saving the post. However, these options are not specific to that post, but change behavior throughout the website.

In my opinion there are three 'solutions':

  • The Gutenberg options dialog should have it's own save-button
  • The Gutenberg site-wide options should be moved to their own settings page
  • These Gutenberg site-wide options should be part of the writing settings page.

gutenberg-options

@noisysocks noisysocks added [Type] Enhancement A suggestion for improvement. Needs Design Feedback Needs general design feedback. User Experience (UX) labels Mar 13, 2019
@youknowriad
Copy link
Contributor

Noting that these are not saved when you save the post, these are saved as soon as you change them.

@louiswolf
Copy link
Author

Ah, interesting. In that case I think this would already be greatly improved with some visual feedback like a spinner and/or message on top of the dialog.

@kjellr
Copy link
Contributor

kjellr commented Mar 19, 2019

This seems a bit analogous to the "Screen Options" settings in the classic editor:

Screen Shot 2019-03-19 at 2 45 22 PM

Those did not include a save button either. My gut says that it's okay to leave this as is, but I'm curious what others think. @mapk and I have been chatting a bit about the function of checkboxes in the Block Manager modal too, so looping him in here too.

@mapk
Copy link
Contributor

mapk commented Mar 19, 2019

Thanks for looping me in, @kjellr! I don't mind where these options exist right now, but the feedback to the user is something that still bothers me a bit.

Can we look into providing textual feedback to the user that the checkbox state has been saved? Something like below:

options

The timing of the msg and fading is all off, but should provide something to talk about here.

@kjellr
Copy link
Contributor

kjellr commented Mar 20, 2019

👍 That could be cool! I'd be up for trying that.

@karmatosed
Copy link
Member

I am removing the 'User Experience (UX)' label as part of a label cleanup. It's not being used anymore consistently so let's try and keep to 'needs design' and 'needs design feedback'. If we find a need for another label we can consider it but having those 2 should cover this.

@karmatosed karmatosed removed the Needs Design Feedback Needs general design feedback. label Oct 15, 2019
@joyously
Copy link

I prefer the previous Screen Options interface, as it lets me see the changes as I make them, whereas the overlay hides things I'm changing.

@mapk mapk added the Needs Dev Ready for, and needs developer efforts label Oct 16, 2019
@skorasaurus
Copy link
Member

skorasaurus commented Dec 15, 2023

I can confirm that this behavior no longer exists; site-wide options (now known as preferences) save immediately after toggling them. (there is no notice that the changes have been saved however).

Please reopen if you are still experiencing this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs Dev Ready for, and needs developer efforts [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

No branches or pull requests

8 participants