This is issue is in response to quicksketch's idea to merge the functionality of Webform Conditional into Webform core.

The end result would be that fields could be conditional on fields on the same page(currently they have to be dependent on a previous page).

Currently Webform Conditional uses Javascript to hide/show fields. It would probably be better to use AHAH.

Also there should probably only be one section on the component edit form for conditionality(currently Webform Conditional adds a separate section called "hiddedn conditional")

@quicksketch I didn't assign this to myself but I could take it on if you want. I think it will have to intertwined with the current conditional logic.

Comments

Title:Merge Webform Conditional in Webform - Conditional fields on 1 pageMerge Webform Conditional into Webform - Conditional fields on 1 page

Also there should probably only be one section on the component edit form for conditionality

I absolutely agree with this. There's no reason why we'd have two sets of conditional options. If the component is on the same page as the conditional field, then we use JavaScript and the method provided by Webform Conditional. If it's on another page, we use the existing functionality.

Currently Webform Conditional uses Javascript to hide/show fields. It would probably be better to use AHAH.

That would be pretty amazing all told, but MUCH more difficult. As another thing to consider, I've branched Webform for Drupal 7 (though I haven't made any commits yet), we should at least consider how this is going to affect the Drupal 7 version, though AJAX is generally much easier in D7 than it is currently.

Any updates guys?.. I'm really itching to use conditional fields with required fields.

Why not just add conditional fields into the webform module as a contributed module to turn on with webform on the modules page?

This would at least merge the two physically, even if it hasn't been done code wise.

Title:Merge Webform Conditional into Webform - Conditional fields on 1 pageMerge Webform Conditional into Webform (support for same-page conditional fields)

Webform conditional as it exists right now is a hack, it won't be included in the Webform project as-is. As I said in #2, it's options need to be merged with the existing conditional mechanism.

if i understund, webform conditional dont work now ????

how to merge the conditional into webform ?

I think it works, I have been using it for a while. Yes it has some problems and the maintainer doesn't replay to some issues since several weeks but in general it is fine.

Webform conditional does a great contribution to enhance the functionality of Webform module but the concern it is written using Javascript, which makes it difficult to merge into Webform. I hope someone has a good programing background helps to push this work forward.

I was in kkaefer's Drupalcon session for the from #states functionality in D7. It seems like that would be a great way to get conditional form elements w/o having to touch JS.

I was in kkaefer's Drupalcon session for the from #states functionality in D7. It seems like that would be a great way to get conditional form elements w/o having to touch JS.

Though since Webform is maintained in-sync between Drupal 6 and 7, using #states is not an option for compatibility reasons until support for Drupal 6 is discontinued.

subscribing

subscribing

Status:Active» Needs review
StatusFileSize
new8.63 KB

I'd like to provide my patch solving problem of fields conditional on the same page fields.
Initially I created patch for Webform Conditional that allows building arbitrary complexity logical expressions as field display conditions and provides GUI for this purpose. (see issue Conditions constructor feature request). This patch works with Webform 2 but as Marat kindly noticed doesn't work with Webform 3. Since Webform 3 already has own conditional fields engine and Webform Conditional module is on the way to be merged into it, it seams to better implement this feature as part of Webform module. My patch follows general Webform Conditional way, so I decided it's logical to submit it to this issue.

Ok, now about patch ideas.

1. I prepared jquery plugin le (logical expression) that includes $.le.expression class with API for expression building and evaluation, $.fn.leConstructor plugin component with GUI for conditions constructor and $.fn.leConditionalForm plugin component for client-side conditional form processing. This javascript was main work to get module work with complex expressions. After client-side build serialized expression is stored in hidden field representing one of component properties.

2. Plugin works currently with operations =, >, <, >=, <=, 'starts from', 'ends with', 'contains','empty', 'one of' (and this set is customizable), so expressions like

!(text1 is empty) AND (text2 > 3 OR select3 starts from 'my')

are possible.

3. All conditions evaluation is done on client side. It allows handling dependencies both for one-page and several pages fields Previous pages answers are just from $form_state['storage'] and provided as JS settings to client side. So I cannot see cause to duplicate evaluation on server side. Wish to follow Drupal way and be friendly to browsers without javascript doesn't make sense in this case because dependencies on the same page fields cannot be implemented without javascript. I don't think also it's better to solve problem with AHAH instead of pure client-side javascript. It's better to avoid additional server calls where it's possible.

4. There was preparation in code of Webform Conditional module to functionality of optional mandatory fields - fields, that should be considered mandatory in case they are visible. I completed this functionality in following way. To avoid chains of expression evaluation on both client- and server-side, all evaluation is done only on client side and pass fields that need to be considered as mandatory in current situation through hidden field

5. Little enhancement to be considered. Conditional section on component form is collapsed if there is no expression defined and not collapsed otherwise.

I'll be glad to hear any feedback

Thanks @ogorun for such great work. I am not sure if I applied the patch correctly, however it does not work with me. I applied the patch manually but still no luck. I think this file "le.conditionsConstructor.js" is missing.

StatusFileSize
new374.65 KB
new54.38 KB

Sorry for invalid patch. Here is fixed one

Thank you @ogorun, It works now with numbers, but letters seem not recognized.

For the select option, for example, the format of options can be something likes:

1|Male
2|Female

When I put the condition for this element contains: 1, the component will be visible only when the first option is selected. However, if I put the condition for this element contains: Male, nothing changes upon selecting the first option.

Also, the job of "Negated" option is not clear for me. The conditional rules will be negated when no expression or element are added.

I really appreciate the work here, but I'm not comfortable with all this conditional logic being moved to the client side. With client-side conditional logic, that means that it can very easily be hacked through Firebug. Turning off JavaScript entirely will have odd effects of leaving certain fields required (or not required) even when they should be, since the hidden field isn't being toggled as the user fills out the form. If we take this approach, we need to ensure that validation is done on both server and client side. My preference would be to do all the validation server-side and trigger AJAX request when the target conditional fields are being changed, then update the form through AJAX. This eliminates the need for client-side changes at all and ensures consistent theming of things like the "required" asterisk.

subscribing

subscribing

subscribing

@Marat,
1) Problem you speak about is actually the fact that patch works with keys but not with option text (doesn't matter whether keys and texts represents numbers or letters). I agree that it's more user friendly to work in constructor GUI with option texts than with keys. It's a good enhancement and I'll implement it soon.
2) Negate option like in original Webform Conditional module states for logical operation NOT. So to construct expression

!(text1 is empty) AND (text2 > 3 OR select3 starts from 'my')

you will check 'Negated' checkbox near (text is empty) expression component

@quicksketch, thank you for feedback. You take into account three rather important things: hidden conditional mandatory fields consistency for browser without JS, possibility to hack logic implemented on client-side and consistency of required field theming.

First issue can be fixed without problems with checking that JS is enabled. For example, we can put one more hidden field with name "js_enabled" with default value of 0 that is switched on to 1 by JS on client side. By the way, Drupal already sets cookie has_js so this cookie also can be used. Just I'm not sure not whether Drupal can work in browser with switched off cookie and keep session another way ($_GET).

Second point - possibility to hack logic implemented in JS - is more serious. You are right. It's possible. But here we speak about not site security but just module behaviour consistency. I cannot see cause somebody will do it. May be I'm missing here something important. Will be glad to here feedback about this point. If it is more important than I think Webform module really need to provide validation on sever-side also.

Mandatory sign theming flexibility I would solve making it configurable on plugin and module level. I agree that such approach is less elegant and requires from Drupal site developer additional work and be glad to find way to take into account current theme theme('form_element') implementation on level of module webform. I'll investigate this possibility and will be glad to hear new ideas in this direction.

Despite the fact moving logic to server-side with AJAX helps to solve these problems, I think client-side conditions evaluation has more than serious advantages.

1) Cient-side evaluation is always more quick because conversation with server isn't involved
2) It allows avoiding additional load to server caused by unnecessary requests. Both load and related to it site pages response time are significant for every Web solution and rather often are problem for Drupal sites
3) Paradoxically but client-side evaluation allows supporting of browsers without JS more than AJAX-based. If in initial form state there are not visible fields on the page AJAX-based solution won't allow user to view and fill them in at all even when value of trigger fields is changed so user cannot use the form. With client-side evaluation when JS is off all fields are visible and can be filled that is for my opinion better downgrade

Please excuse my intrusion and ignorance in programing, I would throw my opinion here. Even @quicksketch raised very important points in #15, I would agree with @ogorun in #19 where using cient-side is faster and better for the server load. In term of security, I don't think this is an issue because Webform is generally used for collecting data and not for exposing them. Nonetheless, a simple code can be used to check if JavaScript is enabled, such as <script type="text/javascript">, if not go somewhere else.

I may be wrong!

I have to agree with quicksketch in #15 regarding the server-side validation. It's important that a form with mandatory fields (even if just for collecting data) not be able to be hacked and have a mandatory field be able to be skipped.

I know it could add a little more programming, which also means more time to complete, but to make a robust and integral module I think this is something that shouldn't be skipped on, unless something can be done to insure that validating conditions on the client side can't be hacked in a method such as Firebug...

StatusFileSize
new3.02 KB

This patch is against Webform 6.x-3.0-beta5.
Do not use this file, I didn't make a recursive patch, so this patch is missing a file. Use #24 instead

@robbertnl, I applied the patch but still facing a problem with mandatory fields. The patch in #13 works with me but when javascript is disabled the conditional fields are not hidden anymore and they must have values if the mandatory is set.

Currently, I forward the visitors to a different page when <noscript> is detected by <script type="text/javascript">. So, having JavaScript turned on is required to view the webform. I know this is not a good solution but it is temporary.

StatusFileSize
new3.09 KB

Oops, i forgot a file. This should work. Btw: this is another approach compared to #13. This is server-side

Title:Merge Webform Conditional into Webform (support for same-page conditional fields)Unable to remove Webform Conditional value
Version:6.x-3.x-dev» 6.x-3.0-beta6
Category:feature» bug
Priority:Minor» Normal

I apologize in advance if this is not the best place to post this bug report.

I love webform. However, I have discovered by accident that in the current 3.0-beta6 you can not remove a conditional_component value once it is set.

In my case, I have a field called "gender" on page 2 of a form and a single field, "area_of_interest", on page 1. Gender is mandatory. However, when editing gender, the conditional_component became set (even though I did NOT set it) and now I can not "unset" it.

When I edit gender and look in the "Conditional rules" fieldset, it only shows one component, "area_of_interest", with no way to select None or no component. Fixing this may be as simple as allowing the Conditional rules select list to have an empty option so you can save an empty string to the conditional_component string.

I only have a few months experience with PHP & Drupal (but about 30+ years with other languages) and am actually looking in the code to see if I can submit a useful patch for the fix. But in the meantime I wanted to post the problem in case it affected adding the "same page" functionality to Conditional components.

Title:Unable to remove Webform Conditional valueMerge Webform Conditional into Webform (support for same-page conditional fields)
Category:bug» feature
Priority:Normal» Minor

Please file a new issue.

Very nice feature. The conditional form seems to work, however the mail(s) send do not contain the values entered on the form. ref: %email_values. The same result when i want to view a submitted form, no information is shown.

ogorun,
ref my comment #27, I found the error causing the replacable %email_values to be empty.
In file webform/incudes/webform.components.inc, on line 230 (ref webform.zip from #13)
replace:

      _webform_client_form_add_component($component, NULL, $renderable, $renderable, $submission, $format);

by:
      _webform_client_form_add_component($component, NULL, $renderable, $renderable, $settings, $submission, $format);

I have added parameter $settings. This parameter, i think, is not important here. What is important is the position of parameters $submission and $format.

There is stil some work to do here.
- When the form is re-displayed because a mandatory field is not filled in ALL fields are visible, not only the ones for which conditions apply.
- In the submission e-mails and the submission view online all fields are displayed. Only the applicable fields should be visible.

@hovel, thank you for feedback. I didn't have time to work on this patch last time. I hope, these weekend will result in patch improvement

subscribing

subscribe

Sorry, I didn't understand if this feature is already available in webform 6.x-3.beta6.
Is there any documentation about it?

Same-page conditional logic is not in Webform 3.x yet. If it were, this request would be marked "fixed". Webform 3.x does contain conditional logic as long as the Webform is multiple pages.

subscribe

subscribing

Subscribe

Subscribing. I could really use this.

Subscribe

Subscribing.

subscribing

Subscribing

Subscribing

Subscribing

I am sure if there was any progress or updates on this, something would be posted... but I am going to inquire anyways.

I come from an .asp world... but am learning more PHP each day. Is there anything someone can do to help this progress along? Or if there was some "sponsorship" money would that help?

Subscribing

Subscribing

Subscribing

Subscribing.

Hi, I am the creator of Webform Conditional. I have just made a major update for the module b/c someone has sponsored changes to it.

I have added Conditionally Mandatory fields. These fields will be required if they are shown. Unfortunately to get the consistent asterisks for required fields it does require overriding theme_form_element in your theme. I have an example of this in the module readme file. The required input of the Conditionally Mandatory fields is validated on the server side(hopefully making my module less hackish ;) ).

I have also updated/improved the Javascript files. Generally I hope the module has been approved all around.

I believe the changes should fix most of the current issues in the issue queue for the module. I am asking for volunteers to review the issues I have marked "needs review". You can find them here.

In a perfect world I would love to work on merging this with Webform but generally I am working on this module in my spare time(unless someone or a group of someones wants to sponsor this effort). I think merging the module would be a large effort b/c quicksketch would want the mechanism changed from the current client-side jQuery show/hide to AHAH. I fully understand why this would be preferable it is just a matter of how much time I can realistically take away from my paid work. Also would it make sense to keep this module separate for Drupal 6.x and work on merging with the Drupal 7 version of Webform?

Perhaps one alternative to merging the module would be for me change
how I alter the component edit form to make it more obvious when you use my version and when you use the built in conditional rules.

Maybe making the 2 field sets

  • Conditional Rules(Same Page)
  • Conditional Rules(Multi-page)

In this case I would only change the title of the exisiting Fieldset, adding (Multi-page).

Priority:Minor» Normal
Status:Needs review» Needs work

Also would it make sense to keep this module separate for Drupal 6.x and work on merging with the Drupal 7 version of Webform?

Right now we're maintaining the 3.x branches in sync (as we did with the 2.x branches). So any features that Drupal 7 gets in the 3.x branch Drupal 6 will also receive (until we start on Webform 4.x, which will be for Drupal 7/8). So most likely this feature would be implemented in both D6 and D7 no matter what.

Maybe making the 2 field sets
* Conditional Rules(Same Page)
* Conditional Rules(Multi-page)

This doesn't make much sense from an end-user perspective. There's no reason why we'd need two fieldsets for the exact same purpose. One fieldset that controls both should be no more difficult than two.

I think you're right that the "best" solution here would still be an AHAH/AJAX solution, so that you can have large segments of the form conditionally loaded. It also makes handling required fields "automatic", since they're not going be validated if they're not on the form at all.

I don't think this is a comparatively difficult feature to add, but like tedbow, I also haven't had time to work much on Webform recently. It's nice that Webform Conditional can be used in the mean time, but obviously the ideal situation would be including this functionality directly in Webform.

Subscribing

I try the #13 solution, it's work but there is a "." in plus, when it send the email the path is "< confirmation >sid?=x"
and in the result pages i receive an error
" * warning: include(./sites/all/modules/webform/templates/webform-results-submissions.tpl.php) [function.include]: failed to open stream: No such file or directory in **********/includes/theme.inc on line 1066.
* warning: include() [function.include]: Failed opening './sites/all/modules/webform/templates/webform-results-submissions.tpl.php' for inclusion (include_path='.:********') in **************/includes/theme.inc on line 1066."

So the email will be blank
EDIT:
i copy the original template: webform-results-submissions.tpl.php
for the email i must use the $value[field], now is acceptable, but the result (submission) page doesn't display result, i must go to the table of result for see the submission

Subscribe

subscribing

Status:Needs work» Postponed

I thought I should announce the first beta release of the Webform Conditional module on this thread. Right now merging of this module is on hold. I have focused on making Webform Conditional a stable, useful module.

I have addressed some issues that I think were drawbacks in the module:

  1. Mandatory fields are now handled the same whether they are controlled by Webform Conditional or Webform. There is no longer a "conditionally mandatory" setting. If a mandatory field is hidden on the form it will not be required. This also makes the themeing of required fields consistent(see #15). There is no longer any need to implement themeing functions for this.
  2. The component settings for Webform Conditional are now in the same format as the regular "Conditional Rules".
  3. There are still 2 fieldsets for Condtional Rules. They are labeled "Conditional rules (Same Page)" and "Conditional rules (Previous pages)"(I don't alter anything but the fieldset title). Regarding quicksketch's comment in #51 about having 2 fieldset - these aren't really for the "exact same purpose". I have found scenarios where one component could be controlled by both kinds of conditionality.(I will make a demo form of this.)
  4. Regarding firebug hacking #15.Validation for all elements now happens on the server-side. If a component should be hidden because of the value of it's trigger component or because it's fieldset should have been hidden then the input is cleared on the server-side.
  5. Components that were hidden do not appear in the submission display or the submission emails.

I would like to make this module a "Release Candidate" and a regular release as soon as it is ready. Over 700 sites are already using this module. I know some user are using on production sites(not my idea).

I would like any help in testing and reporting bugs in the issue queue. Useless I have forgotten to add absolutely necessary functions to the module I will not be adding new features until I have an initial stable release.

I have started documentation but could use help with documentation also. See the issue here: Need for documentation.

You can try a demo of some of functions here: Webform Conditional Demo Form

Thanks for your help and feedback.

Hm, well I have to say that I'm disappointed that effort continues to go into Webform conditional instead of building this functionality directly into Webform, but to each his own I suppose.

There are still 2 fieldsets for Condtional Rules. They are labeled "Conditional rules (Same Page)" and "Conditional rules (Previous pages)"(I don't alter anything but the fieldset title). Regarding quicksketch's comment in #51 about having 2 fieldset - these aren't really for the "exact same purpose". I have found scenarios where one component could be controlled by both kinds of conditionality.(I will make a demo form of this.)

I don't really see how this isn't the exact same purpose. If a field is dependent on another field, it doesn't matter if that field is on a previous page or the current one. Now if what you're describing is a situation where a single field is dependent upon multiple fields, that's a different problem that both same-page and separate-page conditionals would share.

quicksketch,
I understand your disappointment but pretty much its like I said before:

In a perfect world I would love to work on merging this with Webform but generally I am working on this module in my spare time(unless someone or a group of someones wants to sponsor this effort). I think merging the module would be a large effort b/c quicksketch would want the mechanism changed from the current client-side jQuery show/hide to AHAH. I fully understand why this would be preferable it is just a matter of how much time I can realistically take away from my paid work.

I made a calculation that it would take much less time to get the current module finished then it would to totally rewrite the module using AHAH and intergrate it into Webform. I made a choice that I was willing to volunteer only so time to this general effort. Maybe I will more time in the future to work on an AHAH integration.

As far as removing the duplicate fieldset I am open to suggestions/ideas.

Re: quicksketch's comments in #57

I made a small change to my module and removed the "Conditional rules (Same Page)" field set. There is now only 1 "Conditional Rules" fieldset. I just add the current page usable components to the exsiting listbox.

I agree this is much better. Especially b/c it limits each component to having 1 controlling component. Hopefully this will make it easier to merge the module eventually when I or someone else has time.

See: http://drupal.org/node/1053790

Version:6.x-3.0-beta6» 6.x-3.x-dev

maybe it's really better to separate conditions from the module, probably without merge a conditions could grow more to be more sophisticated

Question. Why are we comparing Webform Conditional module to the "Built in" webform conditionals? Webform doesnt even have such a feature. This is completely confusing. I have Webform 3.x (Dev) and the only possible way to get working Conditionals was to install the Webform_Conditional module. Where are the built in conditionals for webform because it's certainly not clear to me where they would be hidden.

Where are the built in conditionals for webform because it's certainly not clear to me where they would be hidden.

When editing any component, there is a field set for "Conditional rules" at the bottom of the component form. These only work on multiple page forms currently.

Hmm I didnt even realize this, and if this is the case, then I can totally see why separating them into separate fieldsets would be beneficial (even if it does look dumb on the webform edit page). If they are combined and there is a bug discovered, how will I know which module's issue queue to use? I wouldnt, because they are both listed the exact same way and there doesnt seem to be any discernible difference between them atm. So for me, if there was an issue with the multiple page conditionals I was using (which I didnt even know I was using because I always install conditional module), I would have totally went over to his module and added an issue there when in fact it would be the wrong place to do so and he'd probably be bangin his head against the wall saying, thats not possible, I dont do xyz with this module. So as a user, I'd actually prefer that they be split out until they both use the exact same codebase (which sounds to me like it could be quite some time since neither of you has the time/resources to combine them atm without sponsorship which is a completely valid explaination). But even though I know now that the way to tell them apart is to check to see if they are multipage or not, others may not even know that like myself and go report things where they shouldnt be.

how will I know which module's issue queue to use? I wouldnt, because they are both listed the exact same way and there doesnt seem to be any discernible difference between them atm.

Which is exactly why they should be merged, which is what this issue is all about. :P

Ok for the time being I have added a better description on the Webform Conditional project page that describes Webforms built in conditional fields in contrast to same page conditional fields.

http://drupal.org/project/webform_conditional

I have also changed the page title to "Webform Conditional (Same Page Conditionals)" to hopefully avoid confusion.

Subscribe

Subscribe

That makes things much clearer, thanx tedbow.

subs

Status:Postponed» Active

I really would like this implemented properly onto Webform.

Drupal should really add a Groupon type system where someone is willing to sponsor to do a project for X amount. And if 30 people sign on, it´s a full go. Costs everyone a couple of bucks and the developers gets his time paid for. Slippery slope, I know, but darnit, money makes the world go round...

Suscribe

@MWiz there's a solution in the works here in Brazil just for that kind of crowdfunding. if you'd like to know more, please drop me a line and I'll put you in touch with the folks.

Assigned:Unassigned» vernond

I'm volunteering to effect the merge of Webform Conditional into Webform because it is valuable functionality to have out-of-the-box.

Time estimate is 3-4 weeks (i.e. around 20 March 2012) as this development happens outside of my day job hours. I will first handle D7 and tackle the port to D6 when happiness abounds i.t.o. D7 patch (yes, I know the original post was for D6, but my preference is to do D7 first).

Fantastic! Looking forward to it vernond!

Let me know if you need help or have any questions. I wrote the Webform Conditionals module. Feel free to contact me.

@tedbow: thanks, will do - you're on my speed dial :-)

will be cool if you can do this for D7 - realise that taking on something like this around your day job can be troublesome - hoping you are finding some time to have a whack at it

@petednz quicksketch has made a solid start on this over in #1215456: Multiple and same-page conditional rules. But rather than a merging of webform_conditional it is a complete reimplementation of conditional components for inclusion in webform core.

sweet - thanks for the pointer fenstrat - hadn't spotted that issue.

Status:Active» Closed (duplicate)