Required fields still not working

[JoryHogeveen]

Description

I know for sure this has been reported on several occasions and we've addressed this more than once.

For some reason the required option still isn't working properly and this gets reported again:

• https://wordpress.org/support/topic/required-field-36/
• https://wordpress.org/support/topic/required-mandatory-field-validation-message/

Due to the nature of this bug I really think we need to check this thoroughly and implement a proper fix.

Version

2.8+

[jamieburchell]

I see you've linked my support topic which has a screencast showing the issue. Let me know if I can provide any more info.

[rosa2]

Just in case that can help, I posted in the plugin WordPress forum my temporary solution to have validation for required pods fields. I wish is useful to you. Thanks for the plugin :)

[sc0ttkclark]

Working on pushing this forward in #7343

[Paktas]

Any progress on this?
18 months have passed for one of the most basic functionalities not working as expected.

[sc0ttkclark]

@Paktas This is in the hands of a developer I've brought in to help us work past some issues I've seen with stability of the required logic on the Block Editor screen. The solution I had previously wouldn't stop submission in all cases.

[Paktas]

Validation seems such a basic functionality.
Works perfectly for required fields on ACF:
https://github.com/AdvancedCustomFields/acf/blob/c6b165369a85bd25136bc75095acd46fe8a45b05/includes/validation.php#L9

[sc0ttkclark]

We've been trying to resolve a longstanding issue with Gutenberg here and ACF is doing the workaround through a JS override that can break other integrations.

The good news is that it appears a new version of Gutenberg has support for what we need but it's still marked as experimental. We are working on testing a solution that uses an ACF-like JS override on the submit process but our goal with this will always be to remain compatible with as many plugins as possible (and compatible with ACF) while ensuring every pathway towards saving results in validation checks.

[Paktas]

Can you link to Gutenberg experimental feature?
I understand compatibility is important, but not having data in pods due to validation flaws is a major show stopper.

[JoryHogeveen]

@Paktas
Please check the PR I've made #7369

ACF currently has a similar solution (savePost override for the editor).
I've also added the filter solution as comments in the PR so once these become available we can change the current solution for a filter approach which is much-much-(much) better.

This issue wasn't with validation itself, that was working just fine. It's just not (yet) possible to properly prevent the block editor from saving since it ignores your own validation process. The currently available savePost JS hook is ran after the general post data is already saved.

Link to the issue on Gutenberg repo WordPress/gutenberg#58022
As you can see the __unstablePreSavePost is merged into GB 19 and is marked as a non-stable hook at this time. GB 19 will be released somewhere during the next major WP release cycle: https://developer.wordpress.org/block-editor/contributors/versions-in-wordpress/
We have no idea when such a hook will become a "stable" hook according to the GB devs.

[JoryHogeveen]

@Paktas If possible, could you please take the time and let us know your test results on my PR? User feedback is very helpful to validate additions like these work as expected.

Direct link to the branch: https://github.com/pods-framework/pods/tree/feature/7343-form-validation
Direct link to the download ZIP: https://github.com/pods-framework/pods/archive/refs/heads/feature/7343-form-validation.zip

[zberno]

Hi @JoryHogeveen,
I've tested it on this environment:

• WordPress 6.6.2 and WordPress 6.7
• Gutenberg actived
• Custom Post Type with Required fields

Required Fields:

• Plain text, multiline
• WYSIWYG
• Relationship with Autocomplete

test 1: Submit with empty required fields

✔️ All empty required fiels has been detected and errors are visible both on top of the page and on the single field.

test 2: Submit with filled required fields

❌ WYSIWYG field has been detected empty.
✔️ Plain text and Relationship passed the validation

test 3: Submit with filled required fields - WYSIWYG with source tab active

✔️ Validation fully passed.
✔️ Required fields has been saved.
✔️ Not required fields has been saved.

test 4: Required fields are filled - delete all contents and submit

❌ WYSIWYG content deletion has not been detected before the Submit.
✔️ Plain text and Relationship content deletion are detected immediatly on Blur;
✔️Errors are visibile under the fields.
✔️The Save button is disabled - cannot submit

test 5: Required fields are filled - delete WYSIWYG content and submit

❌ WYSIWYG content deletion has not been detected before the Submit.
❌The Save button is active - can submit

The page appears to be saved correctly.
After a refresh:
❌WYSIWYG modifield field has not been saved
❌Modified required custom fields has not been saved
❌Modified not required custom fieds has not been saved
✔️Modified Page title has been saved

[sc0ttkclark]

This sounds like it's still an improvement and we're on the right track. While we could merge this and deploy it, I am worried that the results at the bottom could spell confusion and data loss for some folks who would otherwise not be aware. Better to keep this open and work on those fixes next to complete it.

[zberno]

Hi @sc0ttkclark and @JoryHogeveen,
a side note:
I've tested it also with Gutenberg disabled (using plugins like "Classic Editor" or "Disable Gutenberg").

With Gutenberg disabled the custom fields are not displayed at all, required or not.
I get a lot of "Cannot read properties of undefined" console errors.