Make WordPress Core

Opened 9 years ago

Closed 5 years ago

#19531 closed defect (bug) (worksforme)

Wrong error message after correcting an error in username

Reported by: wimfeijen Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Administration Keywords:
Focuses: Cc:


After entering an illegal username (fe. "Wim (wim@…)"), WordPress gives an error message saying:
"ERROR: This username is invalid because it uses illegal characters. Please enter a valid username."
So far so good.

Now, when I correct the issue and click "Add new user" again, the above error message remains in the screen, while the illegal characters are no longer there and the actual error I am facing is that I forgot my password. Which is confusing for me.

The same occurs, when I enter an e-mail which has already been registered. I get the error message:
"ERROR: This email is already registered, please choose another one."
When I correct, the error message remains, while this particular problem has been solved.

WP v: 3.3
Browser: Google Chrome 14.0 on Ubuntu 11.10

Attachments (2)

19531.patch (554 bytes) - added by SergeyBiryukov 8 years ago.
19531.2.diff (561 bytes) - added by MikeHansenMe 5 years ago.
refreshed from src dir

Download all attachments as: .zip

Change History (10)

#1 @SergeyBiryukov
9 years ago

  • Keywords needs-patch added

#2 @DrewAPicture
9 years ago

  • Cc xoodrew@… added
  • Keywords 2nd-opinion close added

I believe that this is currently expected behavior, clunky as it may be.

If I'm grasping this correctly, a $_POST error (generated via server-side validation) will persist as long as long as one of the four required inputs (user_login, email, pass1 or pass2) is empty. This is because the asynch validation prevents the form from updating the $_POST data until they all hold some kind of value regardless of integrity. E.g., ajax checks for a value, server checks for integrity of the value.

So unless somebody wants to tackle asynchronous server-side $_POST validation, I suggest closing as wontfix or maybelater.

#3 @bkerensa
8 years ago

  • Resolution set to maybelater
  • Status changed from new to closed

Marking this maybelater as I concur with @DrewAPicture that we would need to tackle async server-side validation or find another work around.

#4 @helen
8 years ago

  • Keywords close removed
  • Milestone Awaiting Review deleted

#5 @SergeyBiryukov
8 years ago

  • Component changed from General to Administration
  • Keywords has-patch added; needs-patch removed
  • Milestone set to Awaiting Review
  • Resolution maybelater deleted
  • Status changed from closed to reopened

A workaround might be to hide div.error along with adding form-invalid class in wpAjax.invalidateForm() when trying to submit an incomplete form.

5 years ago

refreshed from src dir

#6 @chriscct7
5 years ago

  • Keywords close added; 2nd-opinion has-patch removed

This works fine for me on trunk. When you correct the username and forget to do the password, the password field is lit up to remind you to put in a password. If you bypass this check by removing the field-required class, on refresh you get a "ERROR: Please enter your password." notice. Someone must have fixed this since then.

Thinking close as worksforme

#7 @UmeshSingla
5 years ago

  • Keywords 2nd-opinion added

Works properly, Tested it on multisite, registration works properly.

Ticket can be closed

#8 @chriscct7
5 years ago

  • Keywords close 2nd-opinion removed
  • Milestone Awaiting Review deleted
  • Resolution set to worksforme
  • Status changed from reopened to closed
Note: See TracTickets for help on using tickets.