Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Add option to skip PublishSidebar on publishing #9760
This PR adds a new option to skip the PublishSidebar on publishing.
How it works
The option is surfaced both in the "Tools" section within the general menu and the "Publish sidebar" itself:
This is how it looks when the option is enabled:
This is how it looks when the option is disabled:
The expected result is that the Pre-Publish panel is opened and a checkbox is shown at the bottom of it.
The expected result is that the post is published directly, without the pre-publish checks.
These can also be disabled from "Tools" section of the general sidebar. Play a bit with those checks and make sure it works as expected.
Since there's still stuff marked todo I didn't check this out and try it yet but I left some comments on the code and approach.
I wonder if it would be better to have the panel appear as a component next to the publish button rather than have the publish button switch between being a button and a panel. It seems a bit odd to place a button and have its component conditionally output one of two very separate things.
I guess if we do it often elsewhere there's precedence, but I don't recall seeing it often in the codebase and I find it a bit less of an explicit/easy-to-follow approach.
Does that make sense?
So! When I tested this out the first time, it defaulted to not-showing the pre-publish panel. I think it would be better if we made the pre-publish panel opt-out, rather than opt-in. That is, you can hide it if you want to, but by default, it's shown.
Next! Let's avoid calling it a "sidebar", since a) it's not exactly behaving as a sidebar once all our pre-publish panel changes land in #9398 and b) it's not a sidebar at all on mobile. I keep waffling on what to call it and how to phrase this, so I think it'd be good to put out a batsignal for some editorial help!
- pre-publish panel
- publish checkup
- publish confirmation
I've realised we should also probably match the checkbox behaviour—so if the checkbox is checked in the tools menu, it should also be checked in the pre-publish panel. That will involve more wording changes, and it might make sense to make it a positive ("show the panel" rather than a negative ("don't show the panel), but it could work either way, so long as we ensure their states match.
In the tools menu:
"Show publish confirmation" (positive)
or "Publish posts immediately" (negative)
And matching statements for the panel checkbox:
"Show this confirmation every time I publish a post" (positive)
or "Don't show this next time I publish a post" (negative)
These would ideally be a bit shorter if possible too.
Third, I'll make a wee CSS change here that'll fix the margins issue for this PR, even though it'll just be a band-aid until we get all the other changes introduced as well.
mmm, I've tried by clearing my browser's cache and deleting any local changes I might have and it works as an opt-in. That was the intention. Perhaps an earlier bug? Would you mind clearing your browser's cache and try again?
Updated the wording and changed the state of checkbox and tools menu item to be equal.
I'd call it "pre-publish check" and I'm thinking the clearest thing is to use to turn it on is the same language as the confirmation: "Double-check settings before publication" -- If that's too long, maybe just "Enable pre-publish checks" -- and "Prompt me to double-check settings every time I publish something."
"Enable pre-publish checks" is probably best for the toolbar given length, and it's very clear.
What about making the checkbox in the panel itself mirror this wording more directly—something along the lines of "Show this pre-publish check every time I publish" or "Always show pre-publish checks."?
Seems to be working as expected now, or at least I can't replicate anymore, so
I've tried to parse this several times and can't make heads or tails of it, but if you can clarify @tofumatt I'm happy to give feedback on the interaction pattern!
Do you refer to https://github.com/WordPress/gutenberg/pull/9760/files#diff-a6f2fb9ba2b6fbe3ad649f4c019b76deR53 right? Conditionally show a button or a toggle depending on whether the pre-publish checks are enabled or not. I'm not sure I understand your concerns. Could we perhaps move to code and see if there is a different implementation? Let's comment there.
Looks good, but when I checked it out and tested it the pre-publish panel wasn't on by default, which I'd think it should be.
I saw that eventually going to another page or something fixed it for @sarahmonster… but as I already think this could use some testing I'd like to see an E2E test that makes sure it's enabled by default on a new site and that it can be disabled before merging.
Code and experience works great though, nice job
After you learn puppeteer, it may be argued they are easy to write. I'm still undecided whether the puppeteer API is simple, though. Once written, no doubt they are very useful. Thanks for prompting me to go further, I've learned something new!
I've also taken the time to refactor the e2e code to make it concise addressing these concerns.
referenced this pull request
Sep 18, 2018
I think we need to reset the setting for pre-publish panel being disabled and I left a comment about a selector, but otherwise this looks good.
Once the tests reset the setting so they aren't causing side-effects outside their test runs this is good to merge, so approving conditional on that change
Sep 19, 2018
referenced this pull request
Sep 21, 2018
Just to throw another opinion out there, has the problem of having multiple User Experiences been raised as a concern here? If some people experience it one way, and others experience it another way (based on a setting they'll possibly/likely forget about), it creates a disparate UX, making it tougher to write tutorials, make tutorial videos, and even to develop plugins which tap into this area.
Personally I don't like this area, but I think I like having the option to turn it off even less, as it created a forever-more fragmented user experience. My apologies for being a downer!