Looking at the product, my attributes are in order correctly as specified in /admin/store/attributes/overview. However, once the product has been added to the cart, the attributes appear in no order that I can determine—certainly not the order in which they were set in admin. The Cart and Cart Checkout pages should respect "list position" for the sequence in which product attributes are listed.
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | 603738_cart_attribute_order.patch | 1.74 KB | Island Usurper |
| #7 | ubercart-603738-6.patch | 1000 bytes | univate |
| #1 | ubercart-603738.patch | 534 bytes | univate |
Comments
Comment #1
univate commentedThis is actually a really silly bug, the attributes are being sorted into the correct order, but never actually being returned.
One line fix.
Comment #2
smscotten commentedThank you univate. Unfortunately, your patch didn't do it for me.
$combination only consists of the attributes where the value is numeric and the display type is radio button or select box. Your patch eliminates 80% of the attributes in the particular product I'm testing with. I tried adding a value for $combination[$aid] each time (by adding
after the test for is_numeric($value). That brought all the values back but they were still out of order.
I'll continue to look at it, but you are obviously more familiar with this code than I am so I'd appreciate your eyes and ideas on it.
Comment #3
mikeurturn commentedFinally, somebody else that has this issue. I thought I botched something in the module itself playing around. I am going to attempt this patch and will report my findings.
No luck. The above poster is correct. Will keep trying as well.
Comment #4
mikeurturn commentedThis is frustrating. This issue has been around since 2008 and really needs to be addressed. Is anyone out there that is up to taking this on? It may end up being a simple fix, but I cannot see it.
Comment #5
smscotten commentedMore information; I still have no luck finding out where this is going wrong.
dsm() reports that the $options array (containing the result of _uc_cart_product_get_options($item) in uc_attribute_cart_item()) is in the correct order. This only tells us one place where the problem isn't.
Comment #6
smscotten commentedmikeuturn: I feel your frustration. I've been joking for a couple years now that Drupal's slogan should be: "Makes impossible stuff easy and easy stuff impossible." My client has gone from looking at me as a miracle worker to wondering if I'm not a complete moron because I can't even correct the order of a list of attributes.
Changing to "active" because "needs review" makes it look like there's a fix and I'd rather that the people who are looking to fix things not skip over this.
Comment #7
univate commentedThe status for an issue that has a solution but doesn't work is usually "needs work" not "active".
The product description is generated through the drupal_render function, the following patch adds a weight to the form items, so that drupal_render will observer the order they are in.
Comment #8
smscotten commentedunivate, that has done the trick. I don't see any side effects. I like it! Thank you.
Comment #9
fenstratNice simple solution that handles default ordering (while still allowing overrides through hook_product_description_alter()).
The code to document hook_product_description() in hooks.php will also have to be updated as it's simply a copy of uc_attribute_product_description().
Comment #10
yosemite commentedd6.14
u 2.2
thank you this seems to work
why is not fixed in ubercart???
Comment #11
yosemite commentedstill shows in random unsorted order when viewing
Home › Store administration › Orders
Comment #12
Island Usurper commentedHere's a patch to change the docs.php function as well. Changing the order of attributes at the product level still won't affect products that are already in the cart, but I think it's better than it was.
Thanks, and committed.
Comment #14
jeffschulerThis issue still exists in 6.x-2.2, (released before IslandUsurper's commit in #12.)
The patch in #12 applies cleanly to 6.x-2.2 and does what it's supposed to.
Comment #15
mr.andrey commentedsubscribing
Comment #16
Tweetinat commentedCan I use this patch in 2.3? Am a complete novice and not sure where I should be putting this code. Thanks, Natalie
Comment #17
alfthecat commentedsubscribing
Comment #18
fenstratThere's nothing to subscribe to here. This patch was committed 24th Nov 2009, it's part of Ubercart 2.3 and above.
Comment #19
crystaldawn commentedIncorrect. This issue still exists in 2.4. In 2.4 it lists them in order BACKWARDS.
Comment #20
tr commented@crystaldawn: I cannot reproduce this. I created a new product with new attributes and added that product to my cart. The attributes are shown in alphabetical order on the product view page, the cart page, and the checkout page. I removed that product from my cart. I then modified the order of the attributes at node/%/edit/attributes and again added the product to my cart (after saving the attribute changes). The product view page, the cart page, and the checkout page all show the attributes in the new order.
If you still think there is a bug please open a new issue, describe what you expect to happen and what actually happens, and document all the steps that need to be taken to reproduce the issue.
Comment #21
crystaldawn commentedAdded some attributes to a node.
Added the resulting product to a cart.
Put the following debug code on line 1838 and 1839 in uc_product.module:
And this was the result. Notice how the attributes are correct in the array, but after they are run through drupal_render, they come back as OUT of order?! Erm. Ok, so the bug seems to be fixed in the array, but now drupal render is causing an issue. I am in the process of debugging drupal_render now to find out why it's sending back the array out of order, but something tells me that this problem is affecting others whether they realize it or not. The order in which they are returned is not in the order of the array keys (which is NOT determined by alphabetical which you suggested, it's determined by WEIGHT which would be the correct method. Alphabetical would be completely incorrect anyways even if it did do it that way because they are suppose to be sorted by weight as not all instances would want them alphabetical as shown here by this example use case) as they are suppose to be.
Comment #22
tr commentedPlease open a NEW issue like I asked, and provide the information I asked for.
Comment #23
crystaldawn commentedremoved
Comment #24
crystaldawn commentederm, ok. was in process of putting more debug stuff when u wrote that :P
Comment #25
tr commentedBack to "Closed (fixed)"