I have found quite a few approaches to handling a custom add to cart form, from views VBO to custom field handlers, and I'm not seeing any consistency with the core add to cart behavior.

I see the potential for an API alteration here that would make it easier to customize the add to cart form on product displays, so this may be more of a code feature request, but for now I guess I'm just looking for some pointers.

I would like to alter the "add to cart" form that is found on the product display in a way that does not break the behaviors this form provides to other elements on the page.

This screen illustrates some of the most important relationships of the behaviors I'd like to preserve:
Illustration of the relationship between attribute selection and field view changes

I've labeled areas of shaded color. The pink areas I labeled "Listeners" and the blue area is labeled "Trigger." Changes in the "Trigger" area made by the user trigger updates to the "Listeners" on this page. This is awesome, I love how commerce does this out of the box.

I've read up on how to configure the form elements that appear in the "Trigger" area: http://www.drupalcommerce.org/user-guide/cart but this doesn't provide the kind of flexibility I'm looking for. I found several alternatives:

  1. Product attributes module
  2. Commerce option module
  3. Add to cart extras
  4. Commerce views display
  5. Rules + VBO

Each of these alternatives takes a different approach in presenting a brand new form in a brand new way that doesn't really mesh with the core cart form and behaviors. If I implement any of these, I lose that awesome Product-display-updating Trigger/Listener relationship and all of the modules that relate to it (like the Cloud Zoom feature in Commerce Kickstart), or I lose the SKU/attribute relationship that is part of Commerce core.

All of these solutions are basically hacks, because the add to cart code is so crazy complicated (commerce_cart_add_to_cart_form() is 500 lines of code!).

I think that an API in this form would be hugely awesome... The API would allow you to write code to interact with the "Listeners" on the page via some kind of "Trigger" form object that could update the "Selected Commerce Product," thus firing updates in the "Listeners"

This way, developers could write code to manage the "Trigger" form without breaking the core display behaviors, and while maintaining the concept that each combination of attributes (and each display of such a combination) is a unique Commerce Product entity.

Is there something like this already in place that I'm missing?

CommentFileSizeAuthor
#2 commerce_add_to_cart_form-desired.png150.33 KBtmsimont
commerce_add_to_cart_form.png172.68 KBtmsimont

Comments

rszrama’s picture

rszrama commented
Status: Active » Postponed (maintainer needs more info)

Hmm, I'm still not really sure what you're proposing. Also, if I could tweak your wording a little bit, it's not that those shaded areas are listeners in the respect that they "listen" for changes in the Add to Cart attribute widgets and update themselves accordingly. Rather they're more like receptacles, with the Add to Cart form pushing new content to them whenever it's updated. Put another way: they aren't responding to an event, they are being updated as part of an event.

But like I said, I'm not really sure what it is you want to do. It could be the form already supports it. Can you elaborate?

Have you already looked into hook_commerce_cart_attributes_refresh_alter() (documented in commerce_cart.api.php).

tmsimont’s picture

tmsimont commented
Status: Postponed (maintainer needs more info) » Active
StatusFileSize
new commerce_add_to_cart_form-desired.png150.33 KB

Thanks.

Basically what I want to do is create my own UI for managing the product that is represented in the "receptacles." This UI needs to have multiple "triggers" that each pertain to different combinations of size and color attributes. I want all of the sizes to be listed out, and then have multiple color attribute triggers next to each size.

A client wants me to pretty much reproduce this functionality:
http://www.horchow.com/p/Bernhardt-Eastman-Headboard-Headboards/cprod942...

Only they also want the image to update when a color selection is made.

Here's a screenshot with similar highlights to the commerce screen above:
screenshot of desired functionality showing multiple triggers

In this case, the "triggers" are attribute selections that pertain to another attribute... That is, the "color" is being displayed next to a particular "size." Core commerce only allows selections to be made 1-by-1 and then the view is refreshed based on each selection. I just want to create my own "trigger" UI that mimics the horchow website, and have it update the entity that is represented by the product display field "receptacles."

hook_commerce_cart_attributes_refresh_alter() only works with the given add to cart form UI -- it provides a nice level of interaction with the existing UI, but if I wanted to create my own version of an add-to-cart form, I'd have to do a lot of copy/paste reproduction of the code in commerce_cart_add_to_cart_form() in order to push events out to the receptacles.

I am primarily searching for a way to reproduce the functionality of that horchow site (with minimal copy/paste code), but I'm also pointing out a need here for easier development of custom add-to-cart UI's...

tmsimont’s picture

tmsimont commented

I've discovered a few key ingredients to what I need:
Setting this AJAX callback:

$form['my_element'] = array(
  '#ajax' => array(
    'callback' => 'commerce_cart_add_to_cart_form_attributes_refresh',
  ),
);

and setting this form_state value:

$form_state['default_product'] = (CommerceProduct $product);

Still... creating the form the right way seems to require an awful lot of code... Maybe I'll make a module, or possibly post back a feature request... I think I might be well on the way to solving the original problem tho.

tmsimont’s picture

tmsimont commented
Issue summary: View changes

added image code

bojanz’s picture

bojanz commented
Status: Active » Closed (outdated)

We made the form much easier to customize in 8.x-2.x.
7.x-1.x was too late to fix even back in 2013, since it would have required a rewrite of the code in question.

bojanz’s picture

bojanz commented
Status: Closed (outdated) » Fixed

Better status.

Status: Fixed » Closed (fixed)

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