Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.To reproduce the bug:
- Create new webform:
- Add a text field.
- Add a page break.
- Add a text field.
Now, set the webform, under form settings->advanced settings to 'Automatically save as draft between pages'.
Now as an anonymous user, enter information onto the first page, then hit the '< Previous' button and notice information is still there.
Add a payment settings component (to the second page), and hitting '< Previous' will bring you back with blank values. Authenticated users don't have this problem.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | 1901434_allow_multi_page_webforms.patch | 547 bytes | gdoteof |
Comments
Comment #1
gdoteof commentedI should note, it is possible this bug is in
payitself.Comment #2
gdoteof commentedMoving this to Pay.
On multi page forms, for example, a 2 page form, with Pay on the 2nd page, hitting a 'previous' button will cause pay_form::form_submit to invoke, even though this is not what the user wanted. This is unsetting the $form_state['storage'] which in turn breaks webform 'save as draft' behavior.
Comment #3
gdoteof commentedthis patch checks to see if webform_pay is enabled as a module, sees if it is relevant for this form, and lastly checks to make sure that this form is complete before submitting payment.
this effectively limits the webform pay component to the *last page* of a multipage form.
Comment #4
gdoteof commentedComment #5
jerdavisI'd like to try to figure out a better method for handling #3. Pay module shouldn't have any code in it to specifically accomodate another module as it's supposed to be a generic API module. Also, this does not resolve the base issue, but rather effects a sort of 'hack' specific to the circumstance of the Webform component. If another module runs into a similar set of circumstances this wouldn't fix the base issue.
I'm open to suggestions on a more generic way of handling this. Perhaps if we set some sort of state flag form-wide which other modules could manipulate? This flag would be set to True by default by Pay and could be turned off till ready by other modules involved, then turned back on during the correct phase of form submission. This is just off the top of my head, I'd have to see an implementation or do an implementation and confirm it with the other maintainers before committing.
Anyone else have any thoughts?
Comment #6
quicksketchQuoting the title itself:
Hah! I didin't even know webform_pay actually *worked* in D7. Seems like my "best-guess" porting actually worked. :)
After looking at all the alternatives (again), I'm back at webform_pay because it's still a better solution than anything else I could find. Glad to see it's working for the most part.
Comment #6.0
quicksketchbeing more specific