Conditional fields
Marat - May 5, 2008 - 04:01
| Project: | Webform |
| Version: | 6.x-3.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
Description
Hi there,
I am thinking about adding a new feature which about a conditional field.
Sometime I put a YES/NO question in my webform, and if yes please do something, if no go to the next question. For example, Do you have a car, if s/he selects yes, a textfield will open, please specify the type of car. If s/he selects no, nothing happens.
This could be a very useful feature.
Regards

#1
Sounds great. I'll leave open the feature but I have no intention of implementation.
#2
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?
#3
This would be a valuable feature - one I am looking for too. Subscribing to this topic :)
#4
A conditional field would be grand indeed! It is on my TODO list as well.... Subscribing.
#5
same here, subscribing
#6
subscribing
#7
Subscribing
#8
so do I
#9
Subscribing
#10
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)
#11
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
#12
[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]
#13
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
#14
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?
#15
As far as I know, 'Critical' means that the module cannot be used if this isn't fixed. That's not the case here.
#16
subscribing
#17
I would find this useful as well.
#18
need this badly
#19
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 -
#20
>>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.
#21
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....
#22
subscribing
#23
subscribing!!!
#24
@ #21: if you have paying client who needs conditional form functionality, see if he can pay you for adding this feature to webform!
#25
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?
#26
subscribe
#27
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:
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.
#28
subscribe
#29
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
#30
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?
#31
subscribe
#32
#33
Subscribing
#34
Subscribing
#35
subscribing out of interest.
#36
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.
#37
subscribing
#38
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!
#39
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.
#40
Subscribing
#41
Subscribing.
Sounds very useful for me because I need to stop my (multi-paged) survey if some questions are answered with "no".
#42
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
#43
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
#44
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
#45
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.
#46
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.
#47
quicksketch,
No problem I didn't see the open issue sorry about that.
Thanks
Robert
#48
Subscribe.
#49
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
#50
Subscribing
#51
subscribing
#52
any news here? :)
#53
subscribing
#54
Subscribe.
#55
subscribing
#56
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.
#57
subscribing and looking in to solutions
#58
I was looking for this issue and didn't find it so I'll add the keywords I used: branch and branching. (also subscribe).
#59
Would love to have this functionality
#60
@#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
#61
subscribing
#62
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.
#63
#64
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.
#65
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.
#66
subscribing
#67
subscribing
#68
Desperately needed... subscribing.
#69
subscribing
#70
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.
#71
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.
#72
Subscribing, 3.x-dev is the way to move forward! greetings, Martijn
#73
@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.
#74
Subscribing…
#75
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?
#76
m.e. As mentioned before, that's a separate feature. See #330740: "Other" option in select lists for text entry.
#77
subscribing
#78
As much as I hate to do this to an already subscription-laden thread, "Subscribing."
#79
I'd like to chip in. oh, and subscribe, too.
#80
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.
#81
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.
#82
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'];
}
}
?>
#83
subscribing
#84
subscribing
#85
subscribing
#86
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.
#87
subscribing
#88
#89
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.
#90
subscribing
#91
subscribing — looking forward to testing this
#92
sub
#93
does this patch only work with multistep forms? Or, can it use jquery to show/hide the conditional fields?
#94
@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.
#95
subscribing
#96
subscribing
#97
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.
#98
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
#99
@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.
#100
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.
#101
@ 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
#102
@ netaustin
one more thing.... is the existing patch work for single step form or just multi step forms
hope to hear soon
thanks
#103
That would be great !!!
#104
Subscribing!
#105
Subscribing!
#106
subscribing
#107
subscribing
#108
+1
#109
Looks like great work so far from the comments. I am eager to test it out for myself.
#110
subscribing +1
#111
subscribing
#112
subscribing...
and wondering if I can offer a bounty to induce dev of a conditional fields patch..anyone with me?
#113
Please leave the issue title as is (there are no comment subjects in the issue queue, you changed the title of the complete issue).
#114
Subscribing.
#115
Subscribing.
#116
Subscribing
#117
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
#118
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...
#119
Subscribing
#120
Subscribing
#121
why not just use jQuery to show/hide conditional fields based on values?
#122
Subscribing