multiattribute selection not working with taxonomy reference field

I'm not sure how taxonomy comes into play here. Are you saying you're trying to use a term reference field as a selectable "product attribute" field? i.e. on the add to cart form, the customer would have to select a taxonomy term?

Technically, this shouldn't be possible, but at the very least, it's documented that attribute fields should be one of the "List" type fields. I suppose it might theoretically work with taxonomy terms so long as the vocabulary isn't free tagging enabled...

But really I guess I just don't understand your original post.

spuky, i'm facing exactly the same error, it looks not yet possible to display lists of terms reference on a product display page. It looks like the Add to cart form does not allow to group taxonomy terms ( or node references) into a drop-down selection on the product display page. Did you find a way to go through this error by looking into the code?

Sorry for my bad english ;)

When in my product-type i use a "Term reference", "Select list" .
with
"Required field" selected and "number of values" -> 1 .
i get a : Recoverable fatal error: Object of class stdClass could not be converted to string in drupal_map_assoc() (line 2611 of /var/www/pb_cosmetics/includes/common.inc)..

With "Required field" not selected i don't get the error message.

I use the Select list to assign a product-type to a group of product.

Maybe this helps.

That's right... i don't get the error message either... i'll use it this way.
Merci latulipe :)

I was getting the same error, and disabled "required field" on taxonomy does clear this error message.

I have received the same error when I plan to establish my E-commerce.
Anyone who wants to create a product display for multiple products,they will encounter the error.

This has been confirmed on a fresh install of Drupal locally using dev versions of all the dependent modules.

If you disable the "required" option in the term reference field of the product type, you will no longer receive the error.

Thank you for your reply.But the problem here is "multiattribute selection is not working with taxonomy reference field", so if I disable the "required" option ,"multiattribute selection" is still not working.

Please reference http://drupalcommerce.org/faq/product-attributes for setting up additional attributes to your cart.

Developers, it would be ideal to have "term reference" work in addition with field "list".

As stated above, with Taxonomy you are able to add additional fields to your terms in each vocabulary for endless possibilities...well maybe not endless but yu get the picture.

Over-reliance on the EntityWrapper is the issue again here.

Hopefully, it is easy to fix here, but it hides other things. For example: we do not supporting translation there, and all those fields have to be in LANGUAGE_NONE (which is the default language of the EntityWrapper).

+1

Have also just encountered this issue when trying to set a Term reference field to mandatory and then using it on a product display node that had multiple products associated to it.

Correct patch, that is.

Hi Damien,

Many thanks for the patch in #13 - it certainly fixed the error for me and I was able to set the Term reference back to being a required field and the display node no longer errors when accessed.

It also had a secondary effect which, to be honest made things look a bit better from a users perspective. Let me explain what I was trying to achieve...

One of our shops currently sells Print and eBook versions of publications. I initially tried to create a Product type for each and then combine both in one Display node type. The problem there was that when I referenced one of each product type, the display node would only display the fields relevant to the first referenced product type...therefore, if my eBook had an extra piece of information I wanted to display with a field unique to that product type, it would be ignored if the print version was referenced first.

My solution to this was to have a generic 'Published product' product type and still have the one display node content type. The choice between eBook and Print is now taken care with by terms within a Taxonomy Vocab of 'Publication type'. Now that they use the same product type I can add any product specific fields that could be used for both print and/or ebook and if the data is not set then it simply will not show when that product is selected.

Using taxonomy has also helped when it comes to VAT as one has VAT applied, the other doesn't. It should also help for many other Rules scenarios.

The side effect (if I can call it that) however is that with the term reference being non-mandatory the product selection dropdown uses/displays the product titles (I'd used the same as the title in the display node but with the addition of ' - Print' and ' - eBook'), see option1.gif - With the term reference set to mandatory the product selection then uses the terms in the product selection dropdown (a lot nicer looking some would say), see option2.gif.

I assume this is expected behaviour due to the fact that this field is mandatory and therefore the selector of choice so to speak? Also, am I missing an obvious place where I can set this to display inline and add a : or even change it to radio buttons?

Thanks again :)

AFAICT, this is the same issue as one I attempted to bring up a while back with http://drupal.org/node/1147168 ("Using Taxonomy as Product Attributes"), so I'm glad to see this revisited. I, too, feel it's quite natural do use taxonomy for attributes. E.g., have a vocabulary of common "colors", allowing you to select from this when assigning attributes. By using taxonomy, I guess it could even be possible to obtain a list of all "red" products on a site, regardless of their product type (hats, t-shirts, etc). While somewhat contrived in this example, I'm sure there would be many use cases that would open up.

What's the rationale behind not allowing taxonomy terms to be used as attributes? Or is this just a "we haven't gotten around to that yet" case, which would be fully understandable?

-JM

TheWizz - The patch in #13 actually made my terms behave as attributes. I'm not sure if this works with more than one than vocab per display node but for me the selection between the terms 'Print' and 'eBook' worked fine to select the appropriate product related to the display node.

So in theory, there's nothing stopping you using this to assign colours or sizes for clothing etc

Yeah, I believe this is working now. The idea behind not allowing Taxonomy term reference fields to function as attributes owed to a sort of "magic configuration" I depended too heavily upon to make things like this work. The Add to Cart form in its 1.0 state has been treating any product type field that is required, single value, and contains a definite set of options as an attribute field on the form. This includes even fields that should be required on the product form but didn't need to appear on the Add to Cart form (see #1038320: Replace the "magic configuration" of attribute fields with explicit settings).

So, the magic configuration was bad to begin with, but even worse... I can't remember my initial justification for the requirement of a definite set of options. The only reason I can think I settled there to begin with was that I would take the "Allowed values" of a list field and array_intersect() that against the values actually present on valid referenced products. This is great for preserving the order of options in the attribute select list on the Add to Cart form as it exists on the backend in the field's widget. However, I don't believe it's really necessary - if there is no "Allowed values" list, I can still just populate the attribute select lists with values as they appear on products. This means something like a taxonomy term reference attribute should be supported.

Damien's patch above fixes this, so I'm going to submit and consider this specific issue closed. However, I'm following up with some other attribute related issues today, including that one I linked above, to ensure this is working as (and better) than expected.

In case anyone is wondering why Damien's patch fixes things, the error you're all seeing is as he mentioned related to the Entity Metadata Wrapper. For reference fields like the taxonomy term reference, the wrapper will load the actual referenced term and return that when you use the value() method. This is great when you're trying to drill deep into an order object to, for example, compare field data of product referenced by line items on the order. But when we just want a simple comparison / select list, we really just want the raw value - the term ID - not the whole term object. This patch is required for any sort of reference field to function as an attribute field.

@Axel, re: #14, if you're referencing products of two different types, the reason only fields from the first referenced product are showing is because we wrap product fields in a special container when the Product Reference module renders them into the node. This container can then be targeted for replacement when the selected product changes. However, if a newly selected product is of a different type with different field names, there won't be an existing container on the page to drop that product's data into. This is a separate issue really, that may or may not deserve a fix (the only one that I can imagine being possible off the top of my head to render a bunch of empty containers to the page to accommodate fields that may be displayed from any referenced product... but that feels pretty poor).

Thanks yet again for your replies Ryan.

It all makes perfect sense and as I was reading #17 the penny was dropping as to why my different product types were displaying as they were before I moved across to the Taxonomy method, and then confirmed in #18...I was following a naming convention agreed on for the project a bit too closely and although, for example both product types had an ISBN number I had idiotically called them something like field_ebook_isbn and field_print_isbn and expected them to work/switch.

Lesson learnt but I'm sort of liking the idea of using taxonomy now for this use case. I'll see what the other guys think.

I want to use the taxonomy for multiple valued options too. I'm on RC1, but I'm still restricted to using 1 term per product. What do I need to do to get this to work (the patch doesn't work anymore)?.

Thanks

That's the only way attributes work, Marcus. You can't have a multi-select attribute right now... it would be pretty complex for the user to select it. : )

Oookaaay...Don't understand everything that's said in this but thanks to those who mentioned that "If you disable the "required" option in the term reference field of the product type, you will no longer receive the error."...That sorted out "one" of my problems :)

Hi there,

I'd like to bring back the question of multi-valued attributes. In the shop that I'm building some products will have 2 or more values per attribute. For example, there are 2 variations of the T-shirt, one of them is red and white, and another is red and black. All the colors are term reference fields. In this scenario since there are multiple terms associated with one variation attribute, this attribute is not shown on the Add to cart form. Looks like this form shows only those attributes that has only 1 value. Doesn't look like a flexible solution.

For me it would work if they are displayed in the dropdown separated by the color:
* red, white
* red, black

Can anyone advice if there is a solution for such a case? Thanks in advance!

- Artem

Unfortunately, that's just not possible given the way the form currently works. You could possibly alter it to handle something like that, but it would require changing the way we detect the currently selected product so it tried to match field values based on single vs. multi-value field definitions. You'd also have to have a way to key the options of your attribute select widget to use values that matched multiple field values. It's a non-trivial change.

Thanks Ryan for your response. For me it looks like a major drawback and I'll be looking how to workaround that. I haven't yet looked at the code but thinking about next:

The attribute dropdowns on the Add to cart form are basically key-value fields, where value is the ID of the variation. Currently key is just a label of the term. My idea is to convert the array of terms into a string and put them into the key field. This way we'll receive the possibility to have multiple terms per attribute while it will still point to one variation. Hope it makes sense.

As I already mentioned I haven't looked at the code yet, so not sure how simple\complex it is to implement. Will let you know as soon as check that.

Thanks again.