Unable to save Default Value for multiple hidden fields

Thanks for the report.

If I add a Default Value to the second form the Default Value for the first form is removed and vica versa.

Do you mean if you add a default value to the second *field* the first fields value is removed?

I just experienced this today as well.

• If I disable the Form builder Webform UI module and I edit the Webform without Form Builder, it's able to save all the default values for all hidden fields.
• If I re-enable it and edit the form components, all but one of the hidden fields show empty default values, which makes me think the issue happens during the load of the form to be displayed by the form builder.

I tried to fix the issue in the code, and provide a patch, but I got lost in a rabbit hole. Sorry!

@stopbox, Are you sure you're using the 1.3 version? The 1.2 version had an issue if you reordered the form, it would cause changed settings (including default values) to be lost. This was fixed in #1772576: Select list options are overridden when moved before saved.

I have one hidden field.

Every time I save the form the default value of the hidden field is lost, unless I have changed the default value.

So the effect of this for me is that each time I save the form I have to edit the hidden field and reenter the default value and then resave the form.

I am using 7.x-1.3.

Got the same problem with 7.x-1.4
Regards

I have experienced the same problem.

Just a guess: It could not load the default value in hidden field when I am trying to edit the web form. If you tried to save the web form afterward, all of the default value of hidden field will be gone whatever you have alter them in database before.

Temporary solution: After you have edited and saved the web form with multiple hidden field, it is recommended to alter the value field, in webform_component with type = hidden. Sound stupid, but it works.

Regards,
Samuel

I have the same issue with 7.x-1.4.

The problem is that when the cache is generated the components have the #value key not #default_value.
This works fine when displaying the form.

If the form is modified the cache is modified so the component contains #default_value.

When the form is saved (but was not edited) we only have the #value key. So, in form_builder_webform_save_node the line:
$component = form_builder_webform_get_component($node, $element_id, $form_cache);
removes the #value from the component because in form_builder_webform_get_component we have:

  if (isset($element['#default_value'])) {
    $component['value'] = is_array($element['#default_value']) ? implode(',', $element['#default_value']) : $element['#default_value'];
  }
  elseif (empty($element['#webform_component']['is_new'])) {
    $component['value'] = NULL;
  }

I'm not really sure which is the best solution. Hope this info helps! :)

This bug causes the hidden field is not useable. Here is my patch. Insert this code to /sites/all/modules/form_builder/modules/webform/form_builder_webform.module on line 181.

// Fix hidden field bug.
if ($element['#webform_component']['type'] == 'hidden' AND isset($element['#value']) AND !isset($element['#default_value'])) {
  $element['#default_value'] = $element['#value'];
}

I ran into the same issue with version 7.x-1.5. The patch in #12 works for me (it properly saves the default values for all hidden fields in the form). Thanks @tm01xx.

p.s. I think I saw a similar issue when activating Options/Customize keys for radio buttons i.e. values are not permanently saved as one would expect.

I've just stumbled into this one too - it makes hidden fields pretty useless.

It's as simple as adding a hidden component (and at least one other), setting a default value, then clicking to edit the other component. When clicking back to the hidden one, the default value is gone.

The fix from #12 only seems to act when the node is saved, but the issue can occur when operating solely on the form builder cache.

So the issue I'm seeing is only to do with loading new/changed default values back from the form builder cache into the config form. I guess this would have been broken by the patch in #1565440: Default values in hidden fields are not shown.

With #12 applied, using the steps I gave in #14, even though you can't see the updated value you entered, it's still in the cache and would be saved correctly.

We're actually experiencing this as a show stopper. We have over 100 webforms. When we change the default value of any field on a form that has hidden fields on it, ALL THE DEFAULT VALUES FOR ALL THE FIELDS BESIDES THAT ONE GET EMPTIED.

We are at the point where we basically have to make changes to a webform from the database. It's actually unclear whether this is limited to forms with hidden fields. We are using 1.5 with Webform 7-4.1.

Not sure if I'm doing this right, it's been awhile since I uploaded a patch.

I wanted to point out that this patch has completely fixed the problem. Please commit this and get it out ASAP? Thanks!

The patch provided in #17 seems to work for me

I changed the title back to "Unable to save Default Value for multiple hidden fields"

whoops.. thanks.. didn't mean to change the issue title :)

There is something completely fishy about how this works in form_builder. The root-cause for this bug is that we use the form-API array (from the components render function) to extract the values for the component. Actually we should work with the component itself instead and see the rendering as a one-way function for the preview only.

Currently it's like a triangle: form_builder properties -> webform component -> form-api-array (preview) -> form_builer properties -> webform component. It should be more like: form_builder properties <-> webform component -> form-api (preview).

And when you say we, shall that be you and I? :) I wouldn't mind pitching in if I was working directly with a project member.

Charles

I haven't had someone special in mind. But I'm happy to help if you'd give it a try. Since I'm not co-maintainer for too long I'd prefer to have some input on this by @quicksketch. This is a huge task though, so it might take some time to get it completed.

Turns out that the assumption that webform components are mapped 1:1 to field-api elements is thoroughly built into form_builder. Changing this would mean nearly a reimplementation which certainly won't happen in 7.x-1.x. I'd vote for doing small steps instead and at least not introduce new code that makes assumptions about the form-api-elements.

Well, at the end of the day, we just need to know we can save components without obliterating a form, otherwise the module almost might as well not exist. I'm not sure what small steps would look like vs. reimplementation, but perhaps if we start with the minimum desirable outcome and reverse engineer the steps necessary to get there, that's the path we take?

Yes that's what I mean. IMHO the path would be to change those parts of the code that make problems to something more relaiable.

+++ b/sites/all/modules/contrib/form_builder/modules/webform/form_builder_webform.module
@@ -178,6 +178,12 @@ function form_builder_webform_get_component($node, $element_id, $form) {
+  // Fix hidden field bug.
+  if ($element['#webform_component']['type'] == 'hidden' AND isset($element['#value']) AND !isset($element['#default_value'])) {
+    $element['#default_value'] = $element['#value'];
+  }

Regarding the patch: I'd prefer to keep component-specific code in the components.inc file.

Most of form_builder tries to read the default_value from $element['#default_value'] but the webform-component for hidden fields renders it's $component['value'] into $element['#value']. There was an existing workaround for this in form_builder_property_default_value_form() but it didn't work. This patch removes the previous workaround and sets the #default_value after loading the component from the webform.

Hey torotil, sorry it took me so long to follow up on this and the classes issue, caught quite the virus!

So I noted form_builder version 1.8 and installed that, along with webform 4.8 and core 7.37. The classes issue (https://www.drupal.org/node/2464957) indeed seems to be fixed. However, with this combination, a worse version of this hidden fieldset bug has arisen. I cannot seem to get more than a couple elements of any kind (hidden or otherwise) to stick after I drag them into a new form and hit save. I might put a fieldset, a textbox, a radio set in and hit save, and the textbox will be gone. I do get a message at the top (but I don't know if it's related):
"A partially-completed form was found. Please complete the remaining portions."

Please let me know if there is any additional info I can provide or tests/patches I can run for you. I'll leave this issue closed on the assumption I'm missing something simple and obvious.

Thanks!
Charles

Big thanks for testing!

The notice is due to a recent change in webform and being dealt with in #2483859: Always shows as a draft.

I've already committed some fixes to 7.x-1.x again. Could you test this with a recent checkout?

Hey torotil,

Just tested it, looks solid! It does still give the message at the top, "A partially-completed form was found. Please complete the remaining portions." with no further explanation (or red highlighting of whatever it doesn't like), but that doesn't appear to affect the functionality of the form.

Let me know if I can be of any further assistance, and thank you!

Charles

Just tested it, looks solid!

Good to hear and thanks again for testing!

Let me know if I can be of any further assistance, and thank you!

I guess with open source projects there is always something to do. I've put some ideas into the project description:

* Triage bugs in the issue queue: Is there enough information for developers to reproduce that issue? Can you reproduce the issue?
* Review & test patches
* Re-roll patches if needed.
* Submit patches for new features.

It seems that I'm the only active maintainer of form_builder at the moment. So I really appreciate any help I can get.

This is a pretty critical module for our project, so I will do what I can. I realistically won't have as much time now as I will when we finish our phased rollout over the summer. I'll stay in touch, I think I'd like working with you on this.