[Gelöst] How to hide a custom field group but still submit the data?

[Author]

Artikel

[Steve Palm]

Tell us what you are trying to do?

We had this working, or at least I thought we did. However, the problem is that on our "Edit a Listings Page" we have some javascript that watches for the geocode to be done, and then updates values in custom fields on the page to save specific information we need. When the page is submitted, we use that data to make further updates.

It seems that now (unsure when this stopped working) the data for the custom fields is not being submitted. It may be related to the group of fields being hidden by a condition, but how can we have it both ways? We do not want the fields to be displayed but at the same time we do want the data submitted.

I found this older thread which seemed to be a similar type of problem, and in their case they removed the condition, but we would like those fields to be hidden:

https://toolset.com/forums/topic/types-custom-field-disappears-after-page-editor-loads/

I did just confirm that if the conditional fields are not hidden, the data is submitted.

Is it possible through the form editor to put these fields in some other kind of group with a CSS class name that we could set to not display? I tried using the custom HTML block before and after and put in a DIV with a class name surrounding the block of fields, and then in CSS set it to display: none; but they still appear on the page.

I inserted in the HTML block above the group of fields:
<div class="hide-cmid-custom-fields">

And in the lower block after the group of fields:
</div>

But in the rendered HTML I see:

<div class="hide-cmic-custom-fields" style="/* display: none; */">
</div>

And it seems that down lower the </div> is inserted but it is hard to know for sure what is putting it there. I tried to include comments in the custom HTML blocks but they are being stripped out as well.

I am submitting this now to hopefully speed resolution, but if I find more information I will come back to add it.

What is the link to your site?

versteckter Link

If you still have your admin login, a test listing I am working with is here:

versteckter Link

Otherwise I can provide another dump of the system.

[Steve Palm]

I don't really have anything more useful to add, although I tried a lot of things and nothing has worked. This had to have been working before with the conditional fields, although if you look at our last ticket there was an error in the conditional, it was set as "( false )" and it caused problems with PHP. We fixed that with a properly formatted conditional. So maybe before, under PHP7.4, that conditional was somehow hiding the fields but still allowing the data to be submitted? Strange.

My current thought is to remove the conditional group and the fields and try to get some JavaScript to insert some hidden input fields with the right names and insert our data there. I don't like that as much because there is no visibility, you can't see it in the GUI form designer, it is easy to lose track of what fields are in there, etc... It would be much easier if Toolset would just allow us to have the fields submitted and still have a way to hide them from display.

UPDATE: Even if I were to inject other hidden input fields, would Toolset even pass those data values in the form back to the target PHP?

[Steve Palm]

Thanks to the fact that nobody was able to get to this to answer me, it allowed me to stretch out a little bit and experiment with not only setting up a local copy using WP Migrate Free and Local by Flywheel (been meaning to get to trying that), but also to try my suggestion, and that is to remove the conditional group from the forms and use Javascript to dynamically insert fields into the form to contain the data we need. That is not meant to be an insult, it all worked out in the end, and I know your team is quite busy.

This is rather ugly right now, as very little sanity checking, but this site is pretty static in terms of updates/etc, so it will work for the short term. If you have a better solution, though, I would love to hear it.

I enqueue the script only on pages matching a URL path of the add or edit listings page. I can/could/should do a much better job at verifying where/how the fields are inserted, that it is the right form with the right data/etc, but for now.... I could also use a tempate string and just insert the field name/etc., but this was a quick test to get things up and running and it worked. 🙂 The relevant portion of that script is:

( function( $ ) {
    $( document ).ready( function(){
        let elNonce = document.querySelector('input[name="_cred_cred_wpnonce_cred_form_1007_1"]');
        if ( ! elNonce ) {
          elNonce = document.querySelector('input[name="_cred_cred_wpnonce_cred_form_1022_1"]');
        }
        let html = '';
        if ( elNonce ) {
          html = '<input type="text" name="wpcf-street-address" style="display:none;">';
          elNonce.insertAdjacentHTML('beforeBegin', html );
          html = '<input type="text" name="wpcf-geo_city" style="display:none;">';
          elNonce.insertAdjacentHTML('beforeBegin', html );
          html = '<input type="text" name="wpcf-geo_state" style="display:none;">';
          elNonce.insertAdjacentHTML('beforeBegin', html );
          html = '<input type="text" name="wpcf-geo_postal_code" style="display:none;">';
          elNonce.insertAdjacentHTML('beforeBegin', html );
          html = '<input type="text" name="wpcf-geo_country" style="display:none;">';
          elNonce.insertAdjacentHTML('beforeBegin', html );
        }
})( jQuery );

Then in the PHP that handles the form submission the data is in $_POST just like it would have been otherwise. It doesn't have all the cred form stuff, but it makes it through which is the important part for now. Then I can catch it and update the postmeta and other things we need to do.

[Minesh]

Hello. Thank you for contacting the Toolset support.

Yes - it seems it was really busy when you created the ticket. Please let us know if you will require further assistance.

[Steve Palm]

I would ask you to please consider looking at my problem and see if you have a better solution that would be all done/managed in Toolset without needing to hack away with Javascript.

[Minesh]

Well - it depends on what custom fields you set as depended and also required. If you set your fields as required and you want to still submit it while wrapping it with div that has display:none; style added it will not work as the field is required, so logically it is not correct.

I need problem URL where I can see the issue (you can comment out your custom JS code for now) and send me all details what fields you want to submit with your form while hiding them.

*** Please make a FULL BACKUP of your database and website.***
I would also eventually need to request temporary access (WP-Admin) to your site. Preferably to a test site where the problem has been replicated if possible in order to be of better help and check if some configurations might need to be changed.

I have set the next reply to private which means only you and I have access to it.

[Steve Palm]

Ok, well, it may not be worth all that hassle right now honestly.

The fields were not required at all, and in fact had no information entered on the page. I was hooking in via JavaScript to the Google GeoCoder response, then pulling specific places data out and inserting it into those fields prior to the form submission. This was working fine in the past, but now, for whatever reason, if the conditional group containing those fields had a condition where they were not displayed it also prevented those fields from submitting their data to the form. If I simply changed the condition so they would display, then everything worked fine, and as soon as I change the condition again so they would not display then they stopped being submitted.

It seems a design change, but probably on purpose. If so, then I guess there is no way (as there are no settable options) to have a group of fields in a conditional block where they do not display (because the condition is false) and yet still have their data flow through to the form when submitted.

If you could verify that set of circumstances on a quick test site spinup, it wouldn't need a copy of our site to do so. Then we would know if that is the true behavior of Toolset out of the box, and then determine if that is the correct behavior (according to docs/specs/etc) or of something changed and it is not working properly.

[Minesh]

Based on your description you shared I still not get where exactly I've to the put fields conditionally and what type of fields.

I can offer you sandbox once its available as currently we have issue with that or you can spin-up a test install where I can check whats going on with your issue.

[Steve Palm]

If you can provide a sandbox that might be easiest, as long as I can create and upload a plugin to log and demonstrate the backend processing and how the fields are missing when they are not displayed. I was going to decline, as it will take some time, but in case this issue is not the desired behavior, and in case it is affecting other customers, I would be glad to help track it down.

[Minesh]

Here is a sandbox site you can use and you can auto-login to it using the following link:
- versteckter Link

[Steve Palm]

I realize that it would be quite a bit of work to duplicate our setup to test it with the code I have. I looked into maybe doing an export/import, but on our site when trying to Export I get this in the error_log file:

[07-Apr-2023 20:42:44 UTC] PHP Fatal error: Unparenthesized `a ? b : c ? d : e` is not supported. Use either `(a ? b : c) ? d : e` or `a ? b : (c ? d : e)` in /home/cmincommunity/public_html/wp-content/plugins/toolset-advanced-export/vendor/twig/twig/lib/Twig/Node.php on line 42

I tried to patch that and also it occurs later:

[07-Apr-2023 20:46:01 UTC] PHP Fatal error: Unparenthesized `a ? b : c ? d : e` is not supported. Use either `(a ? b : c) ? d : e` or `a ? b : (c ? d : e)` in /home/cmincommunity/public_html/wp-content/plugins/toolset-advanced-export/vendor/twig/twig/lib/Twig/Node.php on line 198

I changed them to the a ? b : ( c & d : e ) format.

[Steve Palm]

Hi! Can you make the next reply private so I can provide the testing site location/etc? It might be better if that were not public. I will also do my best to provided you with a description of expected behavior and how to duplicate the problem. The sandbox would have taken too much work to set up so I created a local docker copy of our site that you can test with.

[Minesh]

I have set the next reply to private which means only you and I have access to it.

[Steve Palm]

BTW: That reply is NOT private.. I can view it in an incognito window while not logged in. Thankfully the link is hidden but the post itself is not hidden at all.

[Minesh]

I checked with the following form and I try to submit it:
- versteckter Link

Before submitting the form I change the conditional group condition to = the nonexistent value so the fields are not displayed and those fields are missing from the submitted form data.

But when I checked the backend - those field values are still available with the post even though its not submitted.
=> versteckter Link

The current situation is expected.

So, I would like to know here at what point you are using those fields for processing.

We can use the Toolset forms hooks "cred_before_save_data" or "cred_save_data" hooks to make amendments to the custom fields once you submit the form but the thing here is those hooks will run on server site rather client site. Also - you do not have to run those hooks do you? as when we save the form when those fields are not available but those field value available in the backend.

If you want to still use those missing fields (values) on frontend for with custom JS code then another possible solution would be we should add generic fields and add those fields values to those generic fields.