Some of my 'create' forms contain cred fields of various types that are contained within a 'hidden' div because I want the fields to be created but not filled in when the post is first created. This has always worked in the past but I've noticed that date fields within the hidden div are not being saved to the database. Other field types however are being saved successfully.
I'm afraid I don't know when this first cropped up so can't give any guidance as to which version of Forms changed the behaviour.
Is this a known issue?
Hi Julie,
Thank you for contacting us and I'll be happy to assist.
When you mention hidden form fields saving values to the database, does this mean that they are set with a default value?
( using the "value" attribute - https://toolset.com/documentation/user-guides/cred-shortcodes/#cred_field )
I've performed some tests on my website, with the date and other type fields which had a default value set, but were also inside a hidden div. The values of these fields were successfully saved each time, a new post was created using this form.
In case you're using the hidden fields differently, please share the exact steps to reproduce this issue and I'll investigate this accordingly.
regards,
Waqar
Hi Waqar
On my CRED forms, the field is simply hidden from view using CSS like this:-
<div class="admin-only">
[cred_field field='my-date' force_type='field' class='form-control' output='bootstrap']
</div>
and I have this in my stylesheet:-
.admin-only {display:none;}
Because the field is simply hidden from view on the frontend, the field should still be saved to the database with the field name as meta_key and the meta_value should be blank.
To rule out a possible issue somewhere on my dev site, I installed my minimal "vanilla" site (just has Toolset Forms, Types, Access & Views plugins and 2017 theme) and created a form with two custom fields (one single field, one date). I hid the date field as above and submitted the form, one with a value in the visible field and the second with nothing in the visible field. As you can see from the uploaded image, the hidden field isn't saved, the visible field is saved even if it's empty. After further testing, I've discovered that actually the issue isn't with the field being hidden from view; the date field isn't being saved if it's left empty. There is no default set for the field. This hasn't been an issue in the past. Can you clarify please whether something has changed and a default is now required (not ideal IMHO) or is this unexpected behaviour?
Thanks
Hi Julie,
Thank you for sharing these details and I was able to reproduce this behavior on my test website too.
I've shared this with the concerned team, to confirm if this is the expected behavior for the date type fields moving one or will this will be changed in future releases? I'll keep you updated with the progress through this ticket.
For now, if the empty meta entry for that date type field is important for your workflow, you can use "cred_save_data" hook, to add an empty custom field entry:
( ref: https://toolset.com/documentation/programmer-reference/cred-api/#cred_save_data )
Example:
add_action('cred_save_data','custom_check_date_field',15,2);
function custom_check_date_field($post_id, $form_data) {
if ($form_data['id']==1234) {
// check if some date is selected
$date_field = $_POST['wpcf-date-field']['datepicker'];
// if empty or not set, insert an empty value meta entry
if(empty($date_field) || !isset($date_field))
{
update_post_meta( $post_id, 'wpcf-date-field', '' );
}
}
}
Note: Please replace "1234" and "date-field" with the actual ID of your form and the slug of your date type field, respectively.
regards,
Waqar
Hi Waqar
Thank you for testing and providing a work-around whilst we wait for a response.
I wouldn't expect this to be expected/normal behaviour; it simply doesn't make sense for empty fields to be simply dismissed like this (and I also don't believe this has been the case in the past) - sometimes we do actually need to record the fact that a value wasn't provided!
I'll wait to hear from you.
You're very welcome Julie!
Appreciate you brought this forward and I'll keep you updated.
regards,
Waqar
Hi Julie,
I've heard back from the concerned team and here are some key points.
1. No change has been introduced to how the Toolset Form handles the empty custom fields and depending on the type of field, an empty entry is saved or not:
a). Field types where empty entries are saved:
color picker, email, embedded-media, number, phone, select, skype, multiple-lines, single-line, URL, WYSIWYG
b). Field types where empty entries are not saved:
audio, checkboxes, checkbox, date, file, image, radio, video
2. Since changing the behavior for these fields in future releases can result in a number of backward compatibility issues for already built websites, it cannot be considered safe to implement.
3. For someone who needs empty or defaults value entries for these custom fields, the hook "cred_save_data" or "value" attribute can be used with the "cred_field" shortcode.
( as already discussed in this thread )
regards,
Waqar
Hi Waqar
Thank you for the clarification. I get the issue about backwards compatibility even if it does make things cloudy; I'm all for consistency - it makes life alot easier. I'm not 100% convinced that this isn't a change but neither am I 100% convinced that it is !!
So, for the 8 field types that are not saved if empty, can you confirm please that the format for checking them in the snippet is as follows (I'm referring to the text in the second square brackets):-
$audio = $_POST['wpcf-audio-field']['audio'];
$checkboxes = $_POST['wpcf-checkbox']['checkbox'];
$checkbox = $_POST['wpcf-checkbox']['checkbox'];
$date = $_POST['wpcf-date-field']['datepicker'];
$file = $_POST['wpcf-file-field']['file'];
$image = $_POST['wpcf-image-field']['image'];
$radio = $_POST['wpcf-radio-field']['radio'];
$video = $_POST['wpcf-video-field']['video'];
In point 3, you say either a cred_save_data hook or value attribute is needed for default value entries (for the field types that don't save if empty). I have to disagree here; if a radio field (for example) has one of its values set as a default, that value (if the user doesn't select a different one) is saved to the database (I've just double checked it).
Hi Julie,
Thanks for writing back and for understanding.
Checking for the values of the other fields (i.e. other than the "date" type) from the "$_POST" variable is simpler:
$audio = $_POST['wpcf-audio-field'];
$checkboxes = $_POST['wpcf-checkboxes-field'];
$checkbox = $_POST['wpcf-checkbox-field'];
$date = $_POST['wpcf-date-field']['datepicker'];
$file = $_POST['wpcf-file-field'];
$image = $_POST['wpcf-image-field'];
$radio = $_POST['wpcf-radio-field'];
$video = $_POST['wpcf-video-field'];
Important notes:
1. To view how the form values are passed through the "$_POST" variable at the time of submission, I'll recommend trying the "WP PHP Console" plugin ( https://wordpress.org/plugins/wp-php-console/ ).
Guide: lien caché
2. The data of "checkboxes" type Toolset custom field is saved in a special format and for this reason, I'll not recommend to include a blank entry for this type of custom fields, since this can result in unexpected behavior, later ( when any of the options is actually checked ).
As for point 3, I stand corrected and your observation about the "radio" type fields is correct, for the case when a default option is selected.
The same is also possible for a "checkbox" type field ( and not the "checkboxes" type field) if we select "save 0 to the database" option in its settings.
( screenshot: lien caché )
So it all depends on the exact requirements of the planned usage of those fields and how they're configured.
regards,
Waqar
Hi Waqar
Many thanks for this - I'm glad I asked!
Going back to your original snippet:-
add_action('cred_save_data','custom_check_date_field',15,2);
function custom_check_date_field($post_id, $form_data) {
if ($form_data['id']==1234) {
// check if some date is selected
$date_field = $_POST['wpcf-date-field']['datepicker'];
// if empty or not set, insert an empty value meta entry
if(empty($date_field) || !isset($date_field))
{
update_post_meta( $post_id, 'wpcf-date-field', '' );
}
}
}
if I have a post form that creates (rather than edits) a post and contains date fields that are hidden on the frontend using CSS and need to be saved to the database, is there any reason why I couldn't (or shouldn't) simplify the snippet by just using this?
add_action('cred_save_data','custom_check_date_field',15,2);
function custom_check_date_field($post_id, $form_data) {
if ($form_data['id']==1234) {
update_post_meta( $post_id, 'wpcf-date-field', '' );
}
}
}
Also, I'm actually not sure now that I do get why there is a backwards compatibility issue. I'm struggling to understand why it would be a problem for older sites if the current behaviour of audio, checkboxes, checkbox, date, file, image, radio and video fields were to be changed in core code to match the others by saving empty values. To me it makes sense for them all to behave in the same way. Would you mind indulging my curiosity and help me understand the issue please?
Hi Julie,
Glad my message helped.
In case of a new post form, where the date field is already hidden, it is safe to drop the additional check for "empty" and "isset".
To clarify the backward compatibility issue, it is important to understand that for items like conditional display blocks code and views with meta/custom field queries, an "empty" custom field entry and a "non-existing" one, won't always be the same. Also, many customers may already have a number of custom code snippets, designed according to this current behavior of the fields.
So for existing websites, where these elements are already set up/deployed, a change like this will bring in a lot of unexpected results, which will then have to be adjusted manually.
While consistency is important, the cost or impact to achieve it, in this case, seems far too great, I'm afraid. This is the reason, our development team has no immediate plans to change how these other field types are saved, through the forms.
I hope this makes it more clear.
regards,
Waqar
Hi Waqar
Many thanks for your help and explanations; I'm sorted now. Bye for now
