Setting post visibility to "private" forces immediate publishing of post

[sarahmonster]

When publishing a post, if you set the visibility to "private" in the pre-publish panel, a browser notification appears, asking if you want to immediately publish the post as private. Dismissing the notification reverts the selection, and approving it publishes the post immediately.

This also happens in the document settings sidebar, where it's even more likely that users wouldn't want to immediately publish their post:

I'm not sure if this is by design, but it feels like unexpected behaviour, especially when it's presented in line with the public/password-protected options, both of which don't force an immediate publish. We also skip all of the pre-publish and post-publish checks altogether when using this approach, which means the publishing experience feels markedly different when publishing a private post.

Steps to reproduce

1. Write a post.
2. Press the "Publish" button.
3. Open the "Visibility" panel.
4. Select the "Private" radio option.

[tofumatt]

That definitely seems like a bug, or if it's by design that's a very weird design and we should nix it 😆

[youknowriad]

This is not a bug :). We could argue that's is a weird design but since you can't save a "private draft" for instance, it kind of make sense to publish directly.

[tofumatt]

There are semantics people attribute to something being a draft versus "published" though. It also seems like a deliberate special case that we do… if a post can technically be both a draft and private, we should allow it. If we are special-case not allowing it that seems a silly special-case. 😄

[youknowriad]

I think it wasn't clear in my response:

if a post can technically be both a draft and private, we should allow it

This is not possible because it's stored in the same field "post status"

[youknowriad]

I'd love it was possible to separate "post visibility" from "post publish status" but it's not the case in WP, unfortunately, and this would require a big refactoring and probably a big breaking change to be possible.

[tofumatt]

Ohhhh, okay. That makes sense and I don't think it's worth the refactor! Sorry, I didn't know that.

Maybe the trick here then is to at least improve the messaging. Something like:

Marking a post as "Private" will immediately publish it, is this okay?

🤷‍♂️

[youknowriad]

Yes, sounds like the best thing we can do.

[danielbachhuber]

Does it need to save right away? Or can changing a post to Private update the "Publish" button UI, and then the state isn't applied until the post is saved?

[youknowriad]

If it's not saved right away, it will be a confusing UI as well. What happens when you switch visibility to "private" and click "save draft"? A user will expect the privacy setting to stay on "private"

[danielbachhuber]

What happens when you switch visibility to "private" and click "save draft"? A user will expect the privacy setting to stay on "private"

The "Save Draft" button should disappear when post visibility is private?

[tofumatt]

Save draft disappearing on private makes sense to me.

[youknowriad]

It's not that simple :) you can't schedule a private post either.

[danielbachhuber]

you can't schedule a private post either.

You can set the date on a private post though?

[youknowriad]

I assume this would change the status to "future" which will be a public post?

[youknowriad]

I'm resistant here because I'm well aware that these tweaks to how we deal with the post status are very fragile and can break very easily. If someone would like to try doing updates, I'm not against it but be aware that there are a lot of assumptions in different places that can lead to breakage.

I'm afraid this would add a lot of complexity for a small gain.

[tofumatt]

I'm afraid this would all a lot of complexity for a small gain.

Reading all of this makes me think that just tweaking the wording here is probably fine for now 😅

[danielbachhuber]

I'm resistant here because I'm well aware that these tweaks to how we deal with the post status are very fragile and can break very easily. If someone would like to try doing updates, I'm not against it but be aware that there are a lot of assumptions in different places that can lead to breakage.

I understand the fragility angle, certainly. The fragility of the code reflects the complexity of the UX behavior, for what appears to be a simple feature. This can be protected against with good UI flows, test coverage, etc.

I'm afraid this would add a lot of complexity for a small gain.

It's not a "small gain"; it's the difference between a polished, robust, world-class product and everything else. It doesn't need to be fixed immediately, certainly, but it should be done well.

Related #8151 (comment)

[youknowriad]

Kindly disagree. Fixing this in the wrong way would introduce more fragility and complexity.

• The wrong way: Cosmetic updates to the UI depending on the status (not being able to save posts as a draft when the visibility is draft, not being able to schedule posts when the visibility is private)

• The good way: Separate the visibility and the publishing status in the REST API (and probably WordPress in general).

[danielbachhuber]

Fixing this in the wrong way would introduce more fragility and complexity.

I agree with this.

The wrong way: Cosmetic updates to the UI depending on the status (not being able to save posts as a draft when the visibility is draft, not being able to schedule posts when the visibility is private)

I disagree with this. The UI is an implementation of the REST API, not the other way around. The UI should reflect whatever the desired UX intentions are, and be built on top of a broader REST API abstraction.

Furthermore, I haven't a clue what sort of changes this would include with the REST API. Even if we went down that route, making changes to the REST API based on desired UI behavior would be more fragile, brittle, and prone to accidental breakage. And the UI would still need to be updated anyway.

[youknowriad]

Furthermore, I haven't a clue what sort of changes this would include with the REST API. Even if we went down that route, making changes to the REST API based on desired UI behavior would be more fragile, brittle, and prone to accidental breakage. And the UI would still need to be updated anyway.

I'm not stating that we should make REST API changes based on UI desires. I'm stating that there's a conceptual issue in WordPress (unrelated with any UI) where "visibility is mixed with status" which makes it possible to have "drafts for public posts", "scheduled public posts" but not "drafts for private posts" or "scheduled private posts".

[danielbachhuber]

I'm stating that there's a conceptual issue in WordPress (unrelated with any UI) where "visibility is mixed with status" which makes it possible to have "drafts for public posts", "scheduled public posts" but not "drafts for private posts" or "scheduled private posts".

It's an implementation detail, and a constraint to work with. I think it's unlikely that we'll change this part of the application design.

[chrisvanpatten]

One other element to note here is that selecting "Private" doesn't actually save the post if you haven't entered a title, and select "Private" from the visibility popover in the document inspector.

[danielbachhuber]

One other element to note here is that selecting "Private" doesn't actually save the post if you haven't entered a title, and select "Private" from the visibility popover in the document inspector.

Related #6556

[slimmilkduds]

I want to be able to set the default post visibility to private for certain post types. This used to work in the classic editor but I guess that wont be an easy thing to implement after scimming through this discussion?

[mtias]

@danielbachhuber because it is still a pretty bad UX. Changing the status to private means that the post is set to be published as soon as you click "update", which is not at all evident, specially since that becomes the only way to save your changes from then on. If you want to continue to make changes to the post, you are also likely to want them saved which would mean you'll press "update" anyways (but now the consequences of the action are less evident).

Furthermore, after "updating" such a post, switching it back to "public" means the post is actually published to everyone, which is not at all intuitive and can lead to data leaks since the chain of actions was: "Set visibility to private" -> "Update the post after a few changes" -> "Switch the post back to public" — a user is likely to assume this is still a draft, but in this chain of operations the post has been published. The fact changing a "visibility" setting is also changing the post status is not evident, so it's better to make sure the user is ready to commit to that.

[danielbachhuber]

because it is still a pretty bad UX. Changing the status to private means that the post is set to be published as soon as you click "update", which is not at all evident, specially since that becomes the only way to save your changes from then on.

Even though it's pretty bad UX, it's still:

1. Parity with existing core UX.
2. Not a confusing alert() popup. I'd be surprised if we used alert() anywhere in core.

We're already forcing users to learn the block paradigm. We want to minimize the total number of interfaces they need to relearn.

[earnjam]

I think this is what @danielbachhuber is suggesting.

Save draft button removed. Publish button makes it clear that you will be publishing the post if you click it.

After clicking the publish button, you still have to go through the "double check your settings prompt" and it allows another opportunity to change the verbiage of the button to make sure people know the post will be private.

I think it's way more confusing to have a post get published by clicking on something other than the publish button. That button should be the one and only way to make your post live.

[mtias]

@earnjam could you start a patch for this approach? I think it might work alright.

[earnjam]

Yep, I’ll try to put something together tonight.

[earnjam]

#12023 is essentially what I proposed above.

The only thing that is a tiny bit confusing is the post is considered dirty once you change the visibility, so even if it autosaves, then if you try to navigate away from the post it will warn you about unsaved changes. But the visibility is the only thing that wouldn't have been saved in that case.

[youknowriad]

This is not really a bug and the alternative has drawbacks too. Let's take the time to refine this properly.

[earnjam]

I don't want to rush it either, but my only concern with a delay is that we'd then be changing the publishing workflow of core, not a plugin. A good bit different scale.

[pfarikrispy]

I have this same issue or very very similar in WordPress.com on 5.0.3
https://imgur.com/uV3Fj53

[warrentab]

Hello;

Since I began using WordPress over 6 years ago, I would always start out writing my posts in Private mode. They would stay private until I was ready to publish.

Now, with Gutenberg, when saving my posts as I go along while in Private mode it keeps switching to Public mode.

Has this issue been resolved?

[earnjam]

@warrentab Not yet. I have a pull request open (#12023) that solves the issue, but I need to refresh it because there have been some updates that have occurred while I was waiting on design feedback.

[warrentab]

Thank you, sir. I guess I will be kept in the loop about this? *Warren*

…

On Tue, Apr 9, 2019 at 4:26 PM William Earnhardt ***@***.***> wrote: @warrentab <https://github.com/warrentab> Not yet. I have a pull request open (#12023 <#12023>) that solves the issue, but I need to refresh it because there have been some updates that have occurred while I was waiting on design feedback. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#9396 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIO8-Vg1yWJa_Ewz1itkBglritVvl3nlks5vfPdcgaJpZM4WPYYH> .

[pfarikrispy]

Excellent! Glad to hear of this fix. Happens less to me now since I use draft mode as a workaround. Private is more useful since I can signal fellow editor and admin about new proposals. They show in place whereas draft has no root. Christian.

…

On Tue, Apr 9, 2019, 16:28 warrentab ***@***.***> wrote: Thank you, sir. I guess I will be kept in the loop about this? *Warren* On Tue, Apr 9, 2019 at 4:26 PM William Earnhardt ***@***.*** > wrote: > @warrentab <https://github.com/warrentab> Not yet. I have a pull request > open (#12023 <#12023>) that > solves the issue, but I need to refresh it because there have been some > updates that have occurred while I was waiting on design feedback. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > < #9396 (comment) >, > or mute the thread > < https://github.com/notifications/unsubscribe-auth/AIO8-Vg1yWJa_Ewz1itkBglritVvl3nlks5vfPdcgaJpZM4WPYYH > > . > — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#9396 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AL2tW7oD5BpknhOQNl0P4BuXSTYNLe9aks5vfPfegaJpZM4WPYYH> .