Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
How to obtain this feature in webform 6.x-3.6?
Comment | File | Size | Author |
---|---|---|---|
#10 | webform_block_pages-d6.patch | 2.61 KB | quicksketch |
#10 | webform_block_pages-d7.patch | 2.61 KB | quicksketch |
#8 | webform_block_redirect-1033090-8.patch | 3 KB | grasmash |
#6 | webform_block_redirect-1033090-6.patch | 3.35 KB | grasmash |
#4 | webform_block_redirect-1033090-4.patch | 2.94 KB | grasmash |
Comments
Comment #1
quicksketchCurrently this isn't directly possible. I think it would make sense for this to be an option in the configuration of the Webform block when you configure the block from admin/build/block.
Comment #2
Giolf CreditAttribution: Giolf commentedOk but in the webform block i see:
The functionality of this module is now included in Webform 3.3. Do not install this module at the same time as Webform 3.x.
Then i think it's a feature for webform 3.x
Comment #3
quicksketchWell I suppose it should say "most" functionality of the module has been included. Webform's implementation of that feature includes more features in some ways too, but this particular use-case has not yet be included.
Comment #4
grasmash CreditAttribution: grasmash commentedThis actually turned out to be a pretty easy feature to add. I've added a new 'Redirect to node on submit' field to the webform block configuration page.
I easily set up a multi-step webform with only the first step exposed in the block:
I wasn't really sure whether to store this variable in the block settings array or in a new column in the webform table.
This patch was rolled against 3.x from git repository.
One point on the patch development: I wasn't really sure whether to store this variable in the block settings array or in a new column in the webform table. It seemed simpler to just add it to the block settings array, but that did require an extra query to grab the block settings array in webform_client_form(). Not sure which query would be most efficient:
or
I went with REGEXP to improve precision.
Comment #5
grasmash CreditAttribution: grasmash commentedoops. changing status. is this eligible for commit?
Comment #6
grasmash CreditAttribution: grasmash commentedquick update. changed description text and git-formatted patch.
Comment #7
quicksketchThanks, this looks like a good patch. A few changes needed:
- Why is this line using REGEXP? We can just do a straight = check.
- Format your comments according to http://drupal.org/coding-standards.
- Remove trailing whitespace from your patch
- Could we change the label "Redirect to node page when webform block is submitted" to "Show subsequent webform pages in block" and have it default to being unchecked?
- Could we come up with a better name for the variable than "multi_step_redirect"? How about "pages_block" (to match this new label)?
Comment #8
grasmash CreditAttribution: grasmash commentedquicksketch-- thanks for taking the time to review this patch and make suggestions. I've made all of the changes that you requested.
With a bit of hindsight, it seems like there's no need for REGEXP query at all. Sometimes it just takes a little distance to see clearly :)
Please let me know if there's anything else that you'd like me edit.
Comment #9
quicksketchPerfect! I'll review the functionality and work on getting this in next time I'm reviewing features for Webform.
Comment #10
quicksketchI've updated the verbiage a little bit ("Show all pages in block" instead of "Show subsequent pages in block") and then committed this version of the patch. The functionality is the same but the code is cleaned up a little bit to make it easier to read (in my opinion) and puts us in a good place if we decide to implement the latest changes being discussed in #250767: #action breaks webform inside another node.
Comment #11
grasmash CreditAttribution: grasmash commentedLooks good to me, thanks for the commit!
Comment #12
eggersrj CreditAttribution: eggersrj commentedI'm using a webform in a block intended to be placed on any node ... for anonymous users, the pagebreak has action set to the webform's path rather than to the current node displaying the block. However, this is only for anonymous users ... when logged in as admin action is set to the node which is displaying the block (which is what I want). I haven't dug too deeply into this yet, but I suspect the set of changes discussed above have contributed to this behavior? Any thoughts?