signup

joachim's picture

I've given signup module a quick spin.
My thoughts so far -- please add your own :)

  • allows anon signup. Yay! But requires email. Not so good, but can perhaps be worked on with the visitor API?
  • hardcoded name + phone field. Not everyone wants phone, people need other fields.
  • lots of other fields -- conferences need food preferences, partial day bookings, etc, etc. Have suggested using webform here
  • form data is stored serialized -- no good for Views integration.
  • no way to sign up many people at once, but there's an issue open for this.
  • uses a custom emailing system -- I think simplenews integration would be more powerful for mailing campaigns.

Very briefly looked at UC signup module-- in haste on the train, some brief thoughts:
- why depend on date?
- why depend on profile?
- don't use machine name in perms
- having to remove a perm to prevent free signup is going to be a MAJOR gotcha for users. (but think about use cases for free signups being required?)
- temp signups in own table? move this up to signup for cleaner data storage?

Also, we shouldn't use singup because I am incapable of typing the word 'sign' ;)

Login to post comments

Yeah, tried it out over last

goose2000 - Thu, 2009-08-27 12:49

Yeah, tried it out over last week too. You mention:

hardcoded name + phone field. Not everyone wants phone, people need other fields.
lots of other fields -- conferences need food preferences, partial day bookings, etc, etc. Have suggested using webform here

That's what was a big deal breaker to me. Every event is different, thus you need and ability to create custom
registration forms (I still love webform for this reason. In many ways, it's a better candidate to start from I think). Looking at this module,
I guess the developer thinks you will build a new content-type every time you need to design a new type of registration need?
And then assign signup to it - this is what I get from the signup module.


The fields are not hard-coded, but they suck

dww - Wed, 2009-09-09 16:18

The fields on signup forms are not hard-coded, they just suck. This was Drupal 4.6 technology that I inherited from the original author that I've never had a chance to completely re-write. Thankfully, by taking my time, it looks like D7 core fields might be the perfect solution to this. ;)

Anyway, you can customize the fields on the signup form per site, even per-node, if you bother to read the INSTALL.txt file that ships with the module.

For related work, check out:

http://drupal.org/node/29568
http://drupal.org/project/signup_status
http://drupal.org/node/330943#comment-1177526


4.6? Ouch! You're right, D7

joachim's picture
joachim - Thu, 2009-09-10 09:26

4.6? Ouch!

You're right, D7 will make this very easy.
In the meantime, I think FormBuilder is the way to go.


Form builder still has a data storage problem

dww - Mon, 2009-09-21 16:07

Yes, I thought form builder would be great for this. However, there's still the problem of where to store the values. You really really must read http://drupal.org/node/330943#comment-1177526 for detailed discussion of exactly this.