Closed (fixed)
Project:
Webform
Version:
6.x-3.8
Component:
Code
Priority:
Critical
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
28 Feb 2011 at 15:13 UTC
Updated:
24 Mar 2011 at 02:31 UTC
Jump to comment: Most recent file
After upgrading Webform from 6.x-3.6 to 6.x-3.8 my webform containing 2 conditional pagebreaks no longer works as it did before. The attached 3 screenshots demonstrate my scenario:
"01.Form components with 2 pagebreaks.png" shows how the form components are built. First the user must answer a yes/no question. If she answers no, then the content of the first pagebreak will be shown - as shown in the screenshot "02.First conditional pagebreak - OK.png". The user will only see an error message saying that she must answer with yes in order to submit the form and the button to go back to the previous page. This works OK.
However, when the user correctly answers with yes, she only sees two buttons ("Previous Page" and "Submit") but nothing else! The screenshot "03.Second conditional pagebreak - No fields!.png" shows how this looks like.
If you need anything to sort out what's going on I'm happy to provide it. Thanks.
Comments
Comment #1
quicksketchYou're doing something completely unusual in your form. What's up with the second page containing a PHP field that prints a form error? This problem you're experiencing most likely is form-specific, and due to the customizations you have made using PHP code. If you removed such modifications, I think you'll find that it works properly. The 3.8 version made some changes to the way forms are submitted, you'll probably need to adjust your customizations.
Comment #2
roball commentedI appreciate your quick response. However, the PHP code is not causing this problem. I have switched the markup type field on the second page away from the "PHP code" input format to HTML. On the entire webform there is no custom PHP now. The attached screenshot "01.Form components with 2 pagebreaks (No PHP).png" shows how that field looks now (in the overview).
The only difference is that the markup message is now displayed as normal HTML (as shown in the screenshot "02.First conditional pagebreak - OK (No PHP).png").
However when answering yes on the first page there is still no component shown (as shown in the third screenshot in my original post above).
Comment #3
quicksketchCould you Export your node with Node Export module and post it here as an attachment? This will make inspecting the problem much easier than a bunch of screenshots.
Comment #4
roball commentedDone. I've sent you the export code via your contact form.
Comment #5
quicksketchThanks for the export roball. Sorry I also didn't pay attention to the submitter or I would have paid more attention to the original posting. I found that this problem can be "fixed" temporarily by removing the condition on the "Feedback form submitted" page break and just leaving the "Feedback form not submitted" page break condition in place, though obviously this isn't a good long-term solution. I'll look into the code and see if I can figure out what's going wrong here. At this point I'm not really sure how wide-spread this problem is, since obviously some conditional logic is still working.
Comment #6
roball commentedThank you very much for looking into this problem and being able to reproduce it.
I'll try the "temporary" workaround for now.
Comment #7
quicksketchOkay I've found the source of this problem and it does look like our conditional logic is completely broken in the 3.7 and 3.8 versions. The problem was caused by our new submission handling flattening the submission after all pages (effectively creating a $submission object). However our conditional logic was not completely updated to pull values from the new location. This patch adjusts the code to pull from the correct location in $form_state['values'] and moves the flattening code above the page-checking code, so the value can always be found in the same place. Previously some times the values were in
$form_state['values']['submitted'][$parent_name][$form_key]. Now the values are always found in$form_state['values']['submitted'][$cid]as intended.Roball if you can test I'll get this in patch right away. Thanks!
Comment #8
roball commentedI have left the webform node as it was and applied your #7 patch. And yes, this brought the components back on the corresponding condition (in my specific case when the user answers yes on the first page). So it solves a big part of this problem.
However, now the submission results View (node/[NID]/submission/[SID]) is broken: it only shows the component(s) from the first page, but only the field name - without the user's input. All the components from the second (and last) page are completely missing. But I think this should be taken care within a separate ticket.
Comment #9
quicksketchThanks roball. It looks like after applying this patch components on any page but the last page do not get their values saved to the database, which then causes the submission to display strangely since the first page values are missing (which is necessary in order to determine which other values to show). I'm taking another stab at this. Thanks for your testing.
Comment #10
quicksketchThis patch seems to do the trick. I'm testing it out more extensively now, but it looks like it both saves the values properly and handles the multi-page logic correctly. If you can test it out also and let me know what your results are I'd hugely appreciate it. Thanks!
Comment #11
roball commentedBingo - this patch works perfectly! Both the conditional pages and the submission results view work again like they did in version 3.6. Thanks a lot!
Comment #12
quicksketchSweet thanks roball. The 3.7 and 3.8 releases have some other issues caused by my Git ineptitude, so I'll be putting out a new release shortly with this change. Thanks as always for the great report and testing.
Comment #13
quicksketchCommitted and pushed to both 3.x branches. This will be in the shortly to-be released 3.9 version.
Comment #14
roball commented3.9 is working fine again on this matter. Thanks for the quick fix!
Comment #15
quicksketchThanks roball!
Comment #16
rboedeker commentedafter upgrade to 3.9 to fix this issue (multipage / condition issue), the submitted values $form_state['values']['submitted'] in are no longer keyed by their keynames but by their keynumbers. Is this intended ?
Comment #17
quicksketchYep. Prior to 3.7 the $form_state['values']['submitted'] array was by form key name between pages but then by numeric IDs after the final submission. The new version of Webform now executes the submit handlers on all pages for a more consistent submission process.