Online Event Registration with Multiple Registrants

[John Thompson]

I have a client that has an event coming up where we want to sell individual tickets and sell tickets for a table of 8. When a table is purchased, we want to collect the contact info for the people that will be at the table. The quantity they would buy is 1 table, for example. The default workflow for the online registration is to have them indicate the quantity, check the ticket type (individual or table), enter payment info and submit the form. If the quantity is > 1 we collect the contact info for the additional people. In this case, the quantity would be one table but I still want to collect up to 8 names.

First, is there an add-on or module that does something like this or has anyone developed such an extension?

If not, how would you suggest going about this?

One idea (but I don't know how to do it) is to detect the selection of the table item and force the workflow down the multiple attendee path. Another possibility would be to collect the additional names after the payment process has completed.

What do you think?

[totten]

I don't know of an existing tool/extension quite like that -- although others have deeper experience on this kind of question. Generally, it feels like you might use price-sets or custom-fields as a building block.

When designing customizations for registration/contribution, here are a few good/bad techniques:

 1. (Good) Use Civi config options (e.g. price-sets/custom-fields) to get as many of the fields on the screen as possible/necessary, and then inject some Javascript to hide/display fields.

 2. (Good) Show a hyperlink or redirect after the payment is processed -- and link to a separate/standalone page where the registrant enters the extra ~7 people (possibly using profiles or webforms -- possibly using custom code and API calls). This spreads out the questions a bit (which could be good or bad UX -- that's subjective), but it also makes it possible for the participant to return later and add/edit/change people at their leisure (which seems like good functionality).

 3. (Bad) Dig into the PHP controller/state-machine used by the main registration/contribution form. This is generally the most difficult because much of the is undocumented / hard-to-understand.