Add option to skip PublishSidebar on publishing #9760

oandregal · 2018-09-10T17:14:37Z

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:

Testing

Open a new post
Add some content
Click "Publish..." button (which should show three dots at the end).

The expected result is that the Pre-Publish panel is opened and a checkbox is shown at the bottom of it.

Disable the checkbox, and cancel publishing.
Click "Publish" button again (which shouldn't have the dots).

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.

TODO

Add "Don't show this sidebar again" checkbox to the Publish Sidebar.
Better style the dismissable checkbox.
Move preference logic to core/editor.
Update tests.

oandregal · 2018-09-11T12:43:23Z

packages/editor/src/store/actions.js

+ *
+ * @return {Object} Action object
+ */
+export function enablePublishSidebar() {


I originally added the enable/disable logic to the core/edit-post store and moved it later to the core/editor. See 28262d2 The rationale for this change is that the PostPublishPanel (which lives in @wordpress/editor) uses this logic, and the editor can't depend on any component declared in edit-post.

An alternative approach could have been to keep the logic in edit-post and use the PrePublish and PostPublish extensions from edit-post to inject the checkbox component into the Publish sidebar. This is why I've discarded this approach:

In my view, the extensions are meant for allowing plugins to inject their own panels into the PublishPanel. Dismissing the panel is a core action and using the extensions to circumvent the editor/edit-post separation would be a convoluted way to add support for it. To me, that'd be a smell that the editor/edit-post separation needs some more thinking.

We want the checkbox to be shown in the same position of the panel (the bottom). To achieve this, we'd need to rely on CSS styling, because a plugin can't control other plugins's positions in the panel - which is prone to conflicts and unreliable positioning the checkbox.

Is there another alternative to consider where the publish panel makes more sense in edit-post and could be moved wholesale there? This doesn't really feel like a component which ought be offered by the editor module.

I wish we'd taken a more generalized approach akin to edit-post's toggleFeature than to have specific action creators, selectors, reducer handling for each and every user preference.

tofumatt

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?

tofumatt · 2018-09-11T13:02:37Z

edit-post/components/header/more-menu/index.js

@@ -38,6 +39,7 @@ const MoreMenu = () => (
 					filterName="editPost.MoreMenu.tools"
 				>
 					<TipsToggle onToggle={ onClose } />
+					<PublishSidebarToggle onToggle={ onClose } />


I know it's unrelated to this PR, but the onClose method being used for onToggle several times and onSelect below makes me think it should be renamed to closeMenu or something. 🤷‍♂️

tofumatt · 2018-09-11T13:03:33Z

edit-post/components/header/publish-button/index.js

@@ -0,0 +1,25 @@
+import { PostPublishPanelToggle, PostPublishButton } from '@wordpress/editor';
+
+const PublishButton = function( {


Any reason for using function() { over () => {? We just tend toward fat-arrow functions in the codebase, so it stood out.

tofumatt · 2018-09-11T13:04:05Z

edit-post/components/header/publish-button/index.js

+	isSidebarEnabled,
+	onToggle,
+	forceIsDirty,
+	forceIsSaving } ) {


Odd that eslint didn't catch it, but I'd expect } ) { on a de-dented newline.

tofumatt · 2018-09-11T13:05:20Z

edit-post/components/header/publish-button/index.js

@@ -0,0 +1,25 @@
+import { PostPublishPanelToggle, PostPublishButton } from '@wordpress/editor';
+
+const PublishButton = function( {


So this is now a button that turns into a panel? I'd sort of expect we'd have a button that toggled a panel on/off, not really one that changes from panel to button itself...

edit-post/components/header/publish-sidebar-toggle/index.js

tofumatt · 2018-09-11T13:07:26Z

packages/editor/src/components/post-publish-panel/index.js

@@ -96,6 +96,11 @@ class PostPublishPanel extends Component {
 							{ PostPublishExtension && <PostPublishExtension /> }
 						</PostPublishPanelPostpublish>
 					) }
+					<CheckboxControl
+						label={ __( "Don't show this sidebar again." ) }


This should be an apostrophe (’, not a single-quote ').

I need to update my keyboard setup to include that apostrophe. Good catch!

tofumatt · 2018-09-11T13:12:41Z

packages/editor/src/store/reducer.js

@@ -810,6 +810,13 @@ export function preferences( state = PREFERENCES_DEFAULTS, action ) {
 				...state,
 				insertUsage: omitBy( state.insertUsage, ( { insert } ) => insert.ref === action.id ),
 			};
+
+		case 'ENABLE_PUBLISH_SIDEBAR':
+		case 'DISABLE_PUBLISH_SIDEBAR':


I get that this is technically less code but I think it's nicer to have each action type return its own object. It's easier to grok what's happening that way–this code made sense to me but only after I looked at it for probably ten seconds; I was wondering why 'DISABLE_PUBLISH_SIDEBAR' needed to check if the action was 'ENABLE_PUBLISH_SIDEBAR'. I think it'd be nicer to just do:

case 'ENABLE_PUBLISH_SIDEBAR': return { ...state, isPublishSidebarEnabled: true, }; case 'DISABLE_PUBLISH_SIDEBAR': return { …state, isPublishSidebarEnabled: false, };

Thanks for keeping us obvious.

sarahmonster

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!

Some ideas:

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.

oandregal · 2018-09-11T18:16:51Z

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.

I was already working on that! Changes already pushed.

oandregal · 2018-09-11T18:28:49Z

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.

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.

oandregal · 2018-09-11T18:29:59Z

@tofumatt I'll defer to @sarahmonster and @karmatosed about the interaction, as I know they've discussed it and explored options in #7602 and #9398

michelleweber · 2018-09-11T20:12:35Z

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."

sarahmonster · 2018-09-11T20:36:46Z

"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."?

oandregal · 2018-09-12T07:33:12Z

Updated copy in d7d1b77

sarahmonster · 2018-09-12T07:55:44Z

Perhaps an earlier bug? Would you mind clearing your browser's cache and try again?

Seems to be working as expected now, or at least I can't replicate anymore, so 👍.

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'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!

tofumatt · 2018-09-12T10:34:56Z

Sorry, my comment was just about coding; the interaction would be the same, but I thought it was strange that the component conditionally output two very separate components based on state.

oandregal · 2018-09-12T10:42:50Z

Sorry, my comment was just about coding; the interaction would be the same, but I thought it was strange that the component conditionally output two very separate components based on state.

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.

tofumatt · 2018-09-12T10:53:59Z

@nosolosw Looks like you changed the code and alleviated my concerns 😄

Also: is the code ready for another review? I can look if so 😄

oandregal · 2018-09-12T10:58:23Z

Also: is the code ready for another review? I can look if so

Please! Also cc @sarahmonster in case she has any design concerns I should address. It'd be lovely to merge this today or tomorrow so it can make it to the 3.9 release.

tofumatt

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 👍

tofumatt · 2018-09-12T11:03:16Z

packages/editor/src/components/post-publish-panel/index.js

@@ -97,6 +97,13 @@ class PostPublishPanel extends Component {
 						</PostPublishPanelPostpublish>
 					) }
 				</div>
+				<div className="editor-post-publish-panel__footer">
+					<CheckboxControl
+						label={ __( 'Always show pre-publish checks.' ) }


Putting the word "this" inside this text might help contextualise this more.

Always show these pre-publish checks.

might help users understand it more. If it doesn't look too cramped I say go with that, but if it's already a tight space feel free to leave it as-is.

These data has been moved to edit-post store as per #4661

In theory, isPublishSidebarEnabled shouldn't be ever undefined in the preferences object, so this shouldn't be necessary. In practice, we use a localStorage mechanism to persist parts of the state in between sessions (like whether the user has already seen the tips or not). For the core/editor store we persist the preferences key, which contains an object. This is the problem: the localStorage mechanism doesn't check whether the cached preferences object and the state preferences object have the same shape, it just overwrites the current state, so new added keys are deleted. While this bug is not fixed and deployed, we want this preventive measure in place.

oandregal · 2018-09-17T12:23:45Z

I think it would be straightforward to write and useful to test.

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.

oandregal · 2018-09-18T08:31:54Z

Tested scheduling & submit for review states, on mobile, translations, etc.

@tofumatt I can land this as soon as I have a 👍 to enable merging again.

tofumatt

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 😄

tofumatt · 2018-09-18T17:27:44Z

test/e2e/specs/publishing.test.js

+		describe( `a ${ postType } with pre-publish checks disabled`, () => {
+			beforeEach( async () => {
+				await newPost( postType );
+				await disablePrePublishChecks();


Because this setting persists between page loads we should be careful with this… arguably we should have some kind of consistent/known state and after each test where we disable the pre-publish check we should re-enable them with the afterEach test helper.

Right now this test will disable pre-publish checks elsewhere which–as it's not the default state–could be confusing to future test writers.

Done, good catch!

tofumatt · 2018-09-18T17:29:09Z

test/e2e/support/utils.js

+export async function disablePrePublishChecks( ) {
+	await page.click( '.edit-post-more-menu' );
+	await page.waitForSelector( '.components-popover__content' );
+	await page.click( '.components-popover__content > .components-menu-group:nth-child(3) button:nth-child(3)' );


This is a bit of a fragile selector, is there anything better/better-named we could use to select the "Don't show this again" checkbox? It looks like . editor-post-publish-panel__footer input[type=checkbox] would work assuming CheckboxControl outputs an actual checkbox.

Solved at d7c7151

I was reluctant to introduce a specific selector just for testing but, on a second thought, it's totally worth it in this case. Note also that the code uses the general menu, not the actual checkbox within the publish sidebar. We can't guarantee the publish sidebar is enabled unless we use the general menu.

mintplugins · 2018-09-21T17:15:49Z

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!

aduth · 2018-10-12T16:53:55Z

packages/editor/src/store/test/reducer.js

 			} );
 		} );

+		it( 'should disable the publish sidebar', () => {
+			const original = deepFreeze( preferences( undefined, { } ) );


No filler spaces in empty constructs (e.g., {}, [], fn()).

https://make.wordpress.org/core/handbook/best-practices/coding-standards/javascript/#spacing

Need to find if possible to enforce by ESLint.

eslint/eslint#7927

oandregal self-assigned this Sep 10, 2018

oandregal added the [Status] In Progress Tracking issues with work in progress label Sep 10, 2018

oandregal requested a review from sarahmonster September 10, 2018 17:14

This was referenced Sep 10, 2018

Enhance the Publishing flow #7602

Closed

WIP: Try new publishing flow #9398

Closed

oandregal force-pushed the add/skip-publish-panel branch from a8a8bfe to 5869239 Compare September 11, 2018 10:08

oandregal commented Sep 11, 2018

View reviewed changes

oandregal requested review from youknowriad and tofumatt September 11, 2018 12:43

tofumatt requested changes Sep 11, 2018

View reviewed changes

sarahmonster requested changes Sep 11, 2018

View reviewed changes

sarahmonster added the Needs Copy Review Needs review of user-facing copy (language, phrasing) label Sep 11, 2018

oandregal removed the [Status] In Progress Tracking issues with work in progress label Sep 11, 2018

tofumatt self-requested a review September 11, 2018 19:53

tofumatt removed the Needs Copy Review Needs review of user-facing copy (language, phrasing) label Sep 11, 2018

oandregal added the [Type] Enhancement A suggestion for improvement. label Sep 12, 2018

oandregal added this to the 3.9 milestone Sep 12, 2018

sarahmonster approved these changes Sep 12, 2018

View reviewed changes

tofumatt requested changes Sep 12, 2018

View reviewed changes

oandregal and others added 8 commits September 17, 2018 11:39

Update wording

c65ea7c

Update copy

18036e2

Tweak microcopy for pre-publish checks.

c37b6a8

Remove outdated docs

d1c69c5

These data has been moved to edit-post store as per #4661

Fix and add tests

79ced01

Add e2e test

78ebeec

Refactor code to avoid duplication

87b372d

oandregal force-pushed the add/skip-publish-panel branch from 3548cd0 to 87b372d Compare September 17, 2018 12:16

oandregal requested a review from tofumatt September 17, 2018 12:16

oandregal mentioned this pull request Sep 18, 2018

Persistence data plugin should take into account the object shape #9994

Closed

chore: Tweak styles

acffe70

tofumatt approved these changes Sep 18, 2018

View reviewed changes

oandregal added 4 commits September 19, 2018 10:01

Disable pre-publish checks after test

37900cc

Add enable/disable functions

6637b7e

Use specific selector to target pre-publish checks menu item

d7c7151

Do not make assumptions about previous states

b50ca1d

oandregal merged commit 27cc2b6 into master Sep 19, 2018

oandregal deleted the add/skip-publish-panel branch September 19, 2018 10:58

youknowriad mentioned this pull request Sep 21, 2018

Clunky UX when publishing hides categories. #10083

Closed

aduth reviewed Oct 12, 2018

View reviewed changes

postphotos mentioned this pull request Oct 14, 2018

Fix: z-index: -1 needed for publish footer due to accordions #10589

Closed

4 tasks

yassine4999 mentioned this pull request Nov 30, 2023

[Snyk] Fix for 1 vulnerabilities yassine4999/gutenberg#29

Open

soloinovator mentioned this pull request Nov 30, 2023

[Snyk] Fix for 1 vulnerabilities soloinovator/gutenberg#106

Open

petrescugit mentioned this pull request Nov 30, 2023

[Snyk] Fix for 1 vulnerabilities petrescugit/gutenberg#9

Open

captainbarber99 mentioned this pull request Nov 30, 2023

[Snyk] Fix for 1 vulnerabilities captainbarber99/gutenberg#23

Open

MaxMood96 mentioned this pull request Dec 1, 2023

[Snyk] Fix for 1 vulnerabilities MaxMood96/gutenberg#119

Open

		@@ -0,0 +1,25 @@
		import { PostPublishPanelToggle, PostPublishButton } from '@wordpress/editor';

		const PublishButton = function( {

Add option to skip PublishSidebar on publishing #9760

Add option to skip PublishSidebar on publishing #9760

Conversation

oandregal commented Sep 10, 2018 • edited Loading

How it works

Testing

TODO

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tofumatt left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sarahmonster left a comment

Choose a reason for hiding this comment

oandregal commented Sep 11, 2018

oandregal commented Sep 11, 2018

oandregal commented Sep 11, 2018

michelleweber commented Sep 11, 2018

sarahmonster commented Sep 11, 2018 • edited Loading

oandregal commented Sep 12, 2018

sarahmonster commented Sep 12, 2018

tofumatt commented Sep 12, 2018

oandregal commented Sep 12, 2018

tofumatt commented Sep 12, 2018

oandregal commented Sep 12, 2018

tofumatt left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

oandregal commented Sep 17, 2018 • edited Loading

oandregal commented Sep 18, 2018

tofumatt left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mintplugins commented Sep 21, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

oandregal commented Sep 10, 2018 •

edited

Loading

sarahmonster commented Sep 11, 2018 •

edited

Loading

oandregal commented Sep 17, 2018 •

edited

Loading