Closed (fixed)
Project:
Webform Conditional (Same Page Conditionals)
Version:
7.x-1.x-dev
Component:
User interface
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
22 Jun 2011 at 04:12 UTC
Updated:
27 Feb 2015 at 10:30 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
pumpkinkid commentedNot sure why, but my problem is that on multi page forms I can select a choice that should trigger the conditional element and I have to go back to another page and back to the same page beofore it shows up...
not trying to hijack the thread, just not sure if they are related...
Comment #2
revnoah commentedEric, I'm having the same problem. Radio buttons are fine but textareas and textfields are not displaying their field data. If I dig into the webform module, I know the value is there but it isn't getting output. I'm curious to how you managed to solve this.
Comment #3
emcniece commentedDigging back through my installs of D7, I don't think I ever did solve this. Sorry..
Comment #4
revnoah commentedGood to know it isn't just me. I had to hack together a work-around due to a tight timeline but a long-term solution would be preferable.
Comment #5
emcniece commentedI would definitely be interested in hearing your solution :D
Comment #6
star-szrI wasn't able to fix this, but was able to track down the value getting cleared to
_webform_condtional_clear_element_values()which is called only inwebform_conditional_element_after_build().I experimented with changing line 391 in
_webform_conditional_was_hidden():Swapping
$matchedfor!$matchedseems to fix the bug reported here, and makes logical sense to me, but this breaks the saving of the proper webform values. Hidden components with values are saved in the webform results, whereas visible components are not saved.In the D6 version of the module,
webform_conditional_element_after_build()checks$form_element['#post']to determine whether the form is being submitted or displayed. In the D7 version$form_state['input']is checked. I'm not well-versed enough in the differences in the FAPI between 6 and 7 to know whether this is the right approach or not. The multi-page behaviour works fine on the demonstration form which looks to be Drupal 6.Comment #7
tedbowCan someone please post a test form to this issue that has this problem? You find instructions here #1123730: Needed: Sample D7 Webform exports. Please post to the form to this issue thread and not the other one.
Comment #8
plachI have the same problem, it seems it is caused by using the wrong page number: component values are not properly populated and so trigger field values are not correctly interpreted.
Comment #9
tedbow@plach thanks for the patch. Does this fix it for you? Can other please try the patch and see if it fixes their issues? I don't have time to try right but hopefully soon.
Comment #10
plachYes, everything looks ok here.
Comment #11
tedbow@plach, great news. I would still other to try to this patch if they can. Different forms seem to act differently.
Also if someone could post an a test form that gets fixed by this patch, see comment #7, that would be great!
Comment #12
emcniece commentedI can confirm the patch in #8
Tested on Webform Conditional 7.x-1.x-dev (datestamp = "1302569109"), Drupal 7.2
Note the old install - I was saving it :) Can't confirm newer versions yet.
Works great.
Comment #13
tedbow@plach, thanks I have committed the patch to 7.x-1.x-dev.
Comment #14
tedbowComment #15
tedbowmarking as fixed
Comment #17
raulmuroc commentedThe error persists on dependent selectors. for ex:
Selector 1 (sector): Banking <-- when selected banking it appears a second selector
Selector 2 (sub-sector): accountant <-- this is the value choosen.
Then I go one step forward. After that I come back thorugh the webform's multi-step back button, the selector 1 persists, but he selector 2 has disappeared, as well as its value....