Flexible number and type of fields

something like this is currently planned for the 4.7 version of signup--stay tuned!

i'm looking at the ever-growing amount of feature requests for this module, and two things are becoming apparent:

1. there are lots of use cases for it, and lots of people interested in using it
2. it's poised to become a spaghetti mess of code if we don't come up w/ a solid core/plugin approach

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.

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,

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.

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.

I'd still like see a feature like this, so if it happens, I'm subscribed to the thread...
-N

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.

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

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

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.

@ dww:

Bummer that forms.module is no longer supported. Maybe there's another way. There's always the signup-as-a-CCK-node approach I outlined here: http://groups.drupal.org/node/3430

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.

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.

@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?

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.

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.

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.

obsidiandesign,
Any progress in integrating signup&webform ?

This would be very helpful !

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.

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

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.'),
    );
  }
}
?>

Very interested in this feature and a port to d6

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. ;)

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.

Nice work. I'd pay to have customizable fields.

+1 for the feature.

(subscribing)

subscribing

subscribing

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?

Re: #30: Because doing this via theme functions is a hack, and I'm not going to polish a turd.

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.

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

@ 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

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.

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

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

is there any date when one can expect this issue to be solved?

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

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?

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

@joachim: found time to work on it? I think this would be gratefully appreciated by many users :)

Subscribing

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"

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

subscibe

Subscribing

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.

Here's a patch that goes partway. There is more to come, though I'm uploading the work so far in case anyone wants to take a look -- comments welcome!

So far:
- added a hook that lets other modules define their own callback for providing signup form elements.
- changed forms to use it
- updated API documentation
- the signup_basic_form module attached as a zip is meant to be part of this package, inside the modules folder. (I can't get CVS fakeadd to work with a whole new folder) This provides the existing functionality of a Name and Phone number field.

What this means:
- existing sites that change the form in their theme should move this code to a custom module, where they implement hook_signup_form_info and define a callback. This is a little bit more work, but more flexible as you can define more than one form, and also change your site's theme!
- further modules could provide other forms.

So the next part is modules that glue something like webform to this new API: create a webform node and then it becomes available to include in the signup form.
I'm also wondering whether it would be interesting to pull in Ubercart attributes in some way, though I need to take another look at http://drupal.org/project/uc_signup.

Hi, thanks for this enhancement. I am really new to drupal and really want to use this modification to the signup form. How do I go about to using this?

So far, I have created a WebForm that I need. Now, how do I integerate this with the patch and the new signup_basic_form.zip that you have attached to this issue. Is signup_basic_form.zip is a new module that I add just like any other module to the site?

Also, how/where do I apply the the patch?

Really, appreciate any help and guidance you can provided on this.

Thanks

@varhand: This is work in progress. You can try applying the patch (Google for it ;) -- but good docs on this in the Drupal docs).
And getting webform to work with this will require a new module to glue between this new API and webform, but it shouldn't be that complicated.

@everyone: I am currently reworking this patch to allow more than one form plugin to be enabled (and ordered!).
Just about done; just a bit of polishing left. Expect a new patch shortly :)

Here is another patch.

I stress that this is a work in progress! I am posting now because I am probably not going to be able to work more on this for some time (a week at least) due to other commitments.

It would be great if someone will pick this patch up and take it forward; or I will get back to it in due course. I am developing locally using git; if anyone wants to collaborate I can push to github.

I've left @todo notes in the code where there are still things to tackle.

What's new:
- The extra form items are now called panes, like in Ubercart. You can enable more than one on a signup node and order them.

What's missing:
- form element keys for the inserted forms. These are currently ALL WRONG but my train is about to pull in!
- storage of signup data seems to be going wrong, probably due to the form keys having been changed.

Looking beyond this issue:
- plugin modules to profile and content_profile, to collect user data in a signup form (some code from http://drupal.org/project/uc_signup should be moved into its own module, I think)
- adapt the uc_signup module to use this API, and collect Ubercart details; see #623900: API for additions to attendee info form which has implications for more changes to this module.

I hope to take a look at this in the nearish future. Subscribing in the meantime.

subscribing....

Here's another patch.

This is ready for testing! :D

In this patch we have:
- hook_signup_pane_info(), which lets other modules define their own callback for providing signup form panes: these plug in extra fields to the signup form. Signup nodes can then enable any number of panes and order them. (The hook name and the callback function signature have changed since the last patch in #51 above, as I found out more about what was needed to support the various use cases.)
- Signup module's Name and Phone fields have been moved to a new module, signup_basic_form.module. This is attached as a zip is meant to be part of this package, inside the modules folder. (I can't get CVS fakeadd to work with a whole new folder)
- integration with core's Profile module is provided in the attached signup_profile.module. This exposes each Profile category as a pane. This module needs a bit more work to support handling signup of anonymous users. It could either live within the Signup project or separately.

Still to do:
- I haven't quite fathomed the locking of the signup form in the case that the user can see their data but can't edit it.

Implications for current code that builds on signup:
- existing sites that change the form in their theme should move this code to a custom module, where they implement hook_signup_form_info and define a callback. This is a little bit more work, but more flexible as you can define more than one form, and also change your site's theme!

Beyond the scope of this patch, still to do in the big picture:
- signup_profile.module needs to handle anon signup. This might be in the scope of this patch, depending on whether we include this module; or we can move inclusion this module to its own issue once this patch is in. At any rate, not needed to test the new API.
- integration with content_profile.
- integration with webform and/or form_builder. This is to allow site admins (rather than developers) to define their own fields.
- integration with ubercart to collect any values that are product attributes.

Wow - sounds great! Could we expect these features in a 6.x-2.x-dev version anytime soon?

I'm not the maintainer, but generally, this would require people like yourself to try the patch and report back :)

I am willing to help with this, but I don't know how to use a patch file :(. I will try to figure it out tonight.

Given how other features may need to play around with the form (such as multiple signups in one form & email-less signups), I am wondering whether passing in the $form variable is wise.
Its only purpose so far is to get the $signup data in the case that it's being edited. I'll see about maybe changing it to use that.

I'd be interested in the 'current' status of adding these features in a 6.x-2.x-dev version.
And I do realize it's only been a week since the last update to this thread, and it's the 'holidays' week as well . . .

Some minor notes on the patch:

+++ signup.api.php	22 Dec 2009 22:18:17 -0000
@@ -8,6 +8,35 @@
+      'callback' => 'signup_basic_form_form',

I would suggest signup_form_basic_form as callback name (signup_FORMNAME_form). This sounds better (imo).

+++ signup.install	22 Dec 2009 22:18:18 -0000
@@ -482,3 +515,15 @@ function signup_update_6003() {
+function signup_update_6200() {

What about adding the basic pane per default?
drupal_write_record('signup_panes', $base);

@joachim: if you'd like to add a folder with the patch you have to move the files of this folder in the main module directory and manually modify the patch-file.
Lets say you'd like to add "signup_form_basic".
- move all files of this folder to signup
- add the filenames to CVS/Entries
- create the patch (cvs diff -uRpN . > ...patch)
- open the patch-file and add "signup_form_basic/" to the files you would like to put into the directory (both occurences of the filename)
- done

Thanks for the the feedback! :D

> I would suggest signup_form_basic_form as callback name (signup_FORMNAME_form). This sounds better (imo).

I'm using the module name as a prefix to avoid any clashes.... that said, I could give the module a better name than 'signup_basic_form'.

I have been pondering better ways to handle the pane callbacks, as currently the whole of that hook has to be invoked for the signup node to find out what the callbacks are for its panes. Given this happens on node views, it's a bit wasteful.

One thought I had was to store the originating module as well as the pane ID in {signup_panes}, but this is rather fiddly it turns out, as module_invoke_all() doesn't give you any information on which module supplied what data. So we'd have to do a "foreach module, invoke" :(
The other alternative I can think of is storing the callback name in {signup_panes}. But storing function names in code just feels wrong... though I suppose the menu_router table does it and that's core :D

> What about adding the basic pane per default?

Oops -- the basic form should be added to all existing signup nodes. I've just added that to 6200. Dunno about putting the basic form in as a default for fresh nodes though.

I have webform support working :) -- will post patch tomorrow when awake.

I have a few more things to polish....

So in the meantime, in case anyone's interested, I've pushed the whole of my copy of signup with this current work on it to github: http://github.com/joachim-n/signup
In other words, to try this out, replace your signup module folder with that checkout, and run update.php.

There are todo notes in the code; the main thing I want to finish before I post a patch is having the panes output nicely to the list of existing signups.

Here is a picture!

Wow, joachim, your screenshot looks very exciting! That is what many of us have been waiting for :-)

Yes, this is exactly what we have been after !

Other options would be to exclude any of the standard fields in Signup (eg: Name, e-mail or phone) and/or to be able to reorder both the Signup and webform fields (and I understand this can be done in the theme layer, but it's neater if it can be handled at this level)

Thanks in advance, the changes are looking great !

PS: Just to be clear, in your screenshot, is the 'profile category pane' data coming from the data stored in the node from the 'Content Profile' module for the current user ?

> Other options would be to exclude any of the standard fields in Signup (eg: Name, e-mail or phone)

Just disable the 'Name and Phone' pane.

Here's a pic of the admin UI for a signup node -- should make things clearer :)

> PS: Just to be clear, in your screenshot, is the 'profile category pane' data coming from the data stored in the node from the 'Content Profile' module for the current user ?

The profile data is pulled in from the current user; but it's core Profile rather than Content Profile. Implementing integration with Content Profile.... gets interesting. You get into all the same problems as the people trying to get embedded editing of Node Reference nodes.... I'm leaving that for someone else to implement ;)

I've made some more commits to github, and the things I had left to polish are polished :)
It's ready to try out -- will post a patch here tomorrow.

Looks really great (screenshots; didn't try the code yet).

I remember we (Derek, Kris [EclipseGc] and me) had a discussion (several months ago) about using webform_associate to create the signup forms and "attach" them to nodes.
You've seem to manage the forms with pure webform. Great to see. :)

Joachim, do you think your improvements can be commited to this module's official CVS anytime soon?

It looks cool, thanks for all your work on this!

A few questions:
Is every form pane on the site visible on every signup settings page? Could certain panes only be available for specific content types? It seems like it could get to be an overwhelming list pretty quickly if there aren't limits in place.

I'm not a huge fan of the webform module being tied too closely to signup because it takes a certain amount of tech-savvy to use the webform module, and I'm not interested in doing that much training. I'd prefer to use a custom module with less flexibility and a simpler UI. Will it be possible to turn-off or hide the webform options?

For even greater simplicity, could their be default forms for each content type (defined in the site-wide admin settings), and only expose the per-node form UI for users with the appropriate permission?

If the signup uses a webform-based pane, is the data stored in the webform or the signup?

How does signup_profile work? Is it possible for the user to enter data for the signup and opt not to save/overwrite the data on their profile? If someone signs up for 2 events and changes the profile data during the 2nd signup, does that change their registration for the 1st signup?

I'm excited about where this is going!

@roball:

> Joachim, do you think your improvements can be commited to this module's official CVS anytime soon?

Depends on the maintainer... but I'd guess people testing this and reporting back would help! :D

@ln282:

> I'm not a huge fan of the webform module being tied too closely to signup because it takes a certain amount of tech-savvy to use the webform module, and I'm not interested in doing that much training. I'd prefer to use a custom module with less flexibility and a simpler UI. Will it be possible to turn-off or hide the webform options?

Just don't enable the signup_webform module and you won't get webform integration!
This patch comes with these modules that provide panes:
- signup_form_basic: the Name and Phone fields reimplemented as a module
- signup_webform
- signup_profile

You can write your own module that provides panes; in fact, my idea is that people's current extra fields implemented in their theme template could be moved to custom modules. If your site has a single signup, or you know you will always want to use the same group of fields for all signups, you can write a custom module that supplies a pane.

> How does signup_profile work? Is it possible for the user to enter data for the signup and opt not to save/overwrite the data on their profile?

No. The whole point of that is that data is captured to the user profile. Use it for information that is constant to your user: eg, whether they are vegetarian/vegan/etc.

Here is the updated patch.

In the patch itself:
- new API to use signup form panes, defined with hook_signup_pane_info().
- new UI in node settings admin to enable and order panes.
- Name and Phone fields removed from the code. Update.php will enable the signup_basic_form module and add its pane to existing signup nodes to preserve their functionality.
- a new alter hook, hook_signup_form_data_display_alter() to allow pane modules to affect the data output of a signup. This is called from the hardcoded admin listing of signups, the view field, and email output.
- a tweak to the data output with this in mind: if a key is numeric, it is not printed as a label. (This is mostly a workaround for webform providing the label itself, so we'd end up with it twice.)
- the view field for signup form data adds additional fields to the query so it has enough data to call hook_signup_pane_info().

In the zipfile are some modules that implement panes:
- signup_basic_form -- you need this one to try the patch!
- signup_profile -- provides a signup pane for each profile category
- signup_webform -- provides a signup pane for each webform node
- signup_pane_example -- a simple example of how to implement your own pane, with documentation. Can be used as a starting point.

All the code in this patch and the zipfiles is available at http://github.com/joachim-n/signup as the complete signup module folder.

I've set this up on a dev server, from the files at githib (rather than running a patch) and with a bit of configuration, have it working.
Is is exactly what I was after, especially as I am needing to gather extra information from anonymous users . . .

I have found is that the tick boxes for 'Default signup information' are not saving :
admin/settings/signup

Also, I had an existing 'Page' content, then added this updated version of the module, and now get this error if I turn on Sign Up :
Fatal error: Call to undefined function () in //sites/all/modules/signup/includes/signup_form.inc on line 92

Any new content created does not have this error - and I did run the update.php after updating the module . . .

Cheers !

> Also, I had an existing 'Page' content, then added this updated version of the module, and now get this error if I turn on Sign Up :
Fatal error: Call to undefined function () in //sites/all/modules/signup/includes/signup_form.inc on line 92

I see what that problem is. The 6200 update adds the 'Basic' pane for to preserve old signup nodes as they are; during later development of the patch I changed the API to store the callback.

I'll need to change this line to set the callback too:
$ret = db_query("INSERT INTO {signup_panes} (nid, pane_id, weight) SELECT nid, 'basic', 0 FROM {signup}");

@Darrin Southern in the meantime if you feel like hacking your DB you can set the {signup_panes}.callback column to 'signup_basic_form_form' where it's blank.

Less sure about the admin default stuff but will look into it...

Thanks for testing! :D

Note to self for the admin settings stuff:
- save default panes in signup_settings_form_submit
- load them up where signup loads from {signup} with nid = 0
- fix the warning in signup_webform when a webform is being deleted so it can handle the case when the webform-related pane is being used on the default nid 0.

I've fixed the problems reported in #71; new code is on Github.

As I'm doing this work for a client, I've got a test site running. You can give it a spin at http://www.name.org.uk/signuptest/ -- authenticated users can create signup nodes.

I've adding the new signup to a new dev site, and tried to configure SignUp, gets this error :

user warning: Table 'drupal.profile_fields' doesn't exist query: SELECT category, COUNT(*) AS count FROM profile_fields WHERE visibility <> 4 GROUP BY category in /home/drupal/public_html/sites/all/modules/signup/modules/signup_profile/signup_profile.module on line 58.

installing the module does not report that an update is needed to be run, and running it anyhow does not run any update scripts . . .

Oops. I forgot to put {} on the table name!

  $result = db_query("SELECT category, COUNT(*) AS count FROM profile_fields  WHERE visibility <> 4 GROUP BY category", PROFILE_HIDDEN);

Fixed on github.

That's better : )
Are you sure you can't add 'Content Profile' support too ?
( I know you mentioned you would leave that to someone else)

I did have one suggestion, that in the SignUp Admin, that there are separate options to enable/disable Name, Phone and E-mail.
As an example, I already have a Webform with these three fields, and I could turn the SignUp fields all off.
It would also allow the SignUp to have Name, but not have Phone or Email, as these may not be required . . .

Cheers !

The signup basic pane module is really there only for backward-compatibility with people's existing signup-enabled nodes.

If you want Name and phone number fields on new signup nodes, they should really go on Profile(*), as they are things that are constant to your user. The benefit is then that the user won't have to enter them more than once on the site.

(*) Or content profile, eventually... :D

Doh!
Except the case where you're having anonymous users signing up... you'd want to use the Name and Phone then probably.
Or maybe webform!

At any rate, an option to split up Name and Phone is beyond the scope of this patch.

I could however put in another form callback into the info hook to allow panes to have a settings operation to configure this sort of thing.

I'm with you, I'm just thinking about my 'current' client who needs this functionality, and who has 'other' particular needs . . .

they are wanting anonymous users to fill out the form, and for the user to be added to Campaign Monitor via the Webform (which would may mean two e-mail fields), with the fields in this order :

Name
Position
Organisation
Email
Contact Telephone Number
Address
Phone
etc.

Basically I'm looking at having a custom order of the fields, and where Name and Email are not from an authenticated User.
Perhaps if the Sign Up E-mail field was 'exposed' in the Sign Up Admin pane options, and it could be re-ordered . . .

Rock on! This is incredibly exciting. Sorry, but I was slammed in Nov + Dec with a combo of core work for D7 (Update manager), paid work fires, and personal crisis. Then, I was completely offline for 2 weeks over new years, and just now catching up with everything. Given how many hats I wear (both in and out of the Drupal world), signup.module tends to suffer through longish periods of neglect. Apologies about that. ;)

Given that I'm still trying to fix some stuff in D7 core before the alpha1 release, I won't be able to look closely here until probably next week. But, I just wanted to comment that this is all sounding fantastic. A few questions, in no particular order, based on a quick skim of the last ~25 comments or so...

A) Does each pane-implementing-module do its own data storage?

B) What's the fate of the existing serialized {signup_log}.form_data field?

C) What about an upgrade path for sites that have customized their signup form and don't just have the default name/phone fields?

D) What about tokens for signup form pane fields (e.g. for use in signup emails and other places)?

I'll certainly have more questions when I start looking closely at the code, but some overview architectural pointers would be most appreciated before I get into the patches.

Thanks!!!!!!!!
-Derek

@dww:

hi! :D

A & B: Yes and no ;)

A pane module may either:
- catch its data on hook_signup_data_alter(), and store it. This is what signup_profile does.
- if it does not unset its data keys from the $signup in hook_signup_data_alter(), then the data gets serialized in {signup_log}.form_data

C: I'd need people who have this setup to look into this. By customizing you mean with the theme layer? The only issue might be that the signup form array has keys one level deeper now.
There is not much work involved for sites to convert a theme-based form alteration to a signup pane. The steps would be:
- define hook_signup_pane_info()
- move your form altering code from the theme to your module's pane callback
- saving of data to {signup_log}.form_data is will still work as before.

D: I don't know about this... can you fill me in briefly on what this does? I've not changed the current signup core stuff that collects an email for anon users.

Architecture: Look at signup_pane_example.module for an overview of how it works, and #70 above where I give a rundown of what's in the patch.

@Darrin:

Do you mean that signup_confirm_email module should be converted to being a pane? Yes, that's definitely an idea, as a follow-on to this patch maybe.

Otherwise, for the rest of your use case I'd say use webform for all of your data, or write a custom pane to collect it all -- or even better, you could write a module that provides a pane specifically for to Campaign Monitor?

... and @me:

> I could however put in another form callback into the info hook to allow panes to have a settings operation to configure this sort of thing.

Duh... there's already an operations setting in there, but it could do with improving so the node settings link can optionally pass the $signup sid in case a pane module wants to configure per node.

Re: "D: I don't know about this... can you fill me in briefly on what this does?"

It'd let you define reminder emails like this:

Dear [username],

Thanks for signing up for [title], which will start at [field-date].

You said you wanted a [signup-form-meal-type] meal.  If you need to change that, please visit:

[signup-edit-link]

before 4:00pm PST on [date]

See you there!
- [sitename] Team

(or something). In particular, it's that [signup-form-meal-type] part I'm asking about. Currently, there's just a giant [signup-user-data] token for all the custom form fields. I'm not sure how that's going to work in this new system. And, ideally, there'd be an easy way to split out separate tokens for each field in each pane. That might be impossible. But, it's worth considering how to make the token support work properly in this whole system.

More later...

Ah... right.

Well, I had to create a hook_signup_form_data_display_alter() so modules that remove their stuff from the $signup->form_data array can put it back in for display: the signups list, views, and the notification emails to admins. So that could feasibly get another $type call to return tokens maybe?

About the architecture of hook_signup_pane_info(): you define one or more panes, with a unique pane ID as your array key. Each pane defines a label, description, and a form callback.
Each node's enabled panes are stored in {signup_panes} with nid, pane_id, weight, callback.
Originally I was just getting the form callback back out of hook_signup_pane_info() but that means invoking the whole hook on node display which is expensive. The other alternative I considered was having a standard function name for the callback, (ie MODULENAME_signup_pane_form or something) but the problem with that is that module_invoke_all() doesn't actually give you any info about which module supplied what data. (See for example how block.module has to jump through hoops to know which module to call for which block). Even if we did that we'd be having to store module name in {singup_panes} so it's an extra field in the table regardless.
There's also an array of operations that hook_signup_pane_info() can return, which I'm about to slightly tweak today ;)

> I could however put in another form callback into the info hook to allow panes to have a settings operation to configure this sort of thing.

I'd forgotten I already had an 'operations' key in the info hook.
It was, however, a bit deficient for the sort of purposes we're talking about here, so I've improved it. Full docs in signup.api.php, and there's an example of it in signup_webform.
New code on github.

Re: #83
Both places in signup.module where token_replace_multiple() is called have had their $signup object already run through hook_signup_form_data_display_alter(), so all pane modules will have inserted or formatted their data for output.
(Incidentally, if it weren't for backward compatibility considerations, this would mean we could fix the slight oddness of the $form array keys for Name and Phone having to also be the human-readable labels in title case.)
I'm less sure about the other places token_replace_multiple() is called such as cron.inc. Might need your eye on it as I'm not sure on the flow in some parts of the code.

Is there anything specific that needs testing in this latest patch ?

SignUp + Campaign Monitor + Anonymous Users.
I'm wondering if 'duplicate' fields (fields in both SignUp + Campaign Monitor eg: Name, Phone and e-mail) could be set as 'hidden' in the webform, and the content auto entered from what the user enters, via a Default value . . .

Any thoughts ?

@Darrin: I don't know Campaign Monitor at all; what I was suggesting off the top of my head was that you could make a pane that collects everything you need for Campaign Monitor and sends the data to that module's own storage. You'd then enable only that pane on your node, and not the basic 'Name and Phone number' at all. If you made that as a custom pane module then it could be reused wherever you want to use Campaign Monitor.

Standard Webforms send it's data to Campaign Monitor via the Additional Processing, using php code.

$name = $form_values['submitted_tree']['name'];
$email = $form_values['submitted_tree']['email'];

We are not able to target the fields 'back' within the webform, when it is embedded inside the Sign Up.

$name = $form_values['webform_30']['name'];
$email = $form_values['webform_30']['email'];

we can't turn off the Sign Up email field, so we would need to use it, rather than have an email field in the Webform

$email = $form_values['submitted_tree']['"email_address"'];

What we would like, is for the Sign Up to also have Additional Processing, so we could target the fields via php

I don't really follow all that, as I've never used CM before and don't know how it works with other stuff.

You can use hook_signup_data_alter() to get the signup data and save it however you want, if that's what you mean by additional processing. You can get the email out of the $signup at that point and pass it along to CM.

What are people's thoughts on how Profile module should behave with anonymous signups?

As far as I can see, the options are these, or a combination of them with admin settings to choose:

- a) create a user account based on the entered anon email and so store the profile data there (a la Ubercart)
- b) give the user the choice of creating an account as they sign up
- c) just don't show this particular pane and don't collect data
- d) don't allow anon signups on nodes that have a profile pane on them (can this be done per node?) /
- e) -- or warn admins that this is an invalid choice if anon users have the permission to sign up
- f) (crazyland, not going to happen, would cause all manner of problems with things such as Views) Store the data for anon users ourselves.

g) provide a configuration option to allow the admin to choose whether a new account should be created or the pane is hidden (and filled with "Anonymous")

There no need to worry about Campaign Monitor (CM) - all that is required is to have 'Additional Processing' for the Sign Up itself, which is already part of the standard Webform 'Webform advanced settings' . . .

As for anon options, the particular client (this solution is for) does not wish to store user data in a user account, as they are generally not repeat visitors, and if they come back, it may be 12 months later . . .

This would go against most case studies, as most would like to store the user, or at least have the option, and therefore what @stBorchert is suggesting would be preferred . . .

> the pane is hidden (and filled with "Anonymous")

Hiding the pane is possible.
But bear in mind that we can't store data for 'Anonymous' with Profile module. It simply doesn't account for data that does not belong to a user.

I would love to have an account created - thus option a (or g) would make most sense IMO. Even if the user would come back not earlier than after 12 months, it is still useful for the admins to have all signed up users available as Drupal users.

I have now tried your latest GIT version, joachim. Whenever "update.php" is called, the following warning appears on the page's top:

Warning: Call-time pass-by-reference has been deprecated in /etc/drupal/all/modules/joachim-n-signup-1d81781/signup.install on line 533

Joachim, in addition to the warning mentioned above which appears every time when going to update.php (even when all signup modules are disabled), you get a real error when proceeding with the update.php (after another module has been updated). So the current dev version prevents the whole system from running update.php properly - this seems like a critical bug to me. See the attached screenshot.

Those are two consequences of the same bug; I've just updated Github with the fix.

Thanks for testing and reporting!

Wow - thank you for this superfast fix! Can confirm the update.php problem is now gone.

I am trying the latest code from git (last updated 2010-01-22). Because for my case only anonymous users will sign up, I have only enabled the follwing two modules of the "Signup" package:

  [+] Signup
  [ ] Signup basic form
  [ ] Signup confirm e-mail
  [ ] Signup pane example
  [ ] Signup profile
  [+] Signup webform

The version of the Webform module is 6.x-2.9. As long as I have no published webform nodes, the warning

warning: Invalid argument supplied for foreach() in /etc/drupal/all/modules/joachim-n-signup-da48896/includes/node_settings.inc on line 368.

appears after pressing the [ Save configuration ] button on the Signup settings page (admin/settings/signup).

Line 368 of node_settings.inc is the start of the following loop:

  foreach ($form_state_values as $pane_id => $form_state_values_panes) {
    if ($form_state_values_panes['enabled']) {
      $signup_panes[$pane_id] = $form_state_values_panes['weight'];
    }
  }

Once I have at least one published webform node, these nodes are available in the Signup form panes table and the warning will no longer appear. It's only a little cosmetic thing, but I thought it could be useful to others when I report it.

I've committed a fix. (You were right, it's because there are no panes at all to save, so the code was trying to iterate over a non-existent array and PHP is annoying like that...)

However, in trying this bug out I've uncovered a nasty flaw in my whole implementation: if you disable one of the pane modules, say, signup_webform, and then try to look at the signup node, then signup module still tries to call the callback, which is in a module that isn't enabled any more. Result: big fat PHP failure!

The quick fix is to do a function_exists(); have fixed this too.

(I have wondered whether a block module-type pattern would be better, where you save the module name and call a fixed-name handler function with a delta (or in this case an ID), but I think it's swings and roundabouts, as you still have do check the function is okay to call by checking module_exists(); and instead of module_invoke_all() to collect information about panes you have to do some not very pretty mucking about.)

Thanks for your continued help in ironing out the bugs!

Excellent! I can confirm the problem has been fixed with the latest Git code (2010-01-25 00:58) :-)

I have created and published a Webform node with some components, so that this node appeared in the list of available Signup form panes under "Default signup information" at admin/settings/signup. I have ticked the "Enabled" checkbox for this pane only and saved the configuration. I thought that this pane would be available *and* enabled per default on all signup enabled nodes. The pane was indeed available to all individual signup enabled nodes, however disabled per default. So I had to explicitly enable it at node/[NID]/signups/settings. Is this the expected behaviour or shouldn't it be enabled per default?

"Default signup information" at admin/settings/signup affects new nodes. It's working for me:

1. enable some panes at admin/settings/signup
2. create a new node
3. go to its pane settings -- they match what I set at admin/settings/signup

this also works:

1. create a new node with signups disabled
2. enable some panes at admin/settings/signup
3. enable signups on the node
3. go to its pane settings -- they match what I set at admin/settings/signup in step 2.

Here is a new bug report:

In both the confirmation e-mails sent to the registrant and admin all fields are missing in the %user_signup_info (SIGNUP INFORMATION) when they are under a fieldset. So currently it is not possible to add a Webform pane with fieldsets. All fields must be defined directly under the root parent.

Another bug in the confirmation e-mails is that no fields are included in the SIGNUP INFORMATION that are of type "textarea". The only included fields that I can yet confirm are those of types "textfield" and "select".

Third problem regarding the SIGNUP INFORMATION (also applies to the "Additional info" column in the signup_user_vbo_admin_list view: the sort order of the fields does not respect the webform components weights - so the displayed fields are unsorted at all and look messed up.

The webform integration does not support all of webform's possible complexities: filedsets aren't supported, and I only implemented the basic field types. I imagine that this module would be its own contrib project rather than part of this patch, and would need more work, though it may be that some things will always be too complex!

I see, joachim - now where I know the limitations of the current Webforms support, it's no problem - I think what it currently supports is sufficient. The only annoying thing is the unsorted, random appereance of the fields within the SIGNUP INFORMATION. Do you think that could be fixed easily?

And thank you for clarifying things in #103. I'm not sure what happened to me - anyway it works as you described it.

I'm sorry, but I'm not able to find the correct answer: how can I insert fields (btw. their values) from a webform?

Thank you!

Pál

I'm not sure I understand your question.

You insert a whole webform, available as a pane for the signup-enabled node. As pointed out above, not all webform field types work yet.

subscribing. Looks amazing!

really good job!!!!!

Hi Quartz! :D
Thanks for giving this a spin and reporting the bug.

I believe all those error messages are the result of the same problem (missing [] in the update function). That is now fixed on github.

As for documentation -- I can add something to the README.txt file. All signup panes come from separate modules, so yes, you need to enable the ones you want to use.

This module still lacks a handbook page though -- once that's set up, and this patch gets in, I can add to that.

I've added some docs to the README.txt on github.

I think I may have to very slightly change the API...

I am now looking at getting Ubercart attributes into a signup form pane, so these can be specified at the same time as the other signup data, in one form. Since it might be that not all signup-enabled nodes are products, hook_signup_pane_info() should be passed an optional $nid so implementations can decide whether or not to return information about their panes.

Are you also planning to fix the unsorted, random appereance of the fields within the SIGNUP INFORMATION, as mentioned in my reply #104?

Hmmm unless I go the other way, and have the user buy the product with attributes as normal, and then have Signup insert the whole signup form with panes somewhere further in the Ubercart process.
I'll have a look at http://drupal.org/project/uc_signup to see if it can be expanded to include a signup pane step.

Subscribing. Love the module even as is -- thanks to original developers and DWW. And, appreciate the work of joachim.

@joachim: I used your first version on github, just changed it with the newest version and ran update.php. Now I got these errors. Did I do something wrong?

* user warning: Table 'signup_panes' already exists query: CREATE TABLE signup_panes ( `nid` INT unsigned NOT NULL DEFAULT 0, `pane_id` VARCHAR(32) NOT NULL DEFAULT '', `callback` VARCHAR(255) NOT NULL DEFAULT '', `weight` TINYINT NOT NULL DEFAULT 0, UNIQUE KEY nid_pane_id (nid, pane_id), INDEX nid (nid) ) /*!40100 DEFAULT CHARACTER SET UTF8 */ in //includes/database.inc on line 529.
* warning: Invalid argument supplied for foreach() in //includes/module.inc on line 300.
* user warning: Duplicate entry '0-basic' for key 1 query: INSERT INTO signup_panes (nid, pane_id, callback, weight) SELECT nid, 'basic', 'signup_basic_form_form', 0 FROM signup in //sites/all/modules/signup/signup.install on line 537.

The following queries were executed
signup module
Update #6200

* Failed: CREATE TABLE {signup_panes} ( `nid` INT unsigned NOT NULL DEFAULT 0, `pane_id` VARCHAR(32) NOT NULL DEFAULT '', `callback` VARCHAR(255) NOT NULL DEFAULT '', `weight` TINYINT NOT NULL DEFAULT 0, UNIQUE KEY nid_pane_id (nid, pane_id), INDEX nid (nid) ) /*!40100 DEFAULT CHARACTER SET UTF8 */
* Failed:
* The Signup basic form module has been enabled and the basic "Name and Phone number" pane has been added to your existing signup-enabled content.

EDIT: beside those errors everything is working fine ! The signupform looks great and it works just how I want it to work. Thx Joachim for the work. It's great !

Did you explicitly get it to run update 6200?
Your system may have been in a no-mans-land state, in that I've gradually added things to update 6200 while developing the data storage. So after your first installation you would have had *some* of the changes it makes, but not all, and if you specifically got it to run 6200 again, the {signup_panes} table would already have been there.

I explicitly run update 6200 because I had a few problem you fixed a few days ago. So I guess I allready had 6200. And that explains it all.

Problem solved ;-) Thx anyway for the quick response.

joachim, would you mind answering my question at #115? I would have loved trying your revamped module in a live shot at
http://lund2010.healthgrain.org/registration but had to revert to a pure Webform 2.9 node because of this problem. Thanks.

@roball: do you mean about the webform fields being in the wrong order within the signup?

Yes.

I downloaded the source from github, replaced, and ran update.php. I got the warning and one Failed:

warning: Invalid argument supplied for foreach() in /var/www/drupal/includes/module.inc on line 300.

The following queries were executed
signup module
Update #6200

* CREATE TABLE {signup_panes} ( `nid` INT unsigned NOT NULL DEFAULT 0, `pane_id` VARCHAR(32) NOT NULL DEFAULT '', `callback` VARCHAR(255) NOT NULL DEFAULT '', `weight` TINYINT NOT NULL DEFAULT 0, UNIQUE KEY nid_pane_id (nid, pane_id), INDEX nid (nid) ) /*!40100 DEFAULT CHARACTER SET UTF8 */
* Failed:
* The Signup basic form module has been enabled and the basic "Name and Phone number" pane has been added to your existing signup-enabled content.

Vertical tabs?
I played with this a bit further and somehow got an event node edit form corrupted - one Event node with signup through webform suddenly appeared unpublished and the author changed from user1 to anonymous (as listed under Content > Edit.) In the edit form for that node the Author and Publishing options fieldsets are missing. The node was sticky before getting unpublished.

I signed up to the event, then an anoynmous user signed up, I think it happened after this.

I use vertical tabs, after disabling that module the corrupted node edit form got fixed. When I enable it the problem is back.

I can't reproduce it on other nodes, but I do get a warning on another event node (just one node):
warning: Invalid argument supplied for foreach() in /var/www/drupal/sites/all/modules/signup/includes/signup_edit_form.inc on line 112.
This node didn't have any node edit form problems.

Any debug tips?

@125:

- This patch doesn't change anything on node edit forms. Try vertical tabs without the patch, see if you get the same problem.
- Your line 112 warning -- did this node have any panes enabled at all? I'll check but I'm pretty sure form_data should always get saved as at least an empty array.

@124.
What is line 300 of your module.inc? On my version of core there isn't a foreach there.

@123 ?

@123:
I haven't yet had time to look at that. The way webform creates forms with weights and all that is complex.

I see. Thanks for the answer!

I didn't apply the patch, I simply downloaded the source and replaced the module folder, so I can't revert the patch. Should I uninstall and install regular Signup to test vertical tabs?

Re: signup_edit_form.inc on line 112 When I go to Signup on that node I get WSOD (signups), but signups/admin and signups/settings work ok. The enabled pane is Name and phone number.

Re: update.php this is from my module.inc, lines 292 to 308, foreach is line 300

/**
 * Enable a given list of modules.
 *
 * @param $module_list
 *   An array of module names.
 */
function module_enable($module_list) {
  $invoke_modules = array();
  foreach ($module_list as $module) {
    $existing = db_fetch_object(db_query("SELECT status FROM {system} WHERE type = '%s' AND name = '%s'", 'module', $module));
    if ($existing->status == 0) {
      module_load_install($module);
      db_query("UPDATE {system} SET status = %d, throttle = %d WHERE type = '%s' AND name = '%s'", 1, 0, 'module', $module);
      drupal_load('module', $module);
      $invoke_modules[] = $module;
    }
  }

btw on another website I have event with webform pane, but I also get an email field displayed on top of the webform, so I have two cos webform also has an email field. I don't have Signup basic form enabled there.

The extra email seems to have appeared because I had enabled the module Signup confirm e-mail. But it doesn't show up in the interface where you choose panes. It would be great if it appeared there so you can choose to enable it for some nodes and not for the other (webforms).

The same goes for Profile fields, I have the module enabled but it doesn't appear as a separate pane. Maybe I misunderstood how this worked?

#131: I figure Signup confirm email could be ported to the pane system as a later issue once this patch is in.

I have a use case that calls for the fields to appear on the next screen after the user clicks "sign up." Of course the fields would have to be customizable so I thought about using cck and creating a content type. It seems to me that hacking signup to go through a node add for that content type and then linking the nid from the signup node and the nid for the "things specific to the event" would be a useful approach. Does this seem like a wise approach? I haven't tried webforms and I was hoping this might be a useful hack that others might be able to use also.

I know uc_node_checkout does something like this but it lacks the other cool stuff that signup has. I am planning to borrow heavily from uc_node_checkout. In an ideal world, this will also allow folks to update profile fields if they need to.

thanks
Selwyn

@joachim great work, thanks for all the efforts.

@dww any chance of this getting integrated and released or even a dev version?

+1.

dww, what do you think about letting joachim join you as a co-maintainer of the Signup module?

Fantastic work joachim. Is there anything in particular that we should be testing/improving to help get this committed?

I could do with help on getting more of webform supported -- the field weights and more field types too.
Feel free to fork the project on github :)

@joachim, I had a few question about how we should make use of the new hooks:

We are encouraged to handle our own data storage in hook_signup_data_alter(), but at this point, a new signup will not yet have its own sid. This makes it hard to keep our stored data connected to a particular signup; how should we work around this? signup_save_signup($signup)?

If we do handle our own data storage for the panes that our module provides, how should the form data be inserted into the edit form? Should we query the database in the form callback function and attach the data to the form element's '#default_value' attributes?

@dboulet:

Regarding saving: you need to do it in two stages. Take a look at signup_webform_signup_data_alter() and signup_webform_signup_insert().

Regarding loading: yup, if you do your own storage, load up what you need and set '#default_value'. See signup_profile_form() for an example.

I should really add more details about all this to signup_pane_example.module, but I might not get round to it for a few days, so do feel free to branch me on github if you want to beat me to it :)

@joachim, check out my fork on Github ; ).

@dww, Could you chime in here and let us know what your plans for the module are? Are you planning on integrating joachim's approach presented here? It would be great to get something like this committed, even to a new dev branch, so that we could start integrating it into other modules that could make use of it (ex. uc_signup).

Quick update:

- I've merged in dboulet's changes on Github.
- made an API change to hook_signup_pane_info to allow panes to be selective according to node
- I've started work on Ubercart attributes support, but this is not committed to github yet. (This is what the API change was for, so only product nodes get a product attributes pane.) Expect rough initial work shortly.
- regarding weights and field types for webform: weights appear to work, and textareas work too.

I'm not getting text areas in the email notifications to the site owner, is this webform problem or signup (I'm using the version from github from Feb 10th)?

Edit: I check with the same webform - when using only webform the text area comes in email, but when using that same webform in signup it doesn't come.

Should I try the latest github code? Is the upgrade procedure as usual?

Is there a place where I can see email output without laboriously sending myself emails?

As for github -- compare the date of your download with the commit history there. I don't think there have been changes to the webform integration for a while.

subscribing

If you find the way to see email output I'd also like to know :)

Maybe Simplenews can help?

@portulaca: I rather meant a place in the module where the data is processed in the same way but output to the browser directly. Simplenews does test emails but otherwise as it creates nodes it has no need to output the emails.

I've updated github:
- some more changes from dboulet
- signup_uc_attribute module: again, this is most likely external to this patch, but it's on github so I can work with the whole thing as one and for ease of testing. This allows an Ubercart product node to be enabled as a signup, and its product attributes form to be shown as a signup pane. Signing up to the event then adds the node to the cart. There are a few things that still need doing. From the notes in the module comments:

This is tied in with uc_attribute because I don't see a way of having the connection
to UC in one module and the handling of attributes in another. Both would
want to call uc_cart_add_item(); or the uc_attribute glue module would
have to alter the product already in the cart and it seems messy. But
suggestions welcome!

@todo
- disallow UI cancellation of a UC signup
- deal with signups put into the cart but never bought: cancel them on cron?
consider making this feature as a standalone module so non-paid signups
can use it too somehow. (ie signups that need confirmation?)
- data storage to link signup SID with the UC order

Help with testing and coding this would be very welcome!

@joachim, is your new ubercart module meant to replace the functionality of the existing uc_signup module, or is it meant to work alongside it? Are you planning on submitting any of this as a patch towards that module?

I spoke to ezra-g about UC Signup a while back and he said he'd take a look at the patch here.
I've not heard back from him yet and I need to move forward with this for a project.

It's a different approach to the uc_signup module, and doesn't require it. If this patch gets in, then I think this could similarly become the 2.x branch of uc_signup. (I should probably have kept the name the same... but that can be changed.)

Hey @joachim,

It's been ~100 followups on this issue since you posted at #623900: API for additions to attendee info form and I haven't totally been following, but the screenshot at http://drupal.org/node/29568#comment-2455902 looks pretty sweet!

Looking quickly at the patch, I notice you're storing the nid as well as the callback for a pane in the database. What's the motivation for making this configurable on a per-node, rather than per-node-type basis? Seems like per-node adds a lot of complexity and multiple entries in the DB per node but I'm not sure why that level of granularity is necessary.

The callback is the function that "renders" the pane, and forms generally have several callbacks (generate a FAPI form array, validate, submit). How did you decide to store that callback in the DB, and what do you think of having the callbacks defined in code, rather than in the DB?

Also, I never realized until just now that your desired feature was also Ubercart related. Does that mean you created a separate module that does the same thing that uc_signup does?

> Looking quickly at the patch, I notice you're storing the nid as well as the callback for a pane in the database. What's the motivation for making this configurable on a per-node, rather than per-node-type basis?

Current client spec :D

The site will have an 'event' content type. Each event may be different from its predecessors and require different information. For example, some events may offer childcare, some may run over several days, etc.

> The callback is the function that "renders" the pane, and forms generally have several callbacks (generate a FAPI form array, validate, submit). How did you decide to store that callback in the DB

This was to prevent having to invoke hook_signup_pane_info() on node display to find out how to render panes. I'm open to ideas for a better pattern! :D

Bear in mind though that the combination of pane ID and originating module is not sufficient, as some modules supply more than one pane ID, and furthermore in cases such as webform they have just the one callback for all those IDs.

IIRC, I originally had a standard function name for the pane form callback, something like MODULE_PANEID_form(). I dropped that for webform and profile to work, as they have dynamic pane IDs (which include webform nid and profile category respectively). For those modules to work with this system, we would need something like hook_forms() to specify a 'factory' callback for their pane form callbacks.

And at any rate, we'd then need to store the module name in {signup_panes} as well as the pane ID. Therefore, I figured that storing an extra column be it module name or callback makes no difference, and storing the callback is simpler. (It did seem a weird thing to do at first, until I thought of the menu system....)

> Also, I never realized until just now that your desired feature was also Ubercart related. Does that mean you created a separate module that does the same thing that uc_signup does?

The uc_signup_attributes module that is now on github should really be a 2.x branch for UC signup once this patch gets in. I would be more than happy to collaborate on that. I have to forge ahead and get the code wrapped up in the next few weeks though :)

Hey-
Thanks for the great work on this module.
Is there any way I can implement the Signup Panes module functionaliy now? (http://www.name.org.uk/signuptest/)
I would also need the printable CSV sign up roster functionality that was supposed to be in Signup Status, but that module
dosen't seem to work at the moment.
I need this for a client and can pay for immediate implementation. Please contact me via contact form or tsaks@liefa.com
Thanks!

Here is a test signup node that is also an Ubercart product: http://www.name.org.uk/signuptest/node/15

There are quite a few things to smooth over still and either Ubercart or Signup may well throw up various crannies and weirdnesses I've not considered. Please try to find them! :D

Nice to see this in action. I was able to sign up for the same node and get a confirmation email 2x with the same email address. Also, for sites with a limited # of spots, I would think that we wouldn't want to confirm the signup until they've paid, but that may not be a requirement of yours.

Regarding spots: it's all a big race condition -- smoothstr did a v good presentation at DrupalCamp Manchester last year about how complex this is.

Currently, the signup gets cancelled when Ubercart expires the cart. This should work fine for online payments, but with sites that use COD / cheque, I guess it's up to site admins to decide when to mark an order as incomplete due to no payment received by post. There probably needs to be some glue there to cancel the signup at that point.

> I was able to sign up for the same node and get a confirmation email 2x with the same email address.

Hmm... anon user, right?

Does signup module check for duplicate email addresses anyway? If not, this is an issue on signup separate to this one.

> I was able to sign up for the same node and get a confirmation email 2x with the same email address.

I've checked this and I correctly get: "The email address entered has already been used to sign up for this Product event"

I see on the test site you've used ezra+jcs@ and ezra+gvs@ -- those email addresses will be considered different by Drupal. (A very useful feature when creating throwaway test accounts!)

Hello.

joachim:

I've provide your mod of signup with the webform, is what I needed, congratulations.

But it fails when, in the webform, there is a file field.

By submitting, the path goes empty.

(I downloaded the files from your repository).

Not all webform field types are supported yet, and I don't plan to do much more work on webform integration. If anyone wants to pursue it, I'll merge github branches or try to incorporate it into the patch here one way or another :)

Hi Joachim, Derek,
I'm following this thread with great interest. Some good progress here!

1) I'm very interested in a good workflow with custom fields through uc_signup/ubercart, using PayPal. So far uc_signup seems to care only about profile form... @Joachim, what are your plans here?

2) Re-raising the question of tokens:
Last year when building a small site I used custom template_signup_user_form() to add fields to the signup form. It worked well for the site that only has one type of signups, and can be actually scaled to other types within the add-on code. The downside was that it provided no tokens for these fields in the emails. So I patched signup module to expand the serialized data and add to the tokens array for generating emails. My patch also included a sort handler for views, so sorting can be done on any of the additional fields.

It looks like Joachim's fields patch does not change the storage method (or does it?) - then my approach would still work.

If anyone is interested, I can share this patch here.

3) From the commits activity and issue queue, one would have a feeling that signup.module is abandoned. Though I realize that Derek is busy attending to core development and other stuff, this issue needs a lot of caring, which Joachim is providing. Someone already proposed making Joachim a co-maintainer. I second that proposal - it looks like Joachim can contribute in very much needed area.

@Joachim, would you rather commit to the CVS and know that your changes will not end up on the sidelines?

@Derek, if you agree that Joachim is taking this module in the right direction, and you agree to make him a co-maintainer, you will have free help and time to do other higher-level stuff, so what do you say?

--
Ilya

> 1) I'm very interested in a good workflow with custom fields through uc_signup/ubercart, using PayPal. So far uc_signup seems to care only about profile form... @Joachim, what are your plans here?

See the latest code in Github. I've added a module that could become the 2.x branch of uc_signup (though due to bad planning I've called it signup_uc_attributes...) Demo here: http://www.name.org.uk/signuptest/node/15

Basically, you sign up with the normal signup UI and this causes the signup node to be added to the cart. The normal cart expiry rules apply, and if your signup product is removed from the cart then the signup is cancelled. This means that a slot is saved for you once you sign up, but only for a limited time.

I'd really appreciate someone going over the code of that too, to check there aren't any funny corners of Ubercart I've missed off.

> It looks like Joachim's fields patch does not change the storage method (or does it?) - then my approach would still work.

Both :D If your module does nothing to store data, then the signup core data storage is used.

Regarding maintainership, Derek's already contacted me; he and I need to arrange to meet on IRC to chat about it :)

All great news! I will set up a test site and test-drive signup_uc_attributes. Sound like it is what I need.

Subscribing.

Subscribing

i have gone through http://www.name.org.uk/signuptest/ and it works like charm.

I have similar requirement and it will help me.

Just i need to know that your module will work like civicrm event module ? means if i have one signup fields ready through webform or profile, and before filling form there will be question that how many person want to signup (through dropdown of 1-10)? if they select 2 than form will be filled 2 times.

Thank you
Tejas Mehta

> Just i need to know that your module will work like civicrm event module ?

Well no, in that this will actually work :p

> means if i have one signup fields ready through webform or profile, and before filling form there will be question that how many person want to signup (through dropdown of 1-10)? if they select 2 than form will be filled 2 times.

There's a separate issue for this. I'm not sure how it's going to interact with the changes here -- the way it's looking, you'll get a single record that's marked as representing more than 1 person.

Hello joachim,

Thank you for your quick response. Just last question.

I checked uc_signup and it worked to register multiple person, so will your module work with uc_signup ? as it is different thing. it worked directly on checkout page.

Also In future if it is possible that such functionality will be available with your moudle ? i know its hard to tell but if you add such type of functionality than instead of using civiCRM lots of user can start using your module in combination with signup.

Thank you
Tejas Mehta

As I said above: There's a separate issue for multiple signup. I'm not sure how it's going to interact with the changes here -- the way it's looking, you'll get a single record that's marked as representing more than 1 person.

Hello joachim,

Is your module compatible with Webform 6.x-3.0-beta5 ? As to use webform_conditional this version of webform was necessary. Now When i installed this version at that time it allowed me to select webform from Signup Setting Page but it shows me error when i try to view page.

Error is like following

Fatal error: Call to undefined function webform_load_components() in E:\wamp\www\testing_sites\sites\all\modules\signup\modules\signup_webform\signup_webform.module  on line 124

Please have a look on it.

Thank you
Tejas Mehta

I would also like to see compatibility with the upcoming Webform 6.x-3.0.

Working on supporting webform 3 would mean having *two* versions of the patch. This patch is big enough as it is!

I expect the signup_webform module will go into its own contrib project, where it can have two branches.

Hello joachim,

We can understand your problem regarding patch but currently no solution for this error ? And also approximately when support for webform 3 will be released ?

Thank you
Tejas Mehta

> We can understand your problem regarding patch but currently no solution for this error ? And also approximately when support for webform 3 will be released ?

I developed this for a client's current project, and so I used the current stable version of webform.

If you want to go ahead and work on compatibility with webform 3, feel free to fork my version of the signup package on github: http://github.com/joachim-n/signup

Hi joachim,

i think this is really great work.

But i've one question. How can i validate a signup pane? I started to build an own signup pane (i just copied the signup_pane_example module and modified it).

But when i insert a function signup_pane_example_form_validate ($form, &$form_state) - it doesn't work. Do you have an idea, what could be the reason?

@Ilya,

I'd love to see the patch you mention in #158.

Thanks!

subscribing

is it just me or do profile fields show as a fieldset within the Signups collapsible fieldset? ( :$ ). Why use a Collapsible fieldset on an event? I whish there was a setting to turn this off in the admin settings section. If you want users to sign up for an event the form should be easily viewable / available. Is it possible to turn the collapsible fieldset off and just show the form?

:)

@#174: see admin/settings/signup, advanced settings.

@#171: I'd completely forgotten about validation! ;)
I've added that in, with a signup_pane_example_form_validate() in the example module. New code on github.

hey, but is it possible to disable the fieldset, I just want the form to be visible and the fieldset removed, maybe this can be fixed by css ?

btw, thank you for all the work Joachim :)

> hey, but is it possible to disable the fieldset, I just want the form to be visible and the fieldset removed, maybe this can be fixed by css ?

Probably; but that's really outside the scope of this issue.

subscribing

Firstly, thanks again joachim for your great work on this patch !

Here's some feedback from testing today (I've been on an other project since last testing) and I've updated to joachim-n-signup-4aa5a17 yesterday :

The fields in the confirmation email for the [signup-user-data-raw] block arrive in the email, with the fields in different orders each time.
And it would be great to be able to reference each of the fields via their own token, rather than the single block.

Also, you mentioned in #141 on March 4, that the textareas were now working, did you mean in the Webform weights, or the function for the tetareas to appear in the confirmation email ? With this current version, the textarea fields are not being included in the [signup-user-data-raw]

Feature Request :

is there a way to add a URL to the link for webform from within the Signup summary in the list of Signed up users ?
or a way to add a URL to the email that is sent to the administrator of the signup with the URL to the link for webform ?

I understand we can go to the main admin for the Webform submissions, but a direct link would be very helpful.
Particularly in my case, as the WebForm is also doing additional processing, and the admin needs to submit the webform, as the additional processing is not being called from within the Signup . . .

Thanks in advance,

Darrin.

subscribing

subscribing

@iva2k

Would you mind sharing the patch you mention in #158?

Thanks in advance

Laurent

Hi,

Great module.

However, I am having trouble with the views integration since I've installed the github version.

I am no longer able to display signup fields (Additional Signup Info) individually in views.
They are correclty displayed in the views if I don't setup any specific field name whereas no data is displayed if I setup a field name (eg. 'Name').

Thanks for your help

Laurent

Just a quick note to myself (or anyone who has time to look at this before I do... )

When cron is run, _signup_get_username() is called with a $signup object which doesn't have a nid.
This causes an error in signup_profile_signup_form_data_display_alter().

Subscribing.

I placed an issue for signup for ubercart to ask if content profile fields can be used during signup registration. It was marked as a duplicate of this issue.

Does the work in this queue allow for that to happen?

Does this work with content profile?

This does not yet allow content profile fields in a signup.

This wasn't needed for my project, and the matter of embedding a node form inside another form is a complex one because the node form itself is getting altered with all sorts of additions from things like taxonomy and CCK.

If you want to tackle it, I did start creating the basic scaffolding for this, and you're welcome to have it. I can create a branch for it on github and you can fork my project there if you like.

Much thanks to joachim, great work.

I gather that Panels is a requirement, from looking over the thread. So was thinking, is there or could be added here a list of dependencies / required modules ? And which versions it was meant for?

Nope, Panels is not at all a requirement.

The pieces of the signup form that are provided by different modules are called 'panes', same as in Ubercart.

subscribe. This is looking really good (and about to launch on a live site) only small issue is the ordering of the fields in the signup table. Ideally would be great to have separate fields for each so it could be easily used in views.

> only small issue is the ordering of the fields in the signup table. Ideally would be great to have separate fields for each so it could be easily used in views.

You can simply not enable that pane -- it only provides the name and phone number fields for backwards compatibility.

Yay! No panels, no pains. I mean just panes. Thanks again.

EDIT ---------------

Wanted to let the thread know, I now have a working dev site; with the download from the GitHub location. I am using the attributes option to remove the 'add to cart button'. So far so good, it all installed nicely and is working with ubercart. Have not tried the webform pane stuff yet...

I have this patch running on two live sites, and I know of others using it too :)

Also, I updated github yesterday with a small fix for a bug with using more than one webform pane in a single signup.

Seems like this signup patch would be compatible with some of the UC discount modules? I am trying to make a waiver with the attribute option but it shows a -2.00 in my example (see pic), which is odd for the end user.

For any problem with Ubercart integration, try to reproduce the problem without Signups. A quick way that usually works is to disable signup on your node and you'll get the regular UC form on the node.

I tried the latest out, all seems good but for one thing. I notice if I disable sending confirmation email, it is sent anyways, won't turn off. The setting (checkbox) does appear to save ok.

UPDATE

I created a 2nd event and with 'confirmation email' still disabled, this event behaves as expected, no emails go out. Conversely, the original event will still send them out. So seems to get saved at the event level, how ever the email switch was set at that time.

> I notice if I disable sending confirmation email

Nothing to do with this patch. Search for / file a bug! :)

RE #191 - Attached is an image to show how the fields are ordered differently for each submission. I'm using the webform options here, so I don't think disabling the pane would really help.

Huh, that's weird.

You may want to stick a sort of some sort either when those are saved or retrieved. I don't have time to look at this, but fork my project on github if you find a fix.

Ultimately, you probably want #680386: Views integration for the webform_submitted_data table which is still very much in progress.

joachim, one more dumb comment / understanding from me - it works with 'products' great but, 'product kit' is not supported by signup or this patch of signup ?
I was trying to sell a series of lecture events all together. Thanks for your patience. 8 )

> 'product kit' is not supported by signup or this patch of signup ?

No idea. I've never used product kits on Ubercart. I don't even know how they work, and a quick google for them shows little by way of documentation :(

Clean install of Drupal with the current dev version of signup installed. Installed the current version from GitHub, ran the update.php and this is what came back.

warning: Invalid argument supplied for foreach() in /home/britespark/domains/britesparkz.com/public_html/includes/module.inc on line 300.

Do you have the signup_basic_form module in your signup folder somewhere?

If so, then this is a bug in Drupal core, with trying to enable a new module within a hook_update_N(). There is probably a workaround -- haven't time to go hunting right now though.

Joachim: thanks for this. Just got a snapshot of your Git today, and found a bug(?) at signup_webform.module, line 124 and 280:

webform_load_components();
should be
webform_components();

Because otherwise the function doesn't exist.

Also line 443:
module_load_include('inc', 'webform', 'includes/webform.submissions');
otherwise function not exists webform_get_submission

Not getting the components displaying in the signup area, though, so this is not the full story...
Cheers!!
EDIT: Never mind...found that I had updated the webform to v 3... now have a whole lot of stuff to revert...

Joachim, I've installed your modules from github and everything seems to be working fine. Many thanks for your work on this.
Unfortunately, I can't use it without the ability for the user to signup a guest. Uc_signup allows this - is this something that could be included in the future?

> otherwise function not exists webform_get_submission

Which version of webform are you using? Is this perhaps something that has changed in a recent version?

> Unfortunately, I can't use it without the ability for the user to signup a guest. Uc_signup allows this - is this something that could be included in the future?

This is outside the scope of this patch. There is another patch in the signup issue queue for singing up guests.

Thanks Joachim - I found the patch in this comment http://drupal.org/node/45248#comment-2523210
It's a module which allows you to add anonymous signup guests. Combined with the webform integration that you have provided, I think I have a fix.
I installed that module and yours, and so far no glitches.

In case anyone else is struggling to see why their webform is not included in the list of option signup form panes:
Make sure your webform content-type is signup enabled.
Make sure your webform node is signup enabled.

> Make sure your webform content-type is signup enabled.
> Make sure your webform node is signup enabled.

No, that is not the way to do it.

Your signup node and your webform should be separate, and you choose the webform in the signup pane options.

Joachim, I just installed your module onto another site and received this error warning after running update.php
__________

warning: Invalid argument supplied for foreach() in /home/welshpae/public_html/includes/module.inc on line 300.

The following queries were executed
signup module
Update #6200

* CREATE TABLE {signup_panes} ( `nid` INT unsigned NOT NULL DEFAULT 0, `pane_id` VARCHAR(32) NOT NULL DEFAULT '', `callback` VARCHAR(255) NOT NULL DEFAULT '', `weight` TINYINT NOT NULL DEFAULT 0, UNIQUE KEY nid_pane_id (nid, pane_id), INDEX nid (nid) ) /*!40100 DEFAULT CHARACTER SET UTF8 */
* Failed:
* The Signup basic form module has been enabled and the basic "Name and Phone number" pane has been added to your existing signup-enabled content.

Joachim, I created a signup-enabled node.
After viewing the node I went back to delete your "favourite colour" field from the signup configuration.
As anticipated (from experience of testing this module), this configuration had no effect on the signup form fields for the exisiting content.

I disabled and re-enabled signups on the node to see if this would effect the new configuration on the signup form for the node.

The signup form remained unchanged and I received this warning:

user warning: Duplicate entry '205-basic' for key 1 query: INSERT INTO signup_panes (nid, pane_id, callback, weight) SELECT 205, pane_id, callback, weight FROM signup_panes WHERE nid = 0 in /home/welshpae/public_html/sites/all/modules/joachim-n-signup-226fc7e/includes/node_form.inc on line 72.

Joachim, I hope you don't mind me posting all these notes about the new module. I hope the feedback is helpful.

After signup for an event using your module, I receive 2 contradictory messages.

# The product Test Event 2 has been added to your cart. Your signup is temporary until you have completed checkout.
# Signup to Test Event 2 confirmed. A confirmation email will be sent shortly containing further information about this event. A reminder email will be sent 1 day before the event.

How can I disable that send message?

On the same note, is there any way that we could skip this stage and go straight to the user's cart?

Joachim, re:#209

I created the signup node and the webform seperately.
The newly created webform node did not show up as an option to chose in the signup pane options.
I made both the webform content-type and the webform node sign-up enabled, and then it displayed as an option to chose as a signup pane.

UPDATE: DOH! The webforms didn't show up as a signup pane option because they were unpublished, not because they weren't sign-up enabled. .

Another note on your module Joachim:

I am able to signup more than once for an event.
When I remove my signups from my cart I see the following message:

"warning: Invalid argument supplied for foreach() in /home/welshpae/public_html/sites/all/modules/joachim-n-signup-226fc7e/modules/signup_webform/signup_webform.module on line 473."

I just want to confirm the behaviour in #184.

I'm unable to specify individual fields from additional info for a custom signup admin view.I am able to display all additional info together in a single field.

> I am able to signup more than once for an event.

That's surely a problem with this module as a whole, rather than this patch.

(In general, could people try not to report problems due to base signup here? I am fielding a lot of these!)

> I'm unable to specify individual fields from additional info for a custom signup admin view.I am able to display all additional info together in a single field.

I'm guessing that's because the serialized array stored for the extra fields has changed its structure.

I don't have much time to work on this right now, though I will try to see dww at Copenhagen to move this patch forward to a commit.

Anything that other people can do to help with remaining niggles would be great!

Thanks Joachim, I've got your patched module going live tomorrow.
I've disabled Ubercart integration because it was throwing up too many niggly confusions for the user and I needed to get this out quickly.
The webform/profile integration to create the signup form works beautifully, and I've combined it with the "guest signup" patch I mentioned in #207.
The individual fields from the "additional info" are sent out in the confirmation/admin email, so the views integration problem is not a killer.
Thanks again for your work.

@pstead

does the patch work with just profile or also content profile?

http://drupal.org/project/content_profile

I don't know - what is content profile?

Why isn't joachim a co-maintainer?!? Seems these awesome improvements would be nice to eventually get committed. Subscribing.

Thanks for this great extension (rewrite) of the signup module.
Can I check that uc_signup compatibility is intended?

I have a problem using uc_signup when I want to allow users to access a webform for a particular event (a conference) and pay for it too. I get the following code output (my uc_signup default text is "Purchase a place")

<form id="uc-product-add-to-cart-form-14" method="post" accept-charset="UTF-8" action="/events/seec-conference-2010-credit-changes-and-challenges">
<div><input type="hidden" value="1" id="edit-qty" name="qty">
<input type="hidden" value="form-cd8a9bb49580f8a28a452233b037265e" id="form-cd8a9bb49580f8a28a452233b037265e" name="form_build_id">
<input type="hidden" value="2d7f53fb89a158a7f5a8695197910e78" id="edit-uc-product-add-to-cart-form-14-form-token" name="form_token">
<input type="hidden" value="uc_product_add_to_cart_form_14" id="edit-uc-product-add-to-cart-form-14" name="form_id">
Purchase a place
</div></form>

I'm willing to contribute to development...

Nope, this is a completely different approach to uc_signup.

Ubercart integration is within the patch here.

And all becomes clear...it's working for me.
Thank you for the quick response & this amazing patch

Subscribing

i have an issue with this awesome patch, in particular with the integration with ubercart attributes...can you look? i posted here http://drupal.org/node/933060 as i wasn't sure if this was coming from joachim's version of the module or from uc_signup...

You're basically asking for modifications from other modules' hook_user() implementations?

I guess another pane module that invokes hook_user() and provides whatever fields it finds could be doable.

Thing is, this patch has taken so long to get in (and still isn't!!!) that the project I wrote it for is long gone. It's going to need other people to keep pushing it forward too.

sorry, wrong issue referred to in #225, changed to http://drupal.org/node/933060. i too would love to see this put in to the module...

I strongly suggest you don't use this patch in combination with uc_signup -- the two try to do the same thing in different ways and will only cause chaos together.

If you want to be able to sign up multiple people, there is another patch to signup module.

@joachim: Can I just give you commit access to the DRUPAL-6--2 branch and you can basically do whatever you want? Please ping me for releases, but otherwise, commit this and any follow-ups. I really don't have the time/energy to review this, but it's probably great, and it sounds like people would love to be able to make more use of it. If you also want to work on the D6--1 bug queue (and keep it synced with D6--2) so we can get a 6.x-1.0 official out, too, that'd be great!

We can think about a D7 port/re-writes to signups as fieldable entities at #808310: Initial Drupal 7 port of signup module . Deal? ;)

Thanks!!!!!
-Derek

p.s. I granted the perms, please just be careful that you commit to DRUPAL-6--2, not D6--1 or HEAD, since we don't have per-branch ACLs (we hope to with Git). Thanks!

Finally... seems that Joachim's hard work will find the way into the module - great news!!

Indeed, my deep apologies for taking this long!

@dww cool, thanks!

Could you deal with making a DRUPAL-6--2 branch that isn't HEAD, as I assume you'll want that for D7 eventually? Looking at the CVS tree, it looks like a load of 6--1 stuff will need to be synced over too.

I created the DRUPAL-6--2 branch from the end of HEAD. I had actually kept HEAD in sync with DRUPAL-6--1 (with the exception of translations, and I'd rather move those to localize.drupal.org anyway). I confirmed the diff between the branches was just the CHANGELOG and translations. I sync'ed and updated CHANGELOG.txt in the DRUPAL-6--2 branch. http://drupal.org/node/346809 is now pointing to DRUPAL-6--2 and all yours. ;)

Please follow my existing commit message and CHANGELOG.txt conventions (including always using an issue nid for commits, and generally avoiding giant monster issues by breaking things up into smaller pieces). ;)

Welcome aboard, and thanks again!!
-Derek

> Please follow my existing commit message and CHANGELOG.txt conventions
> generally avoiding giant monster issues by breaking things up into smaller pieces

No problem -- I'm used to doing that on image module :)

The CVS instructions tab on the project page isn't showing me instructions as maintainer... is there a delay before that picks up?

I'll get this patch committed and then subsequent bugs and improvements can be new (shorter! ;) issues.

if this is submitted, can we make sure that it doesn't break uc_signup like in 225 or 226?

@SocialNicheGuru:

No, we can't. http://drupal.org/node/346809 clearly says: "This is incompatible with uc_signup". #222 and #228 clearly explain this branch isn't going to be compatible with uc_signup, but that's okay, b/c D6--2 provides its own UberCart integration. uc_signup doesn't work with this patch because you don't need it. At least that's how I understand reality. Joachim can clarify if needed, but from my perspective as the maintainer, we do *not* need to "make sure that it doesn't break uc_signup"...

Cheers,
-Derek

this couldn't have happened at a better time! thank God. i've got a project that will basically be made or broken by these improvements in signup, so i will be following closely and be testing thoroughly. i've been banging my head against a wall trying to get just the right combo of info gathering via signup, content profile, webform and ubercart, and i think this will do the trick in time. we're launching 11/1; no pressure though joachim! :) thanks for all your (and dww's) awesome work!

joachim,
will the patch you mention in #228 for multiple signups still work with these updates? i will test and see, but thought maybe you'd know already.

@dww: The good news is the patch of my copy applies to the 6--2 branch :)

Regarding the submodules signup_webform and signup_uc_attribute -- should these be committed here or created as separate projects?

Also, I've not been following uc_signup development at all, but could signup_uc_attribute become the 6--2 branch of that project?

@joachim: Crap. ;) Answering questions like "should signup_webform" be committed here or created as separate projects" would require me to understand what this patch/branch is doing. I haven't read this issue since around comment #90. Is there a good summary of what's going on here that you can point me to above? It'd probably be worth writing up some docs on this branch anyway, so if a good summary of all the parts doesn't yet exist, it'd be great for you to spend the time producing that... That'll help me strategize about questions like this, not to mention give a better picture to end users trying to take advantage of all this new code.

re: uc_signup vs. signup_uc_attribute -- if there's a good way to unify, please do! I'd rather not fork this effort. I'm really hoping that you and Ezra will work together closely, both on signup core itself, and the UC implications. Frankly, the three of us should probably get in #drupal-signup on IRC at some point (ideally soon) and sync up on all of these things.

Thanks!
-Derek

Heheh...

Okay here is the super-quick elevator pitch.

This patch makes the signup form on a node pluggable. The idea is the same as the Checkout Panes system on Ubercart.

When you create a signup node, you can enable any number of so-called Signup Panes for that particular node.

Hence there are different submodules that provide different panes:

- signup_basic_form -- a re-creation of the hardcoded name & telephone fields from the 6--1 branch
- signup_profile -- provides a pane for each profile category defined in Core Profile module
- signup_webform -- provides a pane for each webform node. This is what allows site admins to create custom fields for each signup. New funky stuff in webform 3 with the way webforms are connected to nodes will probably mean this changes completely... a good reason for making this a separate project that can have different branches.
- signup_uc_attribute -- if the signup node is also an Ubercart product, this provides a pane containing the attributes. If the pane is used, the usual UC form is suppressed and the product is added to the cart automatically when you sign up.

> re: uc_signup vs. signup_uc_attribute -- if there's a good way to unify, please do!

I don't know to what extent we could unify. The approaches are completely opposite -- here you enter details first and it adds to your cart automatically; with ezra's you add to your cart and then get taken to the form to enter details. Moving the signup form details to a multistep form would make a lot of things here easier though -- such as a signup pane for content profile, or signing up multiple attendees.

Thanks for the summary, that's very helpful.

How does the data get stored for all these panes? Is it still a single nasty serialized array in {signup_log}? Presumably not in the case of signup_webform, but what about the others?

How does this relate to signup_status and what I wrote at #330943-3: Drupal 6.x port of signup_status about solving this problem more generally?

Is there a data migration path for people that have customized this form via their theme?

Do all these sub modules really need to be separate modules? Can't they just be .inc files that are conditionally loaded? Generally, I'm not a fan of tons of separate small modules for cases like this. Just makes the admin/build/modules UI more crazy, and slows down your site. In fact, ctools plugins seems like a better model for this than separate modules. In fact, this sounds a *lot* like ctools content panes. I'd be fine with a dependency on ctools in D6--2 if it meant we weren't reinventing this wheel.

I'll let Ezra reply about UC. I haven't looked at uc_signup at all...

> How does the data get stored for all these panes? Is it still a single nasty serialized array in {signup_log}

Unless the pane module acts to save the data itself and remove it from the $signup object, yes. But obviously webform and profile plugins do their own thing.

> Is there a data migration path for people that have customized this form via their theme?

Hahahaha. No. How would that even work?

> Do all these sub modules really need to be separate modules? Can't they just be .inc files that are conditionally loaded?

Er... maybe? Thing is, a bunch of hooks still need to be invoked through the flow of a signup, so I'm not sure what would be gained.

> In fact, this sounds a *lot* like ctools content panes.

I'm not sure it is. This is a hook that lets modules provide a FormAPI array for their pane, and the result is then built up into the final form. Even if it were, certainly not something I have time to look into.

so is the new 2.x-dev version supposed to already have your patch from above? maybe i'm doing something wrong, but i am not seeing any of the signup pane options (profile categories, uc attributes, webforms) that i was seeing with the patched version 1...maybe you're just waiting to work out some of the questions above with dww? just curious...i can always just patch the old version again (and NOT use uc_signup per your previous recommendation).

> so is the new 2.x-dev version supposed to already have your patch from above?

Not yet. When I commit the patch, I'll be sure to post here (and close this issue! ;)

Great news. Thanks again joachim for all your hard work on this module!

i suppose it would make sense to wait to bring up the issue of anonymous users, storage of their data, etc. (a la #90) until the patch is committed to 2.x-dev. basically, it seems anonymous users can complete the process, but signup doesn't go back and associate the new account created for them with their signup, just still shows "Anonymous" signed up.

@joachim and whoever else is interested... I'm currently working on a project using your github version and have made a version of signup_webform that is working with v. 6.x-3 of webform so once you get your patch committed I should be able to provide a patch for that part.

Yeah, Webform 6.x-3.x support would be greatly welcome.

Subscribing. Any ETA on release?

I'm still pondering doing this with fewer modules as dww suggests.

We could the 'hooks on behalf on another module' pattern, and have this:

- profile.signup.inc -- contains hooks on behalf of profile.module
- signup.signup.inc -- contains the basic form

The precedent set in Views, which I suggest we follow, is that we handle things for core only. So support for webform and Ubercart would go in separate projects, which would each be an empty module file that's just a life support system for the meat of the code in webform.signup.inc.

So that only reduces the module count by two (and I expect most people will turn off the basic form module anyway... it's just in there to ensure backwards compatibility: if you want name and phone number fields you should really use profile).

Unless (again) we put all the non-core signup pane stuff in a bumper 'signup panes' project (in the same style as views_bonus).

As you can see, I'm still pondering the pros and cons. Opinions welcome.

seems like the point of starting a 2.x version was to add in the functionality from your patch as part of Signup core functionality. I vote not using a 'bumper'/separate project, use the .inc approach. i'm no coder, so i can't speak to the implications of doing it either way, but i would think improving on the core functioning of signup would be more useful than a separate, new 'signup panes' module. whichever way you decide, i am anxiously awaiting the implementation. thanks for your work so far!

By 'non-core' I mean signup panes that work with modules that are not part of Drupal core, so webform and UC.

Yeah, I like signup providing support for core (and itself).

I'm torn about webform -- that seems like such an obvious use-case for this functionality (at least in D6), I think we should probably just include that functionality directly in signup. It's sort of up to joachim, but so long as it's in its own .inc file, there's no real harm in providing it.

I would keep the UC integration in a separate project. However, I'd love it if there was just a single uc_signup -- if it needs 2 branches for now to support the 2 branches of signup core, that seems better than totally separate projects, especially since we're going to want to reunify in D7. This will be less confusing for everyone. So, I really hope joachim and ezra-g can work that out -- I'd love to hear from both of you before a new project is created.

Thanks,
-Derek

I can appreciate that restricting signup to core modules would be more manageable in the long run. On the other hand inc files aren't necessarily a bad thing either.

Should you decide to split it into core and others, I'd personally rather see separate projects for each of the non-cores rather than a single 'signup panes' project.

I'm having second thoughts about inc files.

If it's just a blind profile.signup.inc file, then signup module has to do a drupal_system_listing() on the whole set of enabled modules just to sniff out which modules might be supplying a foo.signup.inc file. I really don't think that's a gain compared to one or two extra modules in the system table.

What we would do is an approach where signup_profile.module just implements the signup pane info hook, and all subsequent hooks are in a profile.signup.inc which signup module knows to include. That would at least only load the signup code when it's needed.

I'm leaning towards putting webform in this project, especially as there's apparently already working code to support webform 3.

@joachim where can I get the most recent version of your code? seems that the code on github is quite old (July 2010).

Subscribing

I'm currently working on updating signup_webform available from github to use webform 3.x. Get in touch with me if you want to contribute.

@#247, @#258: you two should talk; don't duplicate each other's work.

I'm going to try to find time to commit this in the next few days, so you can either wait till then and then work off CVS or branch the repo on github now.

@macdee please, share your modified version of signup_webform .. I also have started working on this, sorry somehow I missed your comment, what's your status on this?

Attached you find my changes to signup_webform for webform 3.x in form of a patch against github version.. you can apply it from signup root.
It's still a work in progress.

@joachim I was going to wait until you've committed here and roll a patch against that if it's OK with you.

@fax8 I'll compare your patch to what I've done as soon as I get a chance and get back to you, hopefully tomorrow or the next day as I'm in the middle of something else right now.

I'm sure that between the two of us we should have this covered!

This is where I'm at:
My version is completed and works in my own limited testing. The caveat is that it's still on the testing server and hasn't gone live yet so there's been no real world feedback.

It only needs a little tidying up (whitespaces and weeding out my debug code etc.) to make it presentable before I can roll a patch suitable for public consumption.

One thing I did when writing mine was to keep joachim's webform 2 code intact. I check the schema version of webform to switch to 3 specific code when necessary, thus it should work with both webform 2 and 3.

I don't know if it's a good or bad thing to have code for both cases as it does make it a little extra bulky. I could easily refine it to be just 3 specific as I see you've done. Opinions welcome.

David

My patch is still incomplete, it's capable of submit and store simple data but there still quite some work to do.

Personally I decided to skip webform 2 support as webform 3 is now the recommended version.

I would suggest to publish your code here even if incomplete or still untested.. It doesn't have to be perfect code: there's lot of people interested in having this feature so we can help you finding/fixing bugs and make it better.

@fax8 I'll definitely be posting a patch for signup_webform against the code that joachim commits here as soon as that happens.

Can y'all move the discussion of signup2 + webform3 into a new issue? This one is big and confusing enough as it is. ;) Thanks!

I'm having the same problem as #212 - it's been really confusing for attendees to know what to do next so most people have phoned up.
Could this be moved to a new issue against 6.x-2?

Oof.

Committed the attached patch. This is all the stuff on github *except* the signup_uc_attribute module, as we need to figure out where and how that lives. You can obviously grab that off github in the meantime; the code there is the most recent there is.

@ the webform 3 guys: please could you file a new issue for your work?

@ anyone else with problems: please file new issues (and patches! ;)

Holy sh*t! Oof is right... Thanks again Joachim.

@joachim Please see http://drupal.org/node/945552 for webform 3 patch.

awesome. ;) +1 for getting the 6.x-2.x-dev on the project page for all to see and start testing. other than the anonymous users issue (see #90, i vote for option b, just for the record). so far i have the full github code working well with UC attributes and with multiple categories of core profile fields (no use for webform integration yet).

> other than the anonymous users issue (see #90, i vote for option b, just for the record)

Can someone start a new issue for that too please?

So, how exactly does this work at the current state? Lost the point somewhere between all the patches and stuff.
What do I need to do after I have signup and webform installed?
Anyone who can give a short how-to-guide?

I've summarized this at several point over the course of this issue... #240 is one.

#948860: Handling anonymous signups created for improved handling of anonymous users

Does it actually work to have several result-sets for the SAME webform used as signup form?
Let me explain:

• I have an Event-Content-Type
• I use it for signups
• For each Node of this Content-Type I need to use one "Basic"-form (with basic informations like name, etc.) combined with one custom form, I know this works right now BUT
• I need the results of BOTH in one webform-result set, because I want to use the fine exporting functionality of webform (or is there a good way to export the actual signup informations as csv by click?)
• if I use a custom form for multiple nodes, will the results in webform be seperated from each other? So if someone signed up for node/1 with custom-form A and someone signed up for node/2 that is also using custom-form A, will both submits run into the same webform results, so when exporting them I will have both signups mixed together?
• Can I get fileuploads running with this?

Hope that someone can help me out with this.

IIRC it stores the webform stuff as if the user had submitted the webform, which means that the same form used on multiple signups will cause problems. But this is with the webform 2 code -- I suggest you go over to #945552: webform 6.x-3 support for signup_webform and see what possibilities webform 3 offers us.

In general: could people please file *new* issues now this one is fixed?

Is that patch applied on the signup-6.x-1.x-dev release or will it be that soon?

@Scyther: No. This is a major re-write of the signup module that lives in the 6.x-2.x-dev series, as you can see from the version field for this issue.

@all: I'd like to echo joachim's point:

In general: could people please file *new* issues now this one is fixed?

To that end, this issue is now closed for comments. If you want to talk about this feature, please look at the signup 6.x-2.x-dev issue queue and if your issue doesn't already exist, please add a new one.