There are some serieus issues with the "Order has a product with a particular attribute option" in the shipping quotes rules.
For some reason these rules awalys return "FALSE" even when the should return "TRUE". I have been trying to backtrace the problem and it might have something to do with
elseif (isset($attributes[$attribute->name][$oid])) {
return TRUE;
}
on line 51 in uc_attribute.rules.inc.
The else structure looks for attribute->name which is in lowercase while the $attributes array seems to have that value with the first letter in uppercase. Therefore the is statement is never met.
In my case $attribute->name equals "print size" while the $attributes array is as following:
array(1) {
["Print size"]=>
array(1) {
[9]=>
string(22) "Fine Art print 30x45cm"
}
}
Hope this makes sense?
Comments
Comment #1
longwaveCan you give an example print_r() or other debug dump of $attributes and $attribute?
Comment #2
longwaveHm, maybe we need to test $attribute->label and not $attribute->name?
Note also that this was recently fixed in #721412: "Condition: Order has a product with a particular attribute option" is broken, with at least two positive reports from users in that issue. We should probably have tests for this..
Comment #3
fuse CreditAttribution: fuse commentedHave already changed the label name in lowercase, but that didnt't help. Changing it to "none" either.
I fixed it temporarily by adding a ucfirst, but that is of course not the way to solve it. Bumped into another issue too: when combining mutiple conditions with "OR' to check for specific attributes it seems to return "false" again.
Comment #4
longwaveSo in this case did you override the attribute name and/or label at the product level? I don't see where the capitalized P comes from otherwise.
Comment #5
longwaveComment #6
fuse CreditAttribution: fuse commentedChanged the label at product attribute level, but that doesn't change anything. I have tried "print size" lowercase or even
<none>
, but the attributes array keeps using "Print size" capitalized like in the array dump in my previous post.Comment #7
fuse CreditAttribution: fuse commentedThe bug has to do something with
$attributes = $product->data['attributes'];
The value of
$product->data['attributes']
says "Print size" nomatter what I use as labels or name for the attributes.Comment #8
longwave$product->data['attributes'] is fixed at checkout time, keyed on the label of the attribute. This unfortunate design decision means that we no longer have the attribute ID or option ID available to test using Rules, so this only works if the product and base attribute are the same, and are not changed later.
I am not sure if or how we can fix this without changing the underlying data structures, and we have to be careful to avoid breaking existing code that relies on the existing structure.
Comment #9
Leo Pitt CreditAttribution: Leo Pitt commentedI am not sure if this is a duplication of what longwave has stated at #8, I don't think so. I'll add it for others in future. I am using ubercart 6.x-2.11.
The attribute conditional action code compares the name of the attribute from the database with the product order label. The product labels can be over-ridden and result in a mismatch.
So if you're having trouble with this ca, check that the labels of attributes on the product are the same as the names (names, not labels) of the attributes in your store settings.
Comment #10
longwaveNothing we can do about this without restructuring the way attributes are stored, which is not possible without breaking backward compatibility in a future version.
Comment #10.0
longwaveadded extra info
Comment #11
david_garcia CreditAttribution: david_garcia commentedI think this will simply "not fix". To much work + will require backwards incompatible changes.
Alternate solution here:
#2121187: Attribute detail lost when creating uc_order_product