0

Using Commerce Kickstart 2 distribution :

Question 1: Where should the computed field go to access fields from both the Content Type and Product Variation? Does the computed field belong to the content type or to the product variation?

Question 2: How do you reference one from the other?

ie - I thought...

$field_my_gauge = field_get_items($entity_type, $entity, 'field_needle_guage');
$field_my_type = field_get_items($entity_type, $entity, 'field_needle_type');
$field_my_st = field_get_items($entity_type, $entity, 'field_needle_style');
$field_my_len = field_get_items($entity_type, $entity, 'field_needle_length');
$vari_l = taxonomy_term_load($field_my_len[0]['tid']);
$vari_g = taxonomy_term_load($field_my_gauge[0]['tid']);
$vari_t = taxonomy_term_load($field_my_type[0]['tid']);
$vari_s = taxonomy_term_load($field_my_st[0]['tid']);
$vari_result =  $vari_l->name . $vari_g->name . $vari_t->name . $vari_s->name;
$vari_result = preg_replace('/[\s,.]{1,}/', '', $vari_result);
$entity_field[0]['value'] = $vari_result;

buuuut...

Notice: Trying to get property of non-object in eval() (line 9 of /Users/Robert/Sites/devdesktop/country_yarns/modules/computed_field/computed_field.module(468) : eval()'d code).

$vari_g is, or should, be based on the field_needle_guage field. But this is in the product variation of Needle, and not in the content type of Needle. All other fields are in the content type and work correctly.

So what's the right way to access members of a product variation in the content type - or is that even the right way around? (See Q1)

[EDIT]

Ok, so looking at the objects available in the wrapper:

$wrapper = entity_metadata_wrapper($entity_type, $entity);
// field_product_node is documented as the automatically created backreference to the content type.
$product = $wrapper->field_product_node;

// DrupalCommerce Kickstart 2 documentation says the below should work, but it does not - 'error: can't find getProduct function'. (WHY?)
$wrapper->getProduct();

// This comes out as an EntityDrupalWrapper
dpm($wrapper);
// This comes out as an EntityListWrapper
dpm($product);

// but below fails - can't find getIterator on object (WHY??)
$plist = $product->getIterator();
// and below returns an empty array! 
$plitems = $product->value(); 

So all these auto-back-reference class things in DrupalContrib are not accessible in this manner, it seems. If they work, I'd love to find out how!

Looking at how the tables are set up: field_revision_field_product is the link table between 'commerce_product' 'commerce_product_revision' and 'node', and any particular field_data_field_XXX field data table.

So I guess I need to use a sql query to get the field_data_field_XXX value through an inner join. I guess I'll need to put that into a custom module and then make a field of that type that allows you to configure what field to grab from the CT

  • When displaying content the product fields "push through" to the content type so that you can show variation-level product attributes. What purpose does the computed_field serve? What are you really wanting to do? – nvahalik Nov 27 '16 at 3:09
  • The code shows what I'm trying to do. I need to use a computed field to have a summary field to describe the product as a cumulation of the various components. You never see the product by the individual components. You would only see the product based on the computed summary value. So.... How do I access the product variation fields if they 'push through'? – Robert Achmann Nov 28 '16 at 1:52
  • The field in the variation is field_needle_guage. How do I fix this line to access the product variation? $field_my_gauge = field_get_items($entity_type, $entity, 'field_needle_guage'); – Robert Achmann Nov 28 '16 at 2:02
  • I see some people mention entity_metadata_wrapper('commerce_product', YOUR-REQUIRED-PRODUCT-ID); - but how to get required product ID? Also tried $wrapper = entity_metadata_wrapper('node', $node); dsm($wrapper->getPropertyInfo()); to see the properties, but it doesn't understand 'node'... Notice: Undefined variable: node in eval() -- I'm just a bit green on this...obviously – Robert Achmann Nov 28 '16 at 2:43
  • It shows you're trying to build a string... but you aren't mentioning what your intention is for using that string. You have to remember that at it's core Commerce doesn't just do a single product to many product variations. You can have PVs that are related to several different products (content nodes). If you have information that is definitional to what a PV is and you want that to be shown as part of the product then that field should be on the PV. If you only care about displaying it, that information can be on the PV but you're better of using theming to display the appropriate values. – nvahalik Nov 28 '16 at 3:16
0

To clarify from the comment thread:

  1. This is a question that is tough to answer on SE because it's just something you'll have to feel out. If you're doing 1:1 content types to product displays, it doesn't really matter where you put it (though it'd probably be easier to do it on the CT) in general I tend to put more on PV because it's data related to the product. If you're doing 1:N then you'll definitely want to put it on the PV and if you're doing M:N then you're going to have to do some customization.

  2. You can put the computed field on the PV but you'll need something like Entity Backreference so that the PV has a link back to the content type so you can load it and grab it's fields.

| improve this answer | |
  • Finding it hard to find an example of how to use that module...do you have a link? – Robert Achmann Dec 3 '16 at 17:52
  • have you ever used any back reference module? Do you have a code snippet you can share? I can't see how to use them – Robert Achmann Dec 5 '16 at 16:56
  • This is a dead end - I see no hope here as I can't find a single example – Robert Achmann Dec 8 '16 at 0:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.