Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
is there any solution or release to use the Webform Conditionals module on Drupal 7?
Thanks,
Reza
Comment | File | Size | Author |
---|---|---|---|
#18 | 1093334-fix_more_warnings.patch | 1.85 KB | bfroehle |
#11 | 1093334-11-removed-warnings-added-alter.patch | 5.37 KB | googletorp |
#10 | 1093334-10-removed-warnings.patch | 4.7 KB | googletorp |
#7 | 1093334-drupal7-7.patch | 11.49 KB | mariancalinro |
#4 | drupal7_initial-1093334-1.patch | 12.54 KB | ryan.armstrong |
Comments
Comment #1
tedbowI am planning on making a drupal 7 release. I just need to find the time. hopefully I will start the branch this week.
Ted
Comment #2
q2_faith CreditAttribution: q2_faith commented+1
Comment #3
davidk2 CreditAttribution: davidk2 commented+1
Comment #4
ryan.armstrong CreditAttribution: ryan.armstrong commentedOk, here is an initial patch that address most of the issues that Coder rasied. There are still two issues that I couldn't figure out:
Line 5: Module .info files must now specify all loadable code files explicitly. (Drupal Docs)
dependencies[]=webform
Line 74: Parameters to hook_form_alter have changed.
function webform_conditional_form_alter(&$form, $form_state, $form_id) {
But I modified the .info file to work with Drupal 7, updated all of the behavior calls in webform_conditional.js to use 'attach:' and D7 no longer uses db_query to do updates, so I changed it to use db_update. There is a comment that wonders if using update can't be done due to serialized data. This may or may not be an issue in Drupal 7 like it was in Drupal 6, but we should look into this. There were also a couple of other changes that you can see in the patch.
Activating the patch seems to go fine, but when I try to add a select list I get this error:
Recoverable fatal error: Argument 2 passed to db_query() must be an array, string given, called in /Applications/MAMP/htdocs/drupal7/sites/all/modules/webform_conditional/webform_conditional.module on line 407 and defined in db_query() (line 2213 of /Applications/MAMP/htdocs/drupal7/includes/database/database.inc).
Perhaps we can get a 7.x branch with my patch rolled and I'll start opening up issues in the D7 branch like the above one.
Comment #5
tedbow@ryan.armstrong
Thanks for getting this started.
I started a new 7 branch from your patch. I also made some other sql changes.
tedbow
Comment #6
FreeFox CreditAttribution: FreeFox commentedHi tedbow,
I'm very happy to see something happening ;)
As always & everyone I have an urgent need to have a 7 version because for some things I need I have to upgrade to D7 but I can't because not everything is available in D7. Webform conditionals is 1 of them.
Hope to see a first D7-dev version soon so I can start testing.
Thanks in advance
Freefox
Comment #7
mariancalinro CreditAttribution: mariancalinro commentedHi everyone,
This is my first patch on Drupal.org, so i'm not entirely sure i did everything right.
Anyway, i needed this functionality for one of our clients, and i figured why start from scrach, when there is a working module and all i have to do is upgrade it.
I rewrote some of the functions in the js, because it was giving errors about Drupal.behaviors.webform_conditional.getWrapper not being a function, so i moved all these helper functions out of behaviors, into Drupal.webform_conditional.
Also in the php code there were a few databaseAPI errors, and the main thing is that the module was checking for ['#post'] in the elements to trick the validation, only that there seems to be no more ['#post'] in D7, so i replaced that check with a check for $form_state['input'], which is empty when the form is created, but afterwards it contains all the elements in the form.
Hope this helps someone, if not it definitely helped me.
Thanks Ted for a great module,
Calin
Comment #8
drupov CreditAttribution: drupov commentedSubscribe
Comment #9
tedbow@mariancalinro,
Thanks for your work on this! I have applied this to the 7 dev branch. I have also made dev release for 7.x.
I made some changes to the branch after you patch to bring in the JavaScript improvements that I have made in the 6.x.
tedbow
Comment #10
googletorp CreditAttribution: googletorp commentedI took a look at the drupal 7 branch and removed some warnings. I also rewrote a query to use db_select.
Comment #11
googletorp CreditAttribution: googletorp commentedWhile I was at it, I noticed I needed a way to tell Webform Conditionals about my own type of form field which functions much like a the select.
So I added a function and a hook_alter to allow other modules to change which form field types should be able to be used as a conditional trigger. I've included the changes in the patch of #10 in this one.
Comment #12
tedbow@googletorp
Thanks for these changes I have committed these to the D7 branch. I have also added these changes without the new D7 database stuff to the D6 branch. I am trying to keep them alike as possible.
I changed the drupal_alter call a little bit. Fieldset, and pagebreak components are actually possible trigger components. I just select those in the query so that I determine trigger components that should be available(i.e above the current component on the same page.) If I left them in the alter call it would be possible to remove them which would be bad.
One note of caution about the new alter: This will allow adding trigger components that will not work with the current Javascript. Right now I don't plan on adding support for extra javascript calls.
@googletorp, In your case do your component types work with the current javascript?
Thanks again for the help and feedback.
Comment #13
googletorp CreditAttribution: googletorp commented@tedbow
Sounds great.
About the JavaScript, it works just fine for my custom component. It act just like the select component when rendered. It's used to create a single place for adding options for the components, which then can be enabled/disabled for each instance.
I think it's fine to let people handle the JS themselves if they add a special component that doesn't integrate with what the JS that this module supplies.
Comment #14
tedbow@googletorp
Cool. I just wanted to put that note there for others to read. Maybe I should put a comment in the code before the the drupal_alter call? I could see someone adding textfield to the array and it not working. I agree that it is good to provide the alter though.
Comment #15
tedbowLooking for help with test D7 forms: Issue #1123730: Needed: Sample D7 Webform exports
Great way for non-coder(or coders) to help!
Comment #16
bfroehle CreditAttribution: bfroehle commentedWhoa! This is totally broken!Err, nevermind. Generally I've always seen this asPowered by Dreditor.
Comment #17
tedbowEither one will work but actually, your second example would be a little more efficient b/c the "trim" function would only be called if "isset" returns true. Where as the first example would call trim either way, meaning it would sometimes be called on literal empty string.
Comment #18
bfroehle CreditAttribution: bfroehle commentedI've fixed a few more warning which were appearing in MAMP. See the attached patch.
Comment #19
tedbowWould this be easier to read and function the same?
BTW, thanks, I had never seen Dreditor before!
Powered by Dreditor.
Comment #20
bfroehle CreditAttribution: bfroehle commentedYes, you are certainly correct that !empty would be a lot easier! :)