PLEASE NOTE: These forums are no longer utilized and are provided as an archive for informational purposes only. All support issues will be handled via email using our support ticket system. For more detailed information on this change, please see this blog post.

Dynamically populated hidden field doesn't work at end of the form

  1. I came across a weird "bug" when updating to 1.6. I had a basic form with pricing totals and a hidden field that was my id of a record to be updated. I basically had the following code using the post submission filter to handle the updating of the database.

    add_action("gform_post_submission_23", "change_appraisal_fee", 10, 2);
    function change_appraisal_fee($entry, $form) {
    		global $wpdb;
    		$appraisalID = $entry["4"];
    		$appraiser_rate = $entry["1"];
    		$homebase_rate = $entry["2"];
    		$appraiserRate = str_replace('$','',$appraiser_rate);
    		$homebaseRate = str_replace('$','',$homebase_rate);
    		$table = 'appraisal_rates';
    		$data = array('appraiser_rate' => $appraiserRate, 'homebase_rate' => $homebaseRate);
    		$where = array('appraisal_id' => $appraisalID);
    		$wpdb->update($table, $data, $where);

    Where Field 4 was my ID that was populated dynamically. When viewing the form and using firebug I was able to verify that the ID was indeed getting passed to the form as it showed up as a value. However when the form was submitted, it did not submit the full value. The value was 1795, but the confirmation email I sent up to check it out, showed 195 as the ID.

    To make matters more confusing, I added another hidden field and populated it dynamically with the same 1795. This new field at the end now showed 195 on submission, but the original one that was wrong before now showed the correct 1795 value. I then moved both fields to the top and saved it and low and behold, both hidden fields came in at the correct 1795.

    Has anything like this been reported? I have 70 forms on this site and use this method on almost every single one of them, so I'd like to know if it was a weird situation or if I'll need to check all of them to make sure this won't happen again.


    Posted 12 years ago on Saturday November 5, 2011 | Permalink
  2. One thing to try, with version 1.6 or later, is to use gform_after_submission vs. the deprecated gform_post_submission.

    There were some inconsistencies with the processing of gform_post_submission. Please use gform_after_submission with version 1.6 and forward.

    If that does not resolve your issue, please post a link to your form where we can see what you're trying to do and what might be happening. Thank you

    Posted 12 years ago on Saturday November 5, 2011 | Permalink
  3. I tried it with both and just copied the post submission. The thing that was weird is that the confirmation email contained the incorrect values. It wasn't just my storing of the values through the filters.

    I'd like to post a link to the form, but this is a pretty secure site for my client. I can setup a demonstration or try and recreate it elsewhere. I can also forward the emails I got in the confirmations if that will help you see what I'm talking about. I'm not sure what would be easier.

    Posted 12 years ago on Monday November 7, 2011 | Permalink
  4. Can you export the form and send it to me at ? I can install it and test it.

    Posted 12 years ago on Tuesday November 8, 2011 | Permalink
  5. I installed this form and was not able to recreate this problem. I submitted 12345 for the change_appraisal_fee_id and 67890 for the appraisal_id and both came through perfectly. I tried again with 1795 for both, and they came through too.

    I think you should test for a plugin or theme conflict, or give me a more specific test to try. It's something about your setup I believe, as I have not been able to recreate the problem. It could also be the code you are using to pre-populate the ID, but that seemed to be OK in your tests with Firebug.

    Thank you.

    Posted 12 years ago on Sunday November 13, 2011 | Permalink