Hello,
I've noticed that webform_conditional has some logic in place to check each conditionally hidden field upon submission (after the form is re-built), and apply some clearing logic in an attempt to empty it in case a user accidentally places a value there (e.g. a user shows a field, enters a value, but later hides that same field for some reason). This logic seems to live inside _webform_condtional_clear_element_values(). However, the issue that I've noticed is that this logic does not fully "clear" or "reset" these fields because it does not actually clear the fields' values in the $form_state variable, only in the component details for that specific form field.
My guess is that for most cases these "accidental" entries into conditionally hidden fields are not a huge problem, and that clearing them within the $form_state is not paramount. Still, I'm thinking that, more often that not, conditionally hidden fields should be scrubbed very clean in order to keep the submission data as clean as possible. What's more, if other modules are working with the values submitted in a webform (via their own form submit handler for example), they may depend on the $form_state data for their own processing, which may not be "cleaned up" unless webform_conditional also processes the $form_state within _webform_condtional_clear_element_values().
I've not fully digested how webform_conditional handles clearing logic for accidental entries into conditionally hidden fields, but I have found that manipulating the $form_state values within _webform_condtional_clear_element_values() seems to lead to the kind of results that I would expect. I'll try to bundle-up the changes that I have been playing with, and share them as a patch in hopes that someone can shed some light into the best way to address this.
Ryan
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | clear_conditionally_hidden_fields-1264656-9.patch | 4.14 KB | tedbow |
| #6 | webform_conditional.module.txt | 24.34 KB | joecanti |
| #1 | 1264656-1_clear_conditionally_hidden_fields.patch | 2.11 KB | rjacobs |
Comments
Comment #1
rjacobs commentedAttached is the patch that I have been using, which seems to fully clear accidental entries into conditionally hidden fields, simply by also clearing the $form_state entry for any hidden fields.
Does this seem like a universally useful addition?
Comment #2
rjacobs commentedJust wanted to check-in on this. Any thoughts on the problem as outlined and the patch?
Comment #3
joecanti commentedHi, I'm having difficulty patching the file - probably down to my own inability!
Can you please patch the .module file and then upload it as a .txt.
I'll then rename it and give it a try - I think this is a very necessary feature
Many Thanks, Joe
Comment #4
tedbowrjacobs,
Thanks for this I will try to look at this(along with other issues) this weekend. One thing I was wondering about though is it would better to this without an eval statement. I don't think it is necessary for what this function is doing
Thanks,
Ted
Comment #5
rjacobs commented@joecanti - The patch is relative to the module directory, and you should be able to apply it from that point with
patch -p0 < 1264656-1_clear_conditionally_hidden_fields.patch. Let us know if that doesn't work.@tedbrow - Thanks for taking a look at this. I agree that the eval statement is not ideal, and I too was looking for a way around that. In order to clear the appropriate $form_state entries the patch is looking to the #array_parents array to find the hierarchical set of keys that define form elements that need to be cleared. The keys it needs are values in the #array_parents array, which need to be translated to a set of multidimensional keys (and a dynamic amount of them) which then need to be appended onto "$form_state['values']" to create the correct variable definition for the variable to be cleared. I looked at using "variable variables" (http://php.net/manual/en/language.variables.variable.php) to do this, but they do not seem to work for variables passed by reference. Because of this, and my need to just get a quick fix in place, I saw that I was able to make it work with eval and stopped there (I was up against a deadline on a project). I'm sure there is a better technique for this, and probably an easy one, that I'm hoping someone with a bit more php experience might be able apply.
Comment #6
joecanti commentedHi rjacobs,
I patched it with tortoiseSVN fine in the end - just had to remove the "orig" from the 1st line of the patch because tortoise didn't recognise it.
The problem is it's not clearing the conditional field. You can see an example node here:
http://europa.servers.rbl-mer.misp.co.uk/~songbeec/?q=node/12
Tortoise said it patched the file fine, but I have attached the module file as a txt file if you want to check.
I'm using Webform 6.x 3.14 and webform conditional 6.x 1.0 rc2
Thanks for your help,
Joe
Comment #7
rjacobs commentedHi Joe,
Based on the content in your attached txt file it looks like you got the patch to apply fine. It's important to note that nothing actually gets cleared until the form is submitted. So you won't see any of the conditional sub-options (that were "erroneously" still selected when the user changed the main option that the sub-option was dependent on) being cleared while filling-in the form. You will only see this clearing action after submission within the actual form results.
From what I can see, the main module code always did some clearing upon submission, but it only seemed to work if the page was re-loaded (e.g. upon re-displaying the form while also showing validation errors). The problem was that "erroneous" conditional form entries were not always properly cleared within the final recorded results. This latter issues is all that this patch attempts to fix.
Hope that helps a bit.
Comment #8
joecanti commentedAh I see - it clears it upon submission. I was testing it just playing about with the form - but I guess to untick boxes in hidden options when boxes in visible forms were ticked would probably need something more complex plus a bit of jquery.
I have re-tested it and it works as designed.
The reason for me testing like that was that I'm creating an order form, and I expect people to go back through the form and play with their options in order to get te best deal.
For the purposes of this patch though, I have reviewed it and all seems fine to me.
Many thanks, Joe
Comment #9
tedbowI have attached a revised patch that doesn't require eval but the idea is the same.
@rjacobs thanks for info about #array_parents I am sure it save me a bunch of debugging time.
I patched this against the 6.x-1.x-dev version.
Thanks for any help testing this.
Comment #10
rjacobs commentedAhhh, you are systematically using
=&to point to the right place in the array to clear. That makes much better sense.Comment #11
tedbowrjacobs, let me know if you have time to test it out. I tested it but not on a very complex form.
Comment #12
rjacobs commentedHi Ted,
I tried out your version on a (relatively) complex form with multiple pages, nested conditionals, date fields, etc... and it seems to work just as my previous version did (proper clearing took place upon submit/save/pager). So it's looking like your re-coded version is the way to go.
Comment #13
tedbowComitted:
http://drupalcode.org/project/webform_conditional.git/commit/bb096eefb73...
This is probably an issued for 7x too. I will check.