Conditional fields

Sounds great. I'll leave open the feature but I have no intention of implementation.

IMHO, this feature would be very, very welcome. In surveys, it is very common to have a multiple choice question where the last option is 'other...' combined with a text field to specify the other value.

Meanwhile, here is my javascript solution for this issue:
http://drupal.org/node/252146#comment-823804
Maybe this approach is a good start for a patch?

This would be a valuable feature - one I am looking for too. Subscribing to this topic :)

A conditional field would be grand indeed! It is on my TODO list as well.... Subscribing.

same here, subscribing

subscribing

Subscribing

so do I

Subscribing

Guys , I've checked marcvangend's solution.

I have to say that is easy to implement and works great.

Possibly a good start to introduce it to the module . . . ??? :0)

hmm, i see people saying "subscribing" but not sure how to do that...

i'd like to be able to have something like the following:

in a profile, there is an option for student or not and then when selecting student there would be new / additional options such as K-12 / College and after selecting that one would be presented with schools in the user's area that can be selected

[off topic] When you add a comment, you're automatically subscribed. New replies will show up on your personal tracker page, http://drupal.org/user/171253/track in your case. [/off topic]

I also have a need for the conditional field(s). We use an application form that requires the user to select a LOCATION. Based on that selection, they choose from a group of PROGRAMS available at that location, and finally, they can select a START DATE for the program.

I am hoping this isn't terribly hard to do; any help would be greatly appreciated.

-Joy

hi rjoy,
I think that the right way is not base the solution in JS, the ideal would refactor webform_form_alter to deal well with conditional forms, also we would need some work in the UI.

giving the number of subscritions I think this feature is critical, also, I'm moving it to Webform 6.x-2.x-dev ok?

As far as I know, 'Critical' means that the module cannot be used if this isn't fixed. That's not the case here.

subscribing

I would find this useful as well.

need this badly

if you want to get this done now just go to www.formspring.com - it works - you can embed the form into drupal looks awesome - has full conditional fields etc... way better than hacking Webform with javascript to do what you want.... for now.

This would be a welcome addition to Webform but it may be a while before there is either a module to do it or webform its self will do it.

J -

>>go to www.formspring.com - it works

It is a service hosted on their servers and it cost money. Free version is limited. Not an acceptable solution for most people.

if you have paying client who needs conditional form functionality its a small price to pay. Integration is seamless. Its good solution till Webform comes around and integrates conditional fields....

subscribing

subscribing!!!

@ #21: if you have paying client who needs conditional form functionality, see if he can pay you for adding this feature to webform!

I agree that this would be a great addition to webform. But for now I try to work around this and adding fieldsets to the form that the user can open if need be. But how do I remove the empty fieldsets from the confirmation mail?

subscribe

Hi,

I too would love to see conditional fields in Webform. While I cannot offer a ready made script or patch, I know of two software projects that have conditional fields implemented:

• LimeSurvey formally known as PHPSurveyor, a web-based survey/questionnaire package. I haven't worked with it myself, but from what I know the conditional fields are implemented more or less like: all questions are numbered and for each question you can add a statement like "if (answer = a) then goto question X" with X > current question.
• Apache Cocoon's CForms block. This is a module of a Java-based webpublishing framework. This particular module allows you to define forms. Each field in the form, as well as the form itself, has a 'validation' section in which you can add javascript snippets. Here you can basically do anything: pre-fill fields based on the content of this field, hide/display fields based on the content of other fields, perform calculations, etc.

I don't suggest that these projects should be re-implemented in Webform, but I do think there's more to a conditional field than just a simple javascript addition. This suggests more careful and rigorous thinking, than a simple quick fix patch. Example: it's great to see the solution by marcvangend as a start, but building a full blown survey with several conditional field groups with this solution becomes a very complicated script.
In summary: it would be great if this feature was implemented in Webform, but I'd rather wait for it to be done well than having a short term fix that can't scale.

subscribe

subscribed

I'm also tinkering with some code to make conditional pages (rather than just conditional fields) via an alteration to the pagebreak component and some changes to the webform.module. - I'll report back here if I have any success.

I agree with wundo (#14) javascript is not the way to go for the core functionality, and getting the admin side UI right may be tricky

danseagrave: I'm looking for that! Conditional Fieldsets and Conditional Other Textfields.

and, marcvangend #24, I agree! It sounds like this issue is fairly close to a resolution.

#21 flavor If you've got money coming in why not resolve it?

subscribe

Subscribing

Subscribing

subscribing out of interest.

I was just looking at this software as a replacement to a custom app I was creating but I need the ability to do custom branches.

subscribing

Subscribing.

I'd like to suggest a slight variation of conditional fields --> Conditional fields based on things other than just previous yes/no answers (e.g. conditions, taxonomy terms, og, etc.)

An an extreme example, a Webform could be modular and include subforms based on the context in which its called -- such as a a core survey with additional questions added in based on OG group memberships.

Just a thought!

You're welcome to post any thought, but I think this should be a separate feature request, rather than an addition to the issue of conditional fields. I'm reverting the issue's title.

Subscribing

Subscribing.

Sounds very useful for me because I need to stop my (multi-paged) survey if some questions are answered with "no".

Ok since I got my important patches done I am starting to think about how to do this. Since I consider this an important improvement I am going to to work on the issue. I am hoping quicksketch and some of the other developers of the module with chime in.

From what I can tell there are several ways to do this but the simplest one is to add two new type. 1st type Label It should be able borrow a lot of code from Pagebreak in fact I think the goto can as well. Off the top of my head I think we could just create a list of pages that equal Labels and use goto as a pagebreak and let the pagebreak jump to another page what page will be decided by the goto type. Does this make since?

Thanks
Robert

Robert, it's great that you are going to work on this - thanks.

I don't completely understand what you mean by 'create a list of pages that equal Labels and use goto as a pagebreak and let the pagebreak jump to another page what page will be decided by the goto type', but it sounds as if you want to implement conditional fields as conditional pages. I'm not too enthousiastic about that, because even a simple form with one conditional field would be split into two pages. That's not user friendly IMO.

You are probably right that there are several ways to do this. However that does not mean that we should choose the simplest. I think a conditional field should not be some type of question or pagebreak. The conditions can be considered metadata of a question (just like weight or parent fieldset), saying "only show this question if the following condition(s) have been met". If conditions are implemented as a question type, I'm afraid that the user interface might get really confusing, especially for first time users.

IMHO, a proper implementation of conditional fields would:
- use javascript to hide and show conditional questions
- work with all types of questions
- allow multiple conditions for one question
- allow chained conditions
- implement the conditions as a kind of metadata

marcvangend,

I have reread the decision and more importantly I have read the code and yea your list of goals are what I started with but from what I have read in the code that would require a radical change in how the code works. No one in the right mind would accept that patch unless they started working on version 3.x. Yea I think that is a great idea but I am also a pragmatist doing something small is both easier to write and easier for a maintainer to review and include.

All,

There appears to be two diff ideas being talked about. One is for condition paths aka wizard were each question is based on a prior answers. The other is for a kinda Select-Other box. That is were you have a select box and one item in this box aka other although it could be something else if selected would provide either a textfield or textarea were people could free form enter an answer.

The first idea is the one I was talking about although a recent form I did the 2nd one would have been useful as well.

So I can going to open a new issue for 2 types Select-Textfield and Select-Textarea. #353898: Add two new content type select-textfield and select-textarea.. I missed there was already one open. #330740: "Other" option in select lists for text entry.

Thanks
Robert

rmiddle, Thanks for your input. You're very much correct about the approach that should be taken (small and incremental is much better than massive rewrites). There's already an issue for adding textfields to the select list: #330740: "Other" option in select lists for text entry, so I've closed your new issues as duplicates.

quicksketch, robert,
I didn't read the code so I was not aware that my whishlist implies a huge rewrite. I do agree that small steps are better.
As said I'm a bit worried about the interface and the complexity for end users, so I will follow the development and provide help and feedback where possible.

quicksketch,

No problem I didn't see the open issue sorry about that.

Thanks
Robert

Subscribe.

Need that too!
We have a first webform page that allows our users to select some tools to review and depending which tools they selected, they should only get the related page when they click "next".

So far, I use a Javascript workarround to display/hide blocks but it requieres all the item to be on one page. :-s

Subscribing

subscribing

any news here? :)

subscribing

Subscribe.

subscribing

We have need for this functionality as well, but for a use case different than survey. We are collecting webform data on requests to provision development/test servers. We would like to use conditional fields to create a simple configuration wizard that only allows users to request valid application/appserver/OS combinations. For example, if a particular application required Windows vs. Linux OS, once that application was selected, the OS field choices would only display Windows option for selection.

I think this is similar, if not identical from a dev perspective, but wanted to add this use case discussion in case others are faced with similar challenges.

subscribing and looking in to solutions

I was looking for this issue and didn't find it so I'll add the keywords I used: branch and branching. (also subscribe).

Would love to have this functionality

@#56: I think the Hierarchical Select project may do what you want, though I don't know if it works with Webform.

http://drupal.org/project/hierarchical_select

subscribing

OK. This patch accommodates the need we had at The Economist to display questions only based on answers to previous questions. The way this is built, you can only conditionally display elements based on components from previous pages. The form to set components as conditional is in the advanced fieldset, in a collapsed fieldset named "display rules" at the bottom; this is simply because it'd be easy to build yourself a very broken form using this logic.

This will work for most types of elements; the only one that it probably wouldn't work for is a multiple-select element.

The discussion I had with quicksketch about this led me to make this as basic as possible for now.

Wow, nice netaustin. Very simple implementation. Looking at the code, it looks like this is a bit limited though, there isn't any way to skip a page entirely is there? What happens when a user proceeds through the form and there are no available questions on that page? Does it just show a blank page with previous and next buttons? I think this patch might be satisfactory if we ensure that pages that have no components are skipped entirely. It's less flexible than I had been thinking originally, but at the same time it's much, much easier to visualize and we don't have to worry about handling loops in the form logic or other similar problems.

In other news, I've updated HEAD with the latest code, which we'll be using as the 3.x branch. This feature will only be added to the 3.x version which will be Drupal 6 only. Since we're now working in a new version, feel free to change other functions as necessary to improve the code.

Ok, I'll update and re-roll a patch with "skip the page entirely" logic built in.

Currently you won't see the "display rules" fieldset on pagebreak elements. I'll turn that back on, and if a display rule set on a pagebreak comes back false, it'll jump to the next pagebreak or the end of the form. Cool?

I've also updated this issue to 3.x-dev.

subscribing

subscribing

Desperately needed... subscribing.

subscribing

I'm looking forward to this functionality!

I suppose that javascript code generation can be added later to add some UI candy, but let's keep it in mind as this solution is implemented because it could probably be built on this work.

This will be a great addition to WebForms, just wish I could help. I did buy that excellent O'Reilly manual "Using Drupal".... very handy.

Subscribing, 3.x-dev is the way to move forward! greetings, Martijn

@netaustin #65
I've applied and tested your existing patch and am very impressed, everything looks good so far.
Excellent work and an amazingly simple approach you've taken.

Once you post the updated patch as mentioned above I will run that through some tests as well.

Subscribing…

Not sure if my need is the same as the one being described here ... or if it's already accommodated. I'm doing a form that has a number of radio button choices in one field, but if the user doesn't like these choices, s/he can leave them unselected and type another amount into a textfield instead. I don't need the textfield collapsed ... it can show. But it becomes a required field if no radio button was chosen.

Is there a way to do this as the module is currently offered? Or do I need the javascript hack?

m.e. As mentioned before, that's a separate feature. See #330740: "Other" option in select lists for text entry.

subscribing

As much as I hate to do this to an already subscription-laden thread, "Subscribing."

I'd like to chip in. oh, and subscribe, too.

I applied the patch and I'd first like to say... wow. Good work. Thanks!!

Although I'd like to know if you now have a more recent version of the patch....

Thank you for your time.

Oh one more thing....

There is a bug with fieldset compoents in the patch. No components past the FIRST pagebreak are loaded into the Display Rules list.

I fixed my issue AND I have a suggestion.

This code in the patch is problematic. In my case, I had 20 fieldsets that all had names of "If yes..." BUT I manually made the field keys different. Each one of these fieldsets had about 5 to 10 components within them.

With this patch, I wanted to simply add the "conditionalness" to a fieldset instead of to 10 components to save time. (20 fielsets x 10 components ea. = 200 vs 20 fieldsets x 1 = 20) This is also effective for visual representation. The only downside is you cannot have any pagebreaks within fieldsets.

The following code needs to be changed in the patch from:

<?php
// Add conditional fields.
   if ($component['type'] != 'pagebreak') {
     $component_options = array();
     $counter = 0;
     $last_pagebreak_slice = 0;
     foreach ($node->webform['components'] as $cid => $test_component) {
       // Only components before the pagebreak can be considered.
       if ($test_component['name'] == $component['name']) {
         break;
       }
       if ($test_component['type'] == 'pagebreak') {
         $last_pagebreak_slice = $counter;
       }
       else {
         $counter++;
         $component_options[$test_component['form_key']] = $test_component['name'];
       }
     }
?>

TO:

<?php
// Add conditional fields.
   if ($component['type'] != 'pagebreak') {
     $component_options = array();
     $counter = 0;
     $last_pagebreak_slice = 0;
     foreach ($node->webform['components'] as $cid => $test_component) {
       // Only components before the pagebreak can be considered.
       if ($test_component['form_key'] == $component['form_key']) {
         break;
       }
       if ($test_component['type'] == 'pagebreak') {
         $last_pagebreak_slice = $counter;
       }
       else {
         $counter++;
         $component_options[$test_component['form_key']] = $test_component['name'];
       }
     }
?>

subscribing

subscribing

subscribing

Here is a guilt-ridden patch; sorry it is so late. This was no small feat, especially to keep it relatively simple and to keep the previous button functional. Same basic details as before, but now:

1) Pagebreaks can have conditional elements. A pagebreak whose conditional evaluates to FALSE will cause the entire next page to be skipped.
2) If no elements occur on a given page, the entire page is skipped.
3) If the last page is skipped, the form is submitted automatically.
4) The form will skip as many blank pages as needed; so if you're on page 1, and you fill out an element which causes pages 2-4 to be hidden, you'll skip all the way to page 5. And if there is no page 5, it'll submit the form.
5) The previous button works; it also skips blank pages. Say, in the above example, you're on page 5, and you click "Previous" and go back to page 1 and change an element that causes pages 2-4 to be shown, then click next--you're on page 2.

Here are the drawbacks:

1) If you make a conditional component required, you'll create a situation where the user may not actually be able to complete the form.
2) Pagebreak conditionals supercede all others. If you forget that, you could end up creating a very confusion situation for yourself.

These drawbacks are largely why I think the "Display Rules" fieldset still belongs deep in the "Advanced" fieldset. Making the admin UI more usable for everyone is a great goal, but perhaps a separate issue. Your call, quicksketch.

This patch is against HEAD.

subscribing

Wow, amazing work netaustin! Great thinking on making pages themselves affected by conditional logic! I think that for most people, they'll probably *only* use this form of conditional logic, but I could be wrong. It'll be interesting to see how we can display the form "flow" in some visual way. I bet we might be able to do something clever similar to the way drag and drop works within menu trees, build out a graph of the conditional fields and what they affect. Anyway that's a separate issue. I'll review this when I get a chance.

_sub^scribing

subscribing — looking forward to testing this

sub

does this patch only work with multistep forms? Or, can it use jquery to show/hide the conditional fields?

@mrfelton - it only works with multistep forms. A jQuery feature to allow this UI to work on single page fields should be an additional patch once this basic functionality is accepted.

subscribing

subscribing

Hi everyone, I just wanted to post saying this is still going to be included in the 3.x version of Webform when I can next review it, however all my efforts are concentrated on porting ImageField and FileField to Drupal 7 for core, since the code freeze is in September. After DrupalCon Paris my contrib work will pick back up again and I'll resume work on Webform.

Hi everyone

I am new to Drupal, well started working on it just for a month. I have been thinking about the same feature and have gone through the whole discussion. I would like to share whats my point of view and how I think about this feature.

1) There should be a new type called dependency or something that basically links the switch and the target.
Switch: can be anything... a text field, check box, select or anything... on which the target will depend.
Target: can be a fieldset or anything... that will be affected depending on the value of the switch.
2) Condition: Something like workflow-ng
for dependency there will be a link like workflow-ng that will take to a new form where we can set the condition... textual compression, value of a select or anything.
we can add more than one condition
for each condition we will decide the result
3) Result: Which components of the target will be displayed and which won't will be decided in this section, e.g.
we have a fieldset as a target and a check box as switch.... if it's value is true some x,y,z children of that fieldset will be displayed
if it's value is false some a,b,c children of that fieldset will be displayed.
4) jQuerry will handle which elements will be displayed in the Result.

This is the basic work flow that I am thinking....

@ quicksketch, netaustin, anyone else who have something to say

I would like your comments and suggestions or anything that might help me develop it

@saketi3t your workflow is very much inline with the current functionality of the patch, which is already developed and available for you to download. I'm not sure what creating a new patch with very similar functionality would accomplish, though I'm sure quicksketch will be happy to take a look at all implementations.

Also, I think creating a new element to do this, your "switch" element, would be detrimental to user interface and code stability. In Webform, at present, form elements are mostly self-sufficient and standalone. Your switch element would necessarily have to interfere with the element generation and display workflow itself, making it a very special case among form elements.

Also, I'm guessing that quicksketch is looking for the simplest way to introduce this functionality so he can focus on the core changes to logic and not user interface or workflow in the initial implementation. I'd like to get the current approach reviewed and committed before we get too far into some of this interface and workflow stuff so we can work through one issue at a time.

Thanks netaustin, nice elegant work. I noticed a bug though (unless it was by design).
The patch works more like 'conditional pages' than 'conditional fields':

Example:
Page 1
- Question 1
-- option a
-- option b
- Question 2
-- option a
-- option b

Page 2
- Question 1 (display only if Page 1, Q1=a)
- Question 2 (display only if Page 1, Q2=b)

Page 2 will always display both questions if any of the conditions are true or it will be skipped if no condition is true, but it will never show the only one of the questions if the options are set to true and false.

@ netaustin

thanks for your reply
are you talking about the patch you mentioned in #86 or #62 or some other patch
sorry to be naive but I have never installed patch before... and when I click on that link it just displays the source code
can you please give the guidelines to install that patch.. and does it work on Drupal 5?

thanks in advance :-)

-Saket

@ netaustin

one more thing.... is the existing patch work for single step form or just multi step forms

hope to hear soon

thanks

That would be great !!!

Subscribing!

Subscribing!

subscribing

subscribing

+1

Looks like great work so far from the comments. I am eager to test it out for myself.

subscribing +1

subscribing

subscribing...
and wondering if I can offer a bounty to induce dev of a conditional fields patch..anyone with me?

Please leave the issue title as is (there are no comment subjects in the issue queue, you changed the title of the complete issue).

Subscribing.

Subscribing.

Subscribing

Glad to see this is in the works, but I was hoping my search would result in something ready to use!

I'll have to look into work-arounds people have mentioned here for now, I guess.
Looking forward to the real thing being up.

Kudos to the devs, and thanks everyone for posting alternatives in the mean time x

This patch is great! Thanks for your hard work on this. I am wondering if anyone has experienced this issue though...
When I click the next page button to respond to form questions after the pagebreak, I am unable to subsequently click the previous page button to return to the previous page unless I answer any required fields on the current page first. Actually, if I click the previous button a second time, however, it lets me go back. I am wondering why that would be?

subscribing...

Subscribing

Subscribing

why not just use jQuery to show/hide conditional fields based on values?

Subscribing

Thanks for your work, folks! I'm looking forward to webform 3.0!

I suggest you remove the validation for the back button. using :

Index: webform.module
===================================================================
RCS file: /cvs/drupal-contrib/contributions/modules/webform/webform.module,v
retrieving revision 1.136
diff -u -p -r1.136 webform.module
--- webform.module 20 Jun 2009 23:04:58 -0000 1.136
+++ webform.module 13 Oct 2009 20:03:26 -0000
@@ -1235,6 +1235,8 @@ function webform_client_form($form_state
'#type' => 'submit',
'#value' => $prev_page,
'#weight' => 1000,
+ // skip_validation.module key
+ '#skip_required_validation' => TRUE,
);
}
if ($page_num == $page_count) {

Hi,
I have a question about making simple conditional field displays in the form without going to next page. It seems that your patch requires users to select options on one page and the resulting fields are displayed on the next page. I am looking for a slightly simpler option where a text field is displayed whenever a checkbox is selected - if I was coding the form from scratch I would use a simple JS/Jquery show/hide linked to the onclick event in the checkbox. There wouldn't be a next page.
For example:

<input type='checkbox'> checkbox 1
if checkbox 1 is checked show this: else hide it:
please explain:  <input type='text'>

would there be an easy way to add the appropriate JS, or did I miss that this patch allows it? it is quite important to not break the flow of the form...
Thanks
Delphine

Hi everyone,
Here is a JQuery solution that works with a checkbox/textarea combination - it also clears up the textarea upon hiding (adapt for things other than a checkbox/textarea by looking up JQuery).

This code can be added to the "description" field (body) of the webform with input format = php. You'll have to view the source of your webform to get the appropriate ids - they're quite long so I've replaced them for clarity - XXcomponent nameXX will be your component's name. Component 1 is the controlled one and 2 is the controlling one.

<script type="text/javascript">
    $(document).ready(function(){    
        //Hide div by default
     $("#webform-component-XXcomponent 1 nameXX").css("display","none");
  //Add onclick handler to checkbox 
       $("#edit-submitted-XXcomponent 2 nameXX").click(function(){
        //If checked
        if ($(this).is(":checked"))        {
            //show the hidden div
            $("#webform-component-XXcomponent 1 nameXX").show("fast");
        }
        else        {     
            //otherwise, hide it
           $("#webform-component-XXcomponent 1 nameXX").hide("fast");
        // and clear data (using different selector: want the textarea to be selected, not the parent div)
          $("#edit-submitted-XXcomponent 1 nameXX").val(''); 
        }
      });
  
    });
     </script>

Hope this helps someone!
Delphine

subscribing

Thanks everybody !

Subscribe

subscribing, it looks like there's been no activity on this since august. has anyone else found a solution for the implementation of just conditional fields on a single page form? or something that supports a multi-page form but the conditional fields are used on the same form page and not necessarily applying to fields on a next page. thanks!

Hi msedlacek, see the code in #126 - it can help you implement conditional fields on a single page form. Unfortunately you have to do some hand coding, but it's pretty straightforward as long as you find out the field's css ID (use Firebug) and look up Jquery selectors for things others than checkboxes (my example shows/hides/clears data if hidden in a texbox depending on a checkbox's state).

subscribing

Finally got around to testing this patch. Wow, great work netaustin! It seems that the "Previous page" button does not work on the form, but after unapplying the patch, it seems that this must be a pre-existing condition.

There's one big caveat in that this doesn't submit the form properly if the last page is being skipped. Rather than determining if a next page is necessary on submit, the form is rebuilt and then manually submitted with a call to webform_client_form_submit() inside of the webform_client_form() function. This means that any modules adding their own submit handlers will not fire. It will also skip any validation handlers which could potentially do things like put in a confirmation page or something.

Anyway this patch is still pretty flipping cool. I'm working on moving the page logic to the submit handler instead of doing it during the form build.

I've moved the page-handling code to the submit handler instead of during the form building process. Overall I like this approach much better not only because it submits the form properly but also because it shortens up the extremely long form building function. In the process I also got the previous button working again, and it even skips backward over pages that do not have visible components.

I did discover a bug in my testing though, but I've opened a new issue for that: #680262: Conditional fields may save inapplicable values.

Once again a HUGE thanks to netaustin for his work on this. I've committed to CVS. YAY!

Sweet, and thanks for all the hard work on this! I will be testing soon.

Will this be part of the next release?
Is it in sight?
Thanks a lot for your efforts :)

It will be part of the 3.x version which should start releasing betas in the next month or so.

Looking forward to the betas.

Another very cool feature of the upcoming 3.0 release :-)
Just implemented conditional fields into one of "my" existing webforms and I must say this works great!

Subscribing!

We needed the ability to hide a field unless a certain select option was chosen for a pro bono build at DrupalCamp Florida. Ted Bowman should be submitting his conditional module that compliments v3 soon. Commenting in order to subscribe to see when he does update.

I am EXTREMELY excited to see this happening!

I am somewhat of a n00b to Webform (and Drupal), coming from an ASP (ugh) world. I have a form that I need to replicate in Webform, that has a multiple selectbox at the top. Currently when those are selected, those open hidden divs on the same page (but using Webforms these could be multiple pages). My hangup that I haven't seen discussed here is those fields are required.

From what I could tell in reading through this thread, if a field is required and is not displayed, a user maynot be able to complete the form. So my question is: If a field is conditional (i.e. only displayed if another field value == true or meets a certain condition) can it be marked Required and will the logic be in place so that if it's required and not displayed, the form skips that field upon validation for required fields?

I can share my existing form if that would help through Private Message if what I am asking above isn't clear.

I just want to let people know of a module I made called Webform Conditional. It adds a different type of conditional fields(called hidden conditional in the edit form). Basically the fields can be conditional on select fields within the same page of form. They are shown and hidden(and values cleared) with Javascript.

It is in dev stage now and requires Webform 3.x. I could use some feedback. I think my implementation of conditional fields is different enough from way conditional fields are implemented in Webforms that it reasonable for it to be in another module. What do you think?

Thank you for this,
i was expecting something similar within the new "conditional recipients" in webform 3
I gave a try to your module and it seems to be working so i think it is helpful for now...
At the same time i think we were not the only ones expecting this behaviour to be the default one provided by the module.
Anyway, i'm going to use it 'cause it doesn't really make sense to me to add pagebreaks to activate the functionality and i couldn't even make it work this way.
Thanks,
Da.

quicksketch do you think this functionality should better go into webform 3.0 core instead of living in a separate module?

@tedbow: I had a look at your module, it might make sense to include in Webform directly, though I have a lot of concerns around using JavaScript for such functionality (required fields being hidden for example causes all kinds of problems). HOWEVER, let's please open a new issue for that feature enhancement, this thread is already "done" since it we accomplished what we intended. It's hard to follow 100+ comment threads of discussion.

And here is the new thread: #732114: Merge Webform Conditional into Webform (support for same-page conditional fields)

subscribe

subscribe

subscribe!

subscribing

subscribing

+++ Subscribing

This functionality already exists: http://drupal.org/project/webform_conditional

Duntuk, this module is not what they meant in the very first post. They meant a conditional form for text field. The webform conditional module allows condition under selections and drop downs only. But I've found a turn around to do that, I've put my text fields inside a fieldset and the fieldset under the condition of a select options component. So when you click YES or NO in the select options questions, the collapsable fieldset comes up.
It worked perfectly!