A few people have asked whether Product Attributes can act as webform components so that they appear in the webform results and can be rearranged on the webform.

I wanted to do this myself and so I've put together a patch that creates a new webform component called a Product Attribute which allows you to select a Product Attribute to display on the webform. Its probably a bit rough at the moment and can be improved upon, but I thought it was worth posting so that I could get feedback, hearing whether people think it is a good idea or not & whether it can be improved/redesigned etc.. Note that the patch stops the default behaviour of automatically displaying all the Product Attributes at the end of the webform.

CommentFileSizeAuthor
#5 uc_event_registration-1.5_v7.patch30.3 KBwillowmedia
#1 uc_event_registration-1.5_v6.patch29.15 KBwillowmedia
uc_event_registration-1.5.patch22.23 KBwillowmedia
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

willowmedia’s picture

willowmedia CreditAttribution: willowmedia commented
FileSize
uc_event_registration-1.5_v6.patch29.15 KB

I've rolled another patch which includes the following changes:
- fixed bug when downloading data from radio buttons or attributes with no data
- added support for textfield attributes
- to preserve the pre-patch behaviour, included an upgrade script that adds product attributes to existing paidevent webforms
- creating new paidevent nodes will have product attributes added if they are found on the product class (unless we are cloning webforms)

AndyF’s picture

AndyF CreditAttribution: AndyF commented
Version: 6.x-1.5 » 6.x-1.x-dev
Status: Active » Needs work

Thanks so much for this, I've just given it a bit of a test and it worked great. I've commited it to 6.x-1.x. I think there are a few minor issues:

  1. I scanned the code and didn't see anything ensuring that required attributes don't get deleted or marked as non-mandatory as webform components. I think it makes sense to allow non-mandatory attributes to be deleted and added, but required ones to be undeletable: what do you think?
  2. It doesn't seem to show an attribute's help text.
  3. When performing a database update, the attribute components aren't in their component order.
  4. It might be an idea to add a message on the attribute ordering screens that it won't affect existing paidevents.
  5. I noticed that in uc_event_registration.module:uc_event_registration_client_submit() at the end you kept in the old attribute handling code (ie using $form_state['uc_event_attributes']): is that for users in the middle of filling out a form when the module's updated? I wonder if that's necessary?

Thanks again.

willowmedia’s picture

willowmedia CreditAttribution: willowmedia commented

Sorry for not responding - I've only just noticed that you had commented on this issue! I'll try and find some time to work through your suggestions.. thanks.

AndyF’s picture

AndyF CreditAttribution: AndyF commented

No worries, anything you can get done would be great: the list is really there as a record, rather than a task list for yourself specifically! I'd be interested in hearing your thoughts on points 1 and 5 though...

Btw, in case you don't know you can set automatic emails for issues you follow (or all) on a particular project from Profile -> Notifications.

Thanks again

willowmedia’s picture

willowmedia CreditAttribution: willowmedia commented
FileSize
uc_event_registration-1.5_v7.patch30.3 KB

1. I scanned the code and didn't see anything ensuring that required attributes don't get deleted or marked as non-mandatory as webform components. I think it makes sense to allow non-mandatory attributes to be deleted and added, but required ones to be undeletable: what do you think?

Well I guess the current setup gives the site builder more flexibility/control over the product presentation but I think you are probably right we should be honouring the product attribute settings - although once we start going down that route I'm thinking we would have to write extra code to keep the two "models" in-sync. For example, when a product attribute is changed from non-mandatory to mandatory and it isn't already on the webform. Or for when a new attribute is added to a product and it is mandatory..

2. It doesn't seem to show an attribute's help text.

I've created a new patch so that the webform component description fields are pre-populated from the attribute's help text when

  • a) a webform component is added to an existing paidevent during the database upgrade
  • b) creating a new paidevent node and the webform components are pulled in from the Product Class

3. When performing a database update, the attribute components aren't in their component order.

I'm not sure I entirely understand this one, I think my attribute components came out in the same order as the Product Attributes

4. It might be an idea to add a message on the attribute ordering screens that it won't affect existing paidevents.

I've created a new patch to display messages about ordering the attributes and changing their labels

5. I noticed that in uc_event_registration.module:uc_event_registration_client_submit() at the end you kept in the old attribute handling code (ie using $form_state['uc_event_attributes']): is that for users in the middle of filling out a form when the module's updated? I wonder if that's necessary?

Yes, you are right, the patch I produced did leave some redundant code behind - I think I left it there to make the patch smaller & easier to understand. There is probably also redundant code in uc_event_registration.module:uc_event_registration_form_alter()
I'll see if I can get time to clear out the old code.

The new patch I've just added was made against the 1.5 version - is that alright, or should I start rolling them against the 1.x-dev version now ?

willowmedia’s picture

willowmedia CreditAttribution: willowmedia commented
Status: Needs work » Needs review
AndyF’s picture

AndyF CreditAttribution: AndyF commented

Thanks again willowmedia.

  1. Excellent point. I think in light of that it probably doesn't make sense to try to ensure anything. Maybe we could have a message that warns when a particular product's mandatory attributes aren't included and leave it at that.
  2. Thanks
  3. Probably just me then! I'll see if I can recreate it when I get a chance.
  4. Thanks

Regarding patches, ideally they'd be against dev. Thanks for your work on this: I'm not going to be able to look at the patch until early next month, at which point I'll let you know.

AndyF’s picture

AndyF CreditAttribution: AndyF commented
Status: Needs review » Active

Regarding point 3, it turns out that I had some attributes that were equally weighted, in which case Ubercart uses their name for ordering. I've committed your patch and modified the update query to sort by attribute names after weight.

On further reflection I'm still a bit uncertain about point 1. A part of me feels that the most sensible way to handle things would be for every paidevent to necessarily have one and only one uc_attribute component for every attribute. Then the attribute can be configured to be hidden (allowing you to provide a default value). We can prevent people from adding/deleting uc_attribute components, but it still means we'll have to ensure the form remains up-to-date as product attributes change. The way that springs to mind is to check on node load if there are any invalid or missing attributes and dealing with them. A part of me balks at creating automatic behaviour like this that can be destructive however.

Any thoughts?

AndyF’s picture

AndyF CreditAttribution: AndyF commented
Status: Active » Fixed

Right this is done:

  • you can only create one component for each attribute
  • labels and descriptions are not set at the component level, but via the attribute
  • I've slightly changed the markup that will be produced to work with webform title display options, and to be more consistent

Thanks so much for your input.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.