I have created this module to allow users accessing webforms with multiple steps/pages to be able to skip to different steps/pages of the form, instead of the default functionality of Webform, which requires visiting each step/page of the form one at a time via "Previous" and "Next" buttons.
Project link
https://www.drupal.org/project/webform_skip/
Git instructions
git clone --branch 7.x-1.x https://git.drupal.org/project/webform_skip.git
PAReview checklist*
https://pareview.sh/pareview/https-git.drupal.org-project-webform_skip.git
* There is one warning on PAReview, but the functionality is required to reset the hidden form element used by the module.
Thank you,
Joe
Comments
Comment #2
joecorall commentedComment #3
vernitStill PAReview errors available. Please resolve those.
Comment #4
vernitComment #5
joecorall commentedHello,
Thank you for reviewing! I mentioned in the initial post about the one warning PAReview displays, and that I believe it's a false positive. The
$form_state['input']is only used in order to to reset the value of a hidden form variable: https://git.drupalcode.org/project/webform_skip/blob/7.x-1.x/webform_ski...I am not using the value stored in
$form_state['input']anywhere in the module's code, only resetting it to zero. Is this still a valid concern?Comment #6
vernitYes, As $form_state['input'] was not validated or sanitized.
Comment #7
joecorall commentedI'm not sure I understand. I'm not using the value, it's just being set to its initial value of zero. Why does it need to be validated or sanitized?
Comment #8
oranges13This sounds like a very useful module, though I have some concerns on it's effect on validation of webforms as subverting the linear progression from page to page may mean users skip required information. I'm going to more thoroughly test your module and get back to you on that point.
My other concerns:
hook_uninstall()to remove the variables that you set usingvariable_set.Comment #9
joecorall commentedThank you for your feedback! Please let me know if you find any bugs related to your validation concerns. I've been running this module for one of my site's particular use case, and it's been running successfully. Though for that particular webform, the only required field is on the first page of the webform, and the other steps of the webform are optional.
Re concern #1: I added hook_uninstall(). Thanks for pointing this out!
Re concern #2: I debated this on initial release. I ended up defaulting to "enabled" because I thought enabling the module should enable the functionality. Though I understand your point about the annoyance of having to go to multiple webforms in the event you want to enable the functionality for some multi-steps webforms, but not others. So I added a config form to easily enable/disable the module's functionality on all webforms in the system. On the config form, all the webforms are listed, and to disable you can easily uncheck box(es) and then save. The config form is at
/admin/config/content/webform/skip. Tomorrow, I'll create a new release for this, and will update the project's main page and README.Comment #10
joecorall commentedComment #11
vuilThank you for the contribution!
Please fix all issues mentioned on Pareview checklist page as the following one:
Comment #12
joecorall commentedAs mentioned in the initial post, and comment #5 and #7, I believe this is a false positive. Can you please confirm or deny?
Comment #13
joecorall commentedLink to the code in question is here >>> https://git.drupalcode.org/project/webform_skip/blob/7.x-1.x/webform_ski... <<< thank you for reviewing!
Comment #14
vuilThe issue #11 needs to be fixed.
And, please do not change the status if there is no update into the code.
Thank you.
Comment #15
joecorall commentedCan you please tell me why it needs updated? PAReview says on that page the issue could be a false positive, and I believe it is.
Comment #16
joecorall commentedFrom RandyFay.com
I think PAReview is just not taking this use case into account in its automated reviews of code (hence, the false positive warning it is throwing for this module). This module relies on reseting a hidden form value on a multi-step form, and the only way to do so is to access
$form_state['input']. The module is not using the value in$form_state['input'], which is what would pose a security risk, and PAReview is probably simply looking for instances of that string in the code, not taking into account code that is simply setting a value, not using the value.Comment #17
joecorall commentedComment #18
avpadernoSince the code is reading from
$form_state['values']['skip']and setting$form_state['input']['skip'], there aren't security issue. I would consider this a false positive from PAReview.Comment #19
klausiThanks for you contribution!
"'#value' => 'Save',": all user facing text must run through t() for translation.
Otherwise looks good to me, did not see security issues.
Comment #20
joecorall commentedExcellent! I added t() to that Save button, and pushed to the dev release. Thanks for catching that.
Thanks to everyone for reviewing!
Comment #21
avpadernoThank you for your contribution! I am going to update your account.
These are some recommended readings to help with excellent maintainership:
You can find more contributors chatting on the IRC #drupal-contribute channel. So, come hang out and stay involved.
Thank you, also, for your patience with the review process.
Anyone is welcome to participate in the review process. Please consider reviewing other projects that are pending review. I encourage you to learn more about that process and join the group of reviewers.
I thank all the dedicated reviewers as well.