It can be submitted even if required fields are blank.

[Toraji123]

Description

I have created a form like this.

$fields = array('name' => array( 'required' => 1 ));
echo $mypod->form( $fields, 'Save' );

This is how it will appear on the front end.

It can be submitted even if this required field is blank.

Since it is a required field, can you please make it impossible to submit it?

Up to v2.7.31, an error message was displayed and it could not be submitted.

Thanks in advance.

Version

2.8.7

Testing Instructions

No response

Screenshots / Screencast

No response

Possible Workaround

No response

Site Health Information

No response

Pods Package

No response

[JoryHogeveen]

Another report: https://wordpress.org/support/topic/probleme-when-i-save-a-custom-post-with-empty-field-required/

[G-quatrys]

Hello For me this error is in admin page on custom content type

[HmCody]

I am also running into this problem. And what makes it worse is that the publish triggers pods_api_pre_save_pod_item and there is no indication that the required fields are not present short of testing them all.

[HmCody]

Some more information.

I am guessing that previously required field validation was taking place on the front end using Javascript, but has now been moved to the back end in PodsAP.php function save_pod_item. It seems as if this validation takes place after pre_save_pod_item.

For an existing item, this is a pain because I now have to validate before I can do my code in pre_save_pod_item, but I can do that. When I click on Update, validation then sends me to the error page (wp-admin/post.php) where there is a <<Back link that runs javascript:history.back(). Clicking the link takes me to wp-admin/post.php?post=5484&action=edit with all of my original values restored.

Where the real problem comes in is if I am creating a new item. WordPress creates a new post before the validation check is run. Validation then sends me to the error page. Clicking on Back his takes me to wp-admin/post-new.php?post_type=field_event but it starts another new post rather than using the one already created. This leaves the first post as an orphan, with no data, but listed as an item for the CPT. Closing the error page also results in the orphan.

I am sure there was a reason to move validation to the back end, I just wish it wasn't causing these other issues.

[HmCody]

One more detail. If a required field has a default value, that value is substituted for the blank field without being sent to error processing. Only required fields that do NOT have a default value now throw an error.

[G-quatrys]

I have partialy sove the problem with this function in JS : But only working on field inout[text] :

function pods_admin_submit_validation(valid_form, $submittable ){

let erreur=0;
let champs='';
$submittable.find('.pods-validate-required').each(function( index ) {
    let tr_pods_field__container_field=jQuery( this ).parent('th').parent('tr.pods-field__container').find('.pods-dfv-container input.pods-form-ui-field').val();

    if(tr_pods_field__container_field != undefined){
        console.log(tr_pods_field__container_field);
    let tr_pods_field__container_field_label=jQuery( this ).parent('th').parent('tr.pods-field__container').find('label.pods-validate-required').text();
    if(!tr_pods_field__container_field){
        jQuery( this ).parent('th').parent('tr.pods-field__container').find('.pods-dfv-container input.pods-form-ui-field').trigger('focus');

        erreur++;
    } }
  })

  if(erreur>1){return false;}else{return true;}
  //return false;

}

[sc0ttkclark]

@zrothauser we need a way to detect if the fields have met their requirements when handling submitting through our public forms JS. I know we'll be revisiting the other screens in other work but I wonder if there's some sort of API or function we can expose here to detect if the fields for a form are OK.

[Toraji123]

Do you have any plans to fix this bug? I and my customers will be very happy if this bug will be fixed.

[sc0ttkclark]

We need to go through this and determine what's left and what is already covered by the work planned for #2424.

Some of the problems described are resolved now but I just want to do a comprehensive review of the additional problems added on to this issue so we can figure out whether those should be their own separate issues or if we should solve them as part of this one.

[Toraji123]

@sc0ttkclark It appears that this issue has not yet been resolved. It would be very helpful if you could fix it.

[kazemihabib]

Thank you for this nice plugin, this feature is very important and it's broken now. I'd really appreciate it if you could fix it.

[sc0ttkclark]

Fixed and tested in 3eca8caa196110a65766a5c6df9dc87e6f18e3fa

Thanks everyone for your patience here, there's still more to do later for other validation rules and to make that all more dynamic with the DFV JS involved but it now properly picks up the required validation and will stop itself from submitting.