Commerce Signup (D7) - Development approach

- Multistep form attendee information form
D6: Custom checkout pane does a drupal_goto() to redirect users to the attendee information form:
D7: Redirect folks to the form using hook_commerce_checkout_router()

In regards to this, would it not be more "Commerce"-ish to use Commerce checkout page/pane hooks? This way you don't manually redirect pages, instead you're letting the checkout routers do that work. Not only that, but you're able to configure the order of the pages/panes using the Commerce UI.

Then in each step of the checkout process, the values of the panes are stored and passed to functions in the $pane_values array.

Page/pane hook info: http://www.drupalcommerce.org/specification/info-hooks/checkout

subbing

More comments:
Currently you can only enable/disable signups on nodes and not products. As it stands you can just enable signups for Product Displays, and have people sign up for that display. The issue comes up that when you're checking the order line items to see if it contains an item that is signup enabled (in order to decide whether to skip or require the attendee info pane), you don't know the product display it comes from directly, you just have the line item data (in this case the product). So there is no way to easily determine if a product is signup enabled or not.

Possible Solution:
Alter the product entity to include a signup status just like what is currently available for nodes.
- Pros: allows signups to be recognized as a particular product (even if the product display has multiple variants of the product, you know exactly which product has signups)
- Cons: signups tied to particular products outside of product displays makes it more programmatically intense when trying to view overall signups for a product display; having to get all products associated with that display and then all signups for each of those products

subscribe

I'll have to do some digging, but I don't think that's a bad idea to just switch to entity reference to start. This way it would at least get a version of Signup that works with Commerce off the bat without having to modify anything crazily. As it stands now, Signup really only works with Ubercart as the products are distinct nodes, whereas with Commerce you have entities that aren't nodes for products.

Switching to entities later on, I feel (obviously I'm somewhat biased by my own needs with work) that Signups as entities is the way to go, as you allow any future entity to be signup enabled. So if someone creates their own module with their own entity(s), Signup would work immediately with that new entity without having to write a lick of custom code to integrate with it.

Also modifying entities on the fly is quite easy with hook_entity_info_alter. I actually started off that way with my project thinking I could just tell the commerce_product entity that it was signup enabled. You could easily store the entity bundle and id of it in the schema, the only issue is then digging a bit deeper into the entity_info to see the schema table for that particular entity (if necessary).

The issue I foresee is tying signups to entities and the way Commerce does it's product entities. How do you view signups for a particular product as an admin? You wouldn't really be able to have a tab on the node page anymore because there is no more node, only the Product Display is a node. So you'd either have to tie into the product display to see if any products associated to it are signup enabled and then show those, or show the signups on the administrative side for the product admin page (admin/commerce/products) as a new Operation link, or as a new column in that overview table.

That's my personal opinion though, I just know either way I need to have signup entities for my project to work the way we want it to. I'd love to see it be a part of a high profile module just so it can be used to its full extent, but that's not my call :)

If you want any collab from my part just yell, I'm typically in IRC quite often.

subscribe

Hi
I think consideration needs to be given to doing this with custom line item types.
The signup data can just be stored in fields associated with the add to cart form.
There is no reason why the add to cart form can't be a multi-step arrangement either.
See www.commerceguys.com/resources/articles/237

We've got a project coming up on D7 and we'd be keen to put effort in to do it with Commerce rather than uc_signup.
Any chance we could get access to the git repo?

If signups were true first class entities (and hence fieldable) then we'd could create a signup reference field type which we could add to the line item type entity. I think that would be a fairly solid approach and truly customisable.

Lee