tedbow’s picture

I am planning on making a drupal 7 release. I just need to find the time. hopefully I will start the branch this week.

q2_faith’s picture


davidk2’s picture


ryan.armstrong’s picture

Ok, 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)
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/

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.

tedbow’s picture

Thanks for getting this started.
I started a new 7 branch from your patch. I also made some other sql changes.

FreeFox’s picture

Hi 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

mariancalinro’s picture

11.49 KB

Hi everyone,

This is my first patch on, 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,

drupov’s picture


tedbow’s picture

Version: 6.x-1.0-rc1 » 7.x-1.x-dev
Assigned: reza213 » Unassigned

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.


googletorp’s picture

I took a look at the drupal 7 branch and removed some warnings. I also rewrote a query to use db_select.

googletorp’s picture

While 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.

tedbow’s picture

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.

googletorp’s picture

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.

tedbow’s picture

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.

tedbow’s picture

Looking for help with test D7 forms: Issue #1123730: Needed: Sample D7 Webform exports

Great way for non-coder(or coders) to help!

bfroehle’s picture

+++ webform_conditional.moduleundefined
@@ -30,7 +30,7 @@ function webform_conditional_form_webform_component_edit_form_alter(&$form, &$fo
-            $default_value =  trim($extra['webform_conditional_field_value']);
+            $default_value =  trim(isset($extra['webform_conditional_field_value']) ? $extra['webform_conditional_field_value'] : '');

Whoa! This is totally broken! Err, nevermind. Generally I've always seen this as

$default_value =  isset($extra['webform_conditional_field_value']) ? trim($extra['webform_conditional_field_value']) : '';

Powered by Dreditor.

tedbow’s picture

Either 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.

bfroehle’s picture

Status: Active » Needs review
1.85 KB

I've fixed a few more warning which were appearing in MAMP. See the attached patch.

tedbow’s picture

Status: Needs review » Needs work
+++ b/webform_conditional.module
@@ -363,7 +363,7 @@ function _webform_conditional_was_hidden($cid, $components) {
-  if ($components[$cid]['extra']['webform_conditional_cid']) {
+  if (isset($components[$cid]['extra']['webform_conditional_cid']) && $components[$cid]['extra']['webform_conditional_cid']) {

Would this be easier to read and function the same?

if (!empty($components[$cid]['extra']['webform_conditional_cid'])) {

BTW, thanks, I had never seen Dreditor before!

Powered by Dreditor.

bfroehle’s picture

Yes, you are certainly correct that !empty would be a lot easier! :)