WordPress.org

Make WordPress Core

Opened 4 years ago

Last modified 4 weeks ago

#13821 accepted defect (bug)

Changing visibility to password-protected without entering a password does not warn user

Reported by: markel Owned by: kapeels
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Editor Keywords: has-patch gci 4.0-early
Focuses: ui, administration Cc:

Description

Tested on r15182.

If the status of a post is set to Password Protected, and a password is not specified before the user clicks the OK button in visibility and then either publishes, saves, or updates the post, no warning is given to the user that not setting a password forces the post or page to remain Public.

In fact, if updating a post, and this is the only change made, the success message (1) for updating the post appears instead, even though no change was made to the post.

If the post was previously published as Private, and switched to Password Protected without entering a password, then saved, the post switches to Public on save instead of remaining Private.

Either a failure message upon updating or a warning to the user before saving should be displayed to the user to remind them that they didn't properly set a password.

To reproduce the last case above:

  1. Create a post. Publish it as Private.
  2. Edit the post. Change the visibility to Password Protected, but do not enter a password. Click OK.
  3. Update the post.
  4. The post visibility will be changed to Public.

Attachments (6)

13821-1.diff (1.7 KB) - added by kapeels 3 years ago.
13821-2.diff (2.5 KB) - added by kapeels 3 years ago.
13821-2.2.diff (2.3 KB) - added by kapeels 3 years ago.
This one has less green part and trims password before check
passwordpostux.diff (1.9 KB) - added by nano8blazex 3 years ago.
I'm not sure how to edit post.js - compress post.dev.js into it or something. The patch attached only modifies post.dev.js but post.js needs to done too.
13821.5.diff (1.9 KB) - added by MikeHansenMe 17 months ago.
refreshed based on previous patch
13821.diff (2.7 KB) - added by kovshenin 3 months ago.

Download all attachments as: .zip

Change History (24)

comment:1 nacin3 years ago

  • Keywords ux-feedback needs-patch added
  • Milestone changed from Awaiting Triage to Future Release

comment:2 in reply to: ↑ description kapeels3 years ago

  • Cc kapeel.sable@… added
  • Owner set to kapeels
  • Status changed from new to accepted

Replying to markel:

Either a failure message upon updating or a warning to the user before saving should be displayed to the user to remind them that they didn't properly set a password.

I second this.

Would like to do this for gci.

comment:3 nacin3 years ago

  • Keywords gci added

A post that is private should not revert to public, either.

Making a GCI task.

kapeels3 years ago

comment:4 kapeels3 years ago

  • Keywords has-patch added; needs-patch removed

comment:5 nacin3 years ago

Sorry for the delay on this.

Patch doesn't work.

comment:6 nacin3 years ago

Ideally, the "OK" button should simply be visually disabled and functionally not clickable unless there is a value in the password box.

On the button click, verify that there's a value. On the text box change, toggle the disabled class depending on there being a value.

No need for validation otherwise.

kapeels3 years ago

kapeels3 years ago

This one has less green part and trims password before check

nano8blazex3 years ago

I'm not sure how to edit post.js - compress post.dev.js into it or something. The patch attached only modifies post.dev.js but post.js needs to done too.

comment:7 follow-up: nano8blazex3 years ago

As the GCI task was reopened, and I'm not really sure whether kapeels' patch works or not, I've just submitted another patch.

comment:8 in reply to: ↑ 7 westi3 years ago

  • Cc westi added
  • Keywords 3.2-early added

Replying to nano8blazex:

As the GCI task was reopened, and I'm not really sure whether kapeels' patch works or not, I've just submitted another patch.

Marked as Completed.

This patch is cool really good UX improvement.

comment:9 nacin3 years ago

Might want a small JS cleanup on it, but that's it.

comment:10 danielbachhuber3 years ago

  • Cc d@… added

comment:11 MikeHansenMe20 months ago

  • Keywords needs-refresh added

Problem still exists. Patch needs a refresh, it did not prevent or notify me I had not entered a password.

comment:12 MikeHansenMe19 months ago

  • Cc mdhansen@… added

MikeHansenMe17 months ago

refreshed based on previous patch

comment:13 sillybean9 months ago

  • Cc steph@… added

comment:14 hidgw9 months ago

  • Cc hidgw added

comment:15 nacin3 months ago

  • Component changed from General to Administration
  • Milestone changed from Future Release to 3.9

kovshenin3 months ago

comment:16 kovshenin3 months ago

  • Component changed from Administration to Editor
  • Focuses administration added
  • Keywords 3.2-early needs-refresh removed

Tested and did a little js cleanup in 13821.diff. The disabling works for the OK button that is supposed to close the status area, however, the user can still update or save the post, so:

  1. Publish a private post
  2. Set the visibility to password protected, don't type in a password
  3. Hit Update, your post is now public

We can either disable the Update/Publish/Save button just like we do with OK, or we can revert the post status to whatever was chosen previously (private in the above case) upon post save/publish, if the password was blank. I like reverting better than disabling buttons. Thoughts?

comment:17 samuelsidler4 weeks ago

  • Keywords vci 4.0-early added; gci removed
  • Milestone changed from 3.9 to Future Release

Too late for 3.9, sadly. It's a decent amount of churn this late in the cycle. Let's get it early in 4.0.

comment:18 samuelsidler4 weeks ago

  • Focuses ui added
  • Keywords gci added; ux-feedback vci removed
Note: See TracTickets for help on using tickets.