Flexible number and type of fields
birken@drupal.t... - August 24, 2005 - 18:09
| Project: | Signup |
| Version: | 6.x-2.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Description
I'd like to see the ability to choose for each signup which fields to ask for from the user.
For instance, sometimes a phone number would come in handy, while other times gender would be helpful (e.g. if making room plans for an extended conference).
I have no idea if this is possible with the current database configuration. Just dreaming out loud here :-)
#1
something like this is currently planned for the 4.7 version of signup--stay tuned!
#2
i'm looking at the ever-growing amount of feature requests for this module, and two things are becoming apparent:
thus, i'm postponing the addition of any new features until i've had a chance to think this through and talk w/ some other developers. i've scheduled a meeting at the upcoming conference w/ the co-creator of signup module, and hopefully we can hash most of this out soon.
#3
seems like a pretty old post.. but not sure headway on this.. i pretty sure it must be most important feature request for signup - "what singup info do we need?"
if this discussion has moved somewhere else; maybe some can point me to it
thanks,
#4
Well, since we're on the subject...
Integration with a chosen CiviCRM profile would be my dream solution. 'Volunteer' does it that way.
During the election, we were carpooling to various campaign offices from two different locations (Chicago & Evanston). So as part of our sign-up process we had to know what "pick-up" point the person preferred and whether they had a car. That's two radio option groups right there. Then a box for comments.
#5
keep in mind that the current form for signup module can be quite flexible, if you're willing to dig into the code a bit.
#6
I'd still like see a feature like this, so if it happens, I'm subscribed to the thread...
-N
#7
Changing the theme isn't too bad, easier than I thought with my limited coding abilities. But it'd be nice to empower the node owner with the ability to change their form as they seem fit rather than having one blanket form for all events on the site.
And the necessity to have it configurable within the Drupal interface is key.
If you can use the power of the forms module to give the user the option to add fields would be ideal.
#8
Right. Esteemed Drupalist starbow hacked signup.module to use forms.module at one point for the BADCamp site. He's told me privately he's planning to clean up his hack and submit it as a patch so I can include it in the "upstream" version...
#9
That would be sweeeet. I still find it amazing the possabilities Drupal allows with it's flexibility.
I look forward to this integration and use the theming for not to get me by
#10
I'd like to suggest we make this a bit more active.
If starbow is following, and has that code, please post it or contact me.
I'm going to begin researching how to do the do you did.
; )
This feature is something we want to get rolling on.
We would event consider working on the CiviCRM piece, we actually already have that hacked together.
There is a themable function that controls the form displayed on screen.
If you add elements to this form, the serialized data will be updated.
My desire, would be to get that form data into any admin form, so it can be modified within drupal.
Once I start to play with the themable function, I'd like to build a module to handle the customization of this form.
Please post any comments/concerns.
#11
@ dww:
I had thought about using CCK to accomplish this problem, using fields with multiples enabled and somehow mapping each users response to these fields for each Signup node. I see a couple problems with this, though:
-How do you associate certain CCK fields to the signup form, while maintaining others for just the node? This could maybe be accomplished by defining a new CCK field type that's essentially a fieldset that you could then add additional fields to (not sure if this is possible with CCK). But would this then allow users to create multiple signups per node?
-How to go about associating a user with a signup node, and all of the user submitted fields? Since CCK stores multiple fields in a separate table, and only uses nid to reference back to the main node, would it be enough to create a hidden user reference fields, and use the position of the user field (delta) to associate that user to the corresponding signup fields? What if a user doesn't fill out one of the fields?
Another approach could be the way Webform solved a similar problem: creating custom form components that are added directly in the node edit area, the results of which are stored in a one-to-many table for each submission of the webform. It would be too bad to repeat ourselves, but I think this would be the easiest way to get the functionality.
#12
Well, I remember trying and failling to embed webform 1.x into the signup process, but I will give the 2.x branch a look to see if it is more embedable.
#13
@starbow:
Any luck with webform 2.x? I might have a little time to look into this, but I don't want us to repeat ourselves. Were you looking into having webform as a dependency of Signup? Or were you looking into borrowing the code from webform to integrate directly into the signup module?
#14
If you've got the time, go for it. It is half way down my todo list, so I don't know when I will have a chance myself.
It would be better to have a dependence on webform vs snagging their code, in terms of long term maintenance.
#15
Subscribing
@duellj - I'm looking to do the same thing; experimenting a bit here myself as I'm on a time crunch. If you'd like to collaborate, drop me a line.
#16
While it's currently kind of hacked into the signup code, I am able to report that signup 5.x-2.4 + webform 5.x-2.1.2 can be used together. I need to clean things up a bit & make the webform selectable through the administrative interface, but it does submit, verify, and enter the database correctly. I also need to work on displaying the webform output when examining signup records. I'll be in touch with duellj next week, and I'll see what we can get towards a patch.
#17
obsidiandesign,
Any progress in integrating signup&webform ?
This would be very helpful !
#18
I need to add form fields to the signup module to collect addresses. Any idea about how to go about this?
I have sign up and sign up pay installed.
#19
@twirlingsky: Read the INSTALL.txt file shipped with the module. ;) You can already customize the signup fields, the only problem is that it's currently handled site-wide. This issue is specifically for working out a new feature of having flexible signup fields per node or node-type -- it's not meant as a support forum for everyone trying to customize signup for their own site. Thanks.
#20
A less rigorous, but simple solution, I've made a patch against HEAD (signup.module 1.144 and signup.theme version 1.13) so that the theme callback is passed the node including the signup form. In this way you can have a combination of fields used in every form, extra fields per node, and other things like extra fields per taxonomy term. This isn't as robust as webform, as we're still using the serialized array paradigm for storing all the user data.
After applying the patch, I can write a theme function looks like this:
<?php
function my_theme_signup_user_form($node = NULL) {
global $user;
$form = array();
// If this function is providing any extra fields at all, the following
// line is required for form form to work -- DO NOT EDIT OR REMOVE.
$form['signup_form_data']['#tree'] = TRUE;
//these first two fields are for all signup forms
$form['signup_form_data']['Name'] = array(
'#type' => 'textfield',
'#title' => t('Name'),
'#size' => 40, '#maxlength' => 64,
'#required' => true,
);
$form['signup_form_data']['Phone'] = array(
'#type' => 'textfield',
'#title' => t('Phone'),
'#size' => 40, '#maxlength' => 64,
);
// If the user is logged in, fill in their name by default.
if ($user->uid) {
$form['signup_form_data']['Name']['#default_value'] = $user->name;
}
//add fields to specific node signups
switch($node->nid){
case '2335':
$form['signup_form_data']['Age'] = array(
'#type' => 'textfield',
'#title' => t('Age'),
'#size' => 3,
'#maxlength' => 3,
'#required' => TRUE,
);
}
//add fields based on other node properties, like taxonomy terms.
//taxonomy term id for event nodes where food is served
define('FOOD_SERVED_TID', 2 );
//if we're serving food, gather dietary restrictions
if(isset($node->taxonomy[FOOD_SERVED_TID]) ){
$form['signup_form_data']['Food Restrictions'] = array(
'#type' => 'checkboxes',
'#title' => t('Dietary Restrictions'),
'#options' => array(
'vegetarian' => t('Vegetarian'),
'vegan' => t('Vegan'),
'diabetic' => t('Diabetic'),
'glutenfree' => t('No gluten'),
'halal' => t('Halal')
),
'#description' => t('Check any dietary restrictions, and we will do our best to accomodate you.'),
);
}
}
?>
#21
Very interested in this feature and a port to d6
#22
Ugh, sorry jklsemicolon -- I didn't notice you had a patch in here. The good news is that I just committed a basically identical change to DRUPAL-5--2 and HEAD. See #332443: Pass node object to signup_user_form theming function. ;)
#23
FYI: everyone interested in this is encouraged to check out #330943-3: Drupal 6.x port of signup_status for some more thoughts on this topic.
#24
Nice work. I'd pay to have customizable fields.
#25
+1 for the feature.
(subscribing)
#26
subscribing
#27
Absolutely, subscribing for 6.x-1.0-rc3 version
I certainly didn't understand that there was only name and phone number going to be required on the 'sign up'.
I had a look at the inc file and went 'ekkkk'!
Would be so good (read that 'EASY to use') to have customisation like Webform.
#28
subscribing
#29
This is what we did http://drupal.org/node/530344#comment-1853048 which is similar to #20 but for D6 and Signup 6.x-1.0-rc3 in case it helps anyone here.
#30
The
if ($node->nid == $my_node_id) {# node-specific field definitions here
}
is an excellent workaround for defining custom fields per node, instead of site-wide.
Why does the Signup module not support dedicated templates, such as "signup-[NID].tpl.php", where [NID] is the Node ID number, just like the Webform module does?
#31
Re: #30: Because doing this via theme functions is a hack, and I'm not going to polish a turd.
#32
Subscribing.
(and lol @31)
What about using webform to create the form for signup?
Downside -- either we have to muck about with how webform wants to display the form, or we have to have a spare webform node kicking around that's redundant.
I did file an issue suggesting a webform could be an entity separate from a node, but quicksketch shot it down.
#33
Following the bof at DrupalCon Paris about using signup module as part of a wider event handling package, I am thinking form builder might be the way to go.
Need to actually take a look at it now...
#34
@ jaochim, can you say more about what happened at drupalcon? i'm just running up against this issue right now, in planning a new site, and wondering what my best bet is in terms of implementing a forward-supportable solution.
thanks!!
matt
#35
There's a rough outline here: http://groups.drupal.org/node/26075
Please join the group there too!
My very rough plan is that for D6 we should remove the current signup form to a plugin module, and then write a new plugin module that plugs in a form from formbuilder.
Admins can then create a new form and link it to that node.
Data storage would the same model as profile module - one tall thin table for everything.
Alternatively, if form_builder is too complex to use, we could borrow most of the code from profile module -- after all, that's basically what we want, but just for the data to go in our own table and per-event rather than per-user.
This is something I'll be looking at in the next 2-3 weeks.
#36
Hi, first thanks a lot for caring for this! I'm looking forward to being able to use signup in the future!
One thought I have is that when custom fields becomes possible, how about having templates/profiles of forms making it easy to reuse? Use case: I run a site for an association of local sailing clubs, and I would love to offer easy signups for sail events. Basically, the clubs would very often need the same set of fields for signups, eg. class, sail number, club etc. An other type of events we have are meetings, which requires a different set of fields. So having a signup profile adding the required fields would allow the (non-geek) folks in the clubs to set up signon on their own.
There are two steps: reusing existing fields, like CCK, and keeping sets of fields as "signup profiles".
#37
I'm all for this. Interesting that this request is getting to be about 4 years old or so...
I had to hack Signup to death in order to modify the signup form... ...not a pleasant experience. This really shouldn't be handled in a theme function since, 1.) You'd switch the theme and suddenly have a different form and 2.) You can't customize this per node-type without a mess.
It'd be great if there were a UI to construct the signup form (and make it node-type specific), and also, allow users to place the form into a block so that it can be positioned conveniently on the user end.
...certainly not the easiest thing to do, but it'd be incredibly useful
#38
is there any date when one can expect this issue to be solved?
#39
@WishMasterNND: New features can't possibly be added to an existing release, so setting the version to 6.x-1.0-rc6 on a feature request is pretty meaningless. Furthermore, this is such a potentially huge change that I doubt I'd going to add it in the 6.x-1.* series at all -- this will probably be in 6.x-2.* or in the 7.x version. Also, just because you really want this done doesn't make it "critical" for me to work on it.
Re: a "date" when this will be implemented -- the sooner of a) someone else magically does all the work (perhaps joachim?), or b) someone(s) hires me to work on it and get it all done. I don't have time to do this much work for free. That's life in the real world...
#40
I've been delayed with other things, but this might be on my radar in the next few weeks.
@dww: is there a branch for 6.x-2.x yet?
#41
@joachim: Yes, that's HEAD. So far, there are absolutely no differences (I feel like I prematurely created the DRUPAL-6--1 branch), since every commit has gone into both branches, and nothing's gone just into HEAD.
#42
@joachim: found time to work on it? I think this would be gratefully appreciated by many users :)
#43
Subscribing
#44
You can make it work quite easily with webforms.
I've added an extra field nodereference (to a webform) to the node with the signups.
A user can make a webform and add it to the node. In the signup function that creates the signupform, I load the webform node and than it's simply converting the information stored in the webform node to the $forms array from signup. The signup form is created with the fields of the webform.
It's probably not the best way to do it, but is does work :) Maybe someone can re-use this code to make it a feature in the signup-module: "Select Webform-node to use as signup form"
<?php
function THEMENAME_signup_user_form($node) {
global $user;
$form = array();
// If this function is providing any extra fields at all, the following
// line is required for form form to work -- DO NOT EDIT OR REMOVE.
$form['signup_form_data']['#tree'] = TRUE;
$form['signup_form_data']['Name'] = array(
'#type' => 'textfield',
'#title' => t('Name'),
'#size' => 40, '#maxlength' => 64,
'#required' => TRUE,
'#weight' => -1000,
);
$node_form = node_load($node->field_subscribeform[0]['nid']);
$fields = $node_form->webform['components'];
foreach($fields as $field) {
$description = $field['extra']['description'];
$required = $field['mandatory'];
$disabled = $field['extra']['disabled'];
$weight = $field['weight'];
if($field['type']=="textfield"){
//textfield only
$maxlength = $field['extra']['maxlength'];
$size = $field['extra']['width'];
$field_prefix = $field['extra']['field_prefix'];
$field_suffix = $field['extra']['field_suffix'];
$form['signup_form_data'][$field['form_key']] = array(
'#type' => $field['type'],
'#title' => t($field['name']),
'#required' => $required,
'#description' => $description,
'#disabled' => $disabled,
'#weight' => $weight,
'#size' => $size,
'#maxlength' => $maxlength,
'#field_prefix' => $field_prefix,
'#field_suffix' => $field_suffix,
);
}
elseif($field['type']=="textarea"){
//textarea only
$rows = $field['extra']['rows'];
$cols = $field['extra']['cols'];
$resizable = $field['extra']['resizable'];
$form['signup_form_data'][$field['form_key']] = array(
'#type' => $field['type'],
'#title' => t($field['name']),
'#required' => $required,
'#description' => $description,
'#disabled' => $disabled,
'#weight' => $weight,
'#rows' => $rows,
'#cols' => $cols,
'#resizable' => $resizable,
);
}
elseif($field['type']=="select"){
//Used by: checkboxes, radios, select
$options = explode(PHP_EOL, $field['extra']['items']);
$size = count($options);
if($field['extra']['aslist']=='0')
{
if($field['extra']['multiple']=='0') {
$type = "radios";
$multiple = FALSE;
}
else {
$type = "checkboxes";
}
}
else {
$type = "select";
if($field['extra']['multiple']=='0') {
$size = 1;
}
else {
$multiple = TRUE;
}
}
$form['signup_form_data'][$field['form_key']] = array(
'#type' => $type,
'#title' => t($field['name']),
'#required' => $required,
'#description' => $description,
'#disabled' => $disabled,
'#weight' => $weight,
'#size' => $size,
'#multiple' => $multiple,
'#options' => $options,
);
}
else {
$form['signup_form_data'][$field['form_key']] = array(
'#type' => $field['type'],
'#title' => t($field['name']),
'#required' => $required,
'#description' => $description,
'#disabled' => $disabled,
'#weight' => $weight,
);
}
}
// If the user is logged in, fill in their name by default.
if ($user->uid) {
$form['signup_form_data']['Name']['#default_value'] = $user->name;
}
return $form;
}
?>
DON'T JUST COPY PASTE IN YOUR TEMPLATE.PHP
#45
subscibe
#46
Subscribing
#47
it would be awesome if cck could be integrated into the signup fields so we can choose what sorts of data to get when someone signs up.