Get a zero into the database (post_meta) when a checkbox field in a Forms form is not checked and the field is defined as having to produce a zero (i.e. not defined as having to omit any database entry). Because a zero is not produced, I also cannot test for it in a view. The alternative, testing with "different from [checked value]" does not work either, because of the problem described under https://toolset.com/forums/topic/cannot-filter-non-existent-boolean-fields-from-view-blocks/. That issue was answered with a piece of custom code, but I strongly agree with the author of the issue that any boolean which is absent from the database should be regarded as not true (different from true) when referred to in a view block. Could this be made standard behaviour instead of having to use custom code with a filter hook for every boolean? While working on this, I also noticed (my third point) that no field produces any value in the database when it is not used in a Forms form. Again, I would expect all fields to receive their default values when a custom post is created and they have not received other values. Could this be made standard behaviour as well?
Link to a page where the issue can be seen:
Unfortunately we were under pressure to make this work, so the checkbox has been replaced by a radiobox. This allowed us to get a database entry either way, as long as the field is included in the Forms form. It is a workaround, though, it took us quite some time to figure this out and we believe that it should not have been necessary.
I expected to see:
A zero in the database (post_meta) when a checkbox field in a Forms form is not checked and the field is defined as having to produce a zero (i.e. not defined as having to omit any database entry).
Instead, I got:
No database entry in the post_meta and no way to easily filter this boolean.
Hello. Thank you for contacting the Toolset support.
Do you mean that you have created a custom checkbox field using Types and in custom field settings you set the option "When unchecked, save 0 to the database" - is that correct?
So, you now looking for that when you have that checkbox field on your form and when you keep the checkbox field unchecked and save the form from forntend, you expect that 0 should be saved in the "postmeta" table. - Correct?
- If yes: technically you are right but there is not 100% settings sync between the custom field you created using Types from backend and when you add the same field on frontend.
The better workaround would be to use the Toolset form's hook "cred_save_data" or "cred_before_save_data" and add the related code where you should check if the checkbox field is set or not and based on that you should add/update postmeta with 0 using update_post_meta() or add_post_meta() functions.
Thanks for your quick reply. Your description of the situation is correct. However, if I am technically right, as you say, I fail to grasp why it doesn't work that way. In other words, why is there no 100% settings sync between the custom field created using Types from the backend and an instance of this field as used on the frontend? I think what I meant to say was that I would like things to become 100% consistent. It would make using Toolset so much more attractive if it would work intuitively and would not require custom code unless you are trying to do something really special, which is not the case here. It should not even have to be a feature request, because we are not talking about a new feature. For now, I prefer the workaround with the radio box we have found above going through the learning curve for implementing forms hooks. So please have this (my three points) put on the list for further improvement of Toolset.
I understand your point but this will be considered as a new feature request as the request and we as support person do not handle the feature request. The new feature request should be filed using the following form and our product manager will review it and take the decision accordingly.
