If the required fields are not set on user profile's save, every field's value will be dropped

[jackjohansson]

Hi,

In the user profile screen, there are some required fields such as email and nickname.

Let's say I have added some extra fields using edit_user_profile and show_user_profile action hooks. These fields are filled by the user, and do not have to be required.

If the user fills every field (let's say 20 fields, took 10 minutes to fill) but clears the email field and save the form, there will be shown an admin error:

ERROR: Please enter an email.

Every field that was filled by the user will be dropped, and has to be refilled.

The point is, until the required fields are empty, there is no reason to let the user save the form in the first place.

This issue has been discussed in the WordPress Development StackExchange. I've posted 3 solutions for this issue, which can be improvement or bug resolve.

Below is a link to the question on WPSE. I would be happy to write an accurate solution, in case the development team decides to push this into their future patches.

​https://wordpress.stackexchange.com/q/272940/94498

King regards,
Jack

[swissspidy]

This could be as simple as using the validateForm() JavaScript function available in WordPress.

[jackjohansson]

Replying to swissspidy:

This could be as simple as using the validateForm() JavaScript function available in WordPress.

Thanks for the reply.

However, shouldn't this be a part of the core by default? There's no point in submitting a form that lacks required fields.

It would make some sense if the form was properly saved, but it's just submitted in order to trigger an error.

[swissspidy]

Replying to jackjohansson:

Replying to swissspidy:

This could be as simple as using the validateForm() JavaScript function available in WordPress.

Thanks for the reply.

However, shouldn't this be a part of the core by default? There's no point in submitting a form that lacks required fields.

It would make some sense if the form was properly saved, but it's just submitted in order to trigger an error.

I didn't oppose your idea. By pointing out validateForm() I'm simply suggesting a way to solve this in core.

[SergeyBiryukov]

Related: #27606

[jackjohansson]

Replying to SergeyBiryukov:

Related: #27606

Hi,

The related ticket purposes a patch on the server side. However the issue is still standing (see the linked question).

Is a front-end solution possible in this case as @swissspidy mentioned? I've already coded a script that validates the form before sending (including extra fields added by user). If so, should I push it forward?

[psykro]

Replying to jackjohansson:

Replying to SergeyBiryukov:

Related: #27606

Hi,

The related ticket purposes a patch on the server side. However the issue is still standing (see the linked question).

Is a front-end solution possible in this case as @swissspidy mentioned? I've already coded a script that validates the form before sending (including extra fields added by user). If so, should I push it forward?

I'd say if you have a patch that solves the problem, go ahead and submit it

[jackjohansson]

First patch for user update, has one bug currently

[jackjohansson]

I've added the initial patch for this bug. It checks nickname and password in the by jQuery, and the email by AJAX.

Currently it has a bug, you need to click the submit button twice if all of the fields are valid. There is most likely some other handler interfering, as this bug doesn't exist in a JSFiddle version of this patch.

If anyone has a moment to try it out, their feedback will be greatly appreciated.

@swissspidy @SergeyBiryukov @psykro @afercia

[psykro]

Thanks @jackjohansson I'll take a look

[DrewAPicture]

Assigning to mark the good-first-bug as "claimed".

[SergeyBiryukov]

Related: #47064

On the user profile screen, required fields (Email and Nickname) are validated server-side. If a user spends time filling out many fields but leaves a required field empty and submits, WordPress returns a server-side error and all unsaved field values are lost.

This fix adds client-side validation to the profile form using the existing validateForm() function already available in common.js. The form-required class is added to the Nickname and Email rows in user-edit.php, and a submit event handler is added to #your-profile in user-profile.js that calls window.validateForm() to block submission and highlight the empty fields. Server-side validation is unchanged and remains the security boundary. Only the #your-profile update form is targeted, matching the server-side behavior where Nickname is only required on update.

Trac ticket: https://core.trac.wordpress.org/ticket/41314

## Use of AI Tools

[softglaze]

I have tested [PR 11511](​https://github.com/WordPress/wordpress-develop/pull/11511) locally, but the client-side validation is currently failing to block the form submission.

Testing Environment:

• OS: Windows
• Local Env: wordpress-develop (Docker/Node)
• Browser: Chrome (with cache disabled via DevTools)
• WordPress: 7.1-alpha (trunk)

Steps Taken:

1. Fetched and applied PR #11511.
2. Verified the form-required class was correctly output in the HTML for user-edit.php.
3. Ran npm run build to compile the JavaScript.
4. Edited a profile: filled out a non-required field (Website) and cleared the required "Email" and "Nickname" fields.
5. Clicked "Update Profile".

Results:
The client-side JavaScript does not stop the submission. The form submits to the server, the page reloads, the standard red server-side error is thrown, and all unsaved data in the other fields is wiped clean.

It appears the submit event listener added to user-profile.js isn't successfully catching the event or triggering validateForm(). This will need further debugging!

[softglaze]

Following up on comment:16 — my earlier result was invalid due to a broken local build (I had run npm run build while the site serves src/, so no compiled JS was loaded and all core JS 500'd; the failure I reported was an environment artifact, not the PR).

After a clean npm ci + npm run ​build:dev, retested PR 11511 (Windows, Docker, Chrome, 7.1-alpha trunk):

✅ With Nickname and/or Email cleared: submission is blocked client-side, both fields get the error highlight, and all other unsaved values are preserved. Tested each required field individually as well.
✅ With valid data: the form saves normally in a single click.

One minor issue: each blocked submission activates the spinner next to the Update Profile button and it's never reset, so spinners accumulate and it looks like the page is stuck loading [attach your screenshot with the two circles]. Since the button is at the bottom and the error highlight is at the top of the form, there's also no visible feedback near the button about why nothing happened — resetting the spinner and moving focus to the first invalid field would help.

Overall the approach works and fixes the data-loss problem; the spinner handling looks like a small follow-up fix in the submit handler. Restoring has-patch.

Tested locally on Windows (Docker, Chrome, 7.1-alpha trunk) after a clean npm ci + npm run ​build:dev — the fix works as intended: submission with empty Nickname/Email is blocked client-side, both fields get the error highlight, and unsaved values in other fields are preserved. Valid data saves normally in a single click.

One minor issue: each blocked submit activates the spinner next to the Update Profile button and it's never reset, so spinners accumulate on repeated attempts (screenshot attached). Since the button is at the bottom and the highlighted fields are at the top, there's no feedback near the button about why nothing happened. Suggest resetting the spinner in the handler when validation fails, and possibly moving focus/scrolling to the first invalid field.

Full test notes on the Trac ticket: https://core.trac.wordpress.org/ticket/41314#comment:17

[westonruter]

Replying to swissspidy:

This could be as simple as using the validateForm() JavaScript function available in WordPress.

9 years later, it seems like we should be using HTML5 form validation now instead.

Related:

• #32510
• #47595
• #65281