Thanks for this nice module.

I am getting below error when used dimension field in commerce_pricing_attributes option set.

EntityMetadataWrapperException: Unknown data property field_area1. in EntityStructureWrapper->getPropertyInfo() (line 339 of /opt/lampp/htdocs/hqconf/sites/all/modules/contrib/entity/includes/entity.wrapper.inc).

This seems somehow $commerce_option_wrapper->{$field_name}->value(); isn't going fine which generated error in function
public function getPropertyInfo($name = NULL)
in file mentioned under error.

Kindly help if possible with any suggestion on what can be the reason.

Tajinder Singh

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

jurgenhaas’s picture

Status: Active » Postponed (maintainer needs more info)

This is hard to analyze, I haven't seen such an error in this context before. Is it possible that you describe on how to reproduce the problem from scratch? I mean, this would require a plain Drupal installation, a set of extra modules being enabled and then 1..n setup steps until this above error happens, so that we can try in a test environment and then fix it when we've found the reason for it.

TajinderSingh’s picture

Thanks for quick reply.

Below are the steps:
1. Install Drupal 7.34
2. Install Module: Commerce, Commerce Option, Commerce Product Attributes, Commerce Pricing Attributes, CTools, Dimension, Entity, Rules, Views, Inline Entity Form
3. Create new Product Options set with a 'Dimension' field having mode 'Width and Height'
4. Add 'Pricing Attributes' field with widget 'Pricing Attributes Widget' in default variation type: Product. Mark 'Dimension' field in Options set as enabled.
5. Create a new Content type 'Product' with field 'Variations' of type 'Product reference' with widget 'Inline Entity Form - Multiple values'
6. Now proceed to add a new product with a variation of type 'Product' having option set we created as selected and 'Dimension' field enabled
7. After creating the product, product will open in view mode having 'Add to Cart' form. Add product in cart while giving values to 'Dimension' field dimensions. The page will refresh
8. Now Click 'Shopping cart' link under block in left sidebar.
9. On 'Shopping cart' page exception will be throws as:
EntityMetadataWrapperException: Unknown data property field_dimensions2. in EntityStructureWrapper->getPropertyInfo() (line 335 of /opt/lampp/htdocs/ddimension/sites/all/modules/entity/includes/entity.wrapper.inc).

The difference found in 'Commerce Product Dimensions' & 'Commerce Pricing Attributes' is that earlier picks field values via Entity metadata wrapper as $commerce_option_wrapper->{$field_name}->value().

'Commercr Product Dimensions' picks 'Dimension' field value using $line_item->{$type}[$langcode][0] where $langcode is hard coded as LANGUAGE_NONE in line just before it in file 'commerce_product_dimensions.module'

jurgenhaas’s picture

Thanks for the writeup, I tried to follow the instructions but came across some gaps, e.g. which versions of each module to use and steps 3-7 are not acurate enough for me to quickly go through.

So you could probably dump the database of that test instance and send that as a PM? Or you could look into commerce_product_dimensions.module and check if the language code for the line item can be determined otherwise and create a patch for that.

hargobind’s picture

Status: Postponed (maintainer needs more info) » Active

I think the solution to this issue is that hook_field_info() needs to have a 'property_type' key on the field definition. Do a google search for "entity metadata wrapper hook_field_info property_type" and you'll see a handful of articles and Stack Overflow posts such as this one and this one. Good luck!

jurgenhaas’s picture

Thanks @hargobind, this sounds very interesting and I never came across this before. What would be required is a simple reproducable setup where the problem can be shown and then fixed. Ideally, some instructions how to setup a D7 site from scratch to reproduce this would certainly help to get this off the ground. Of course, without commerce involved would be much appreciated.

jurgenhaas’s picture

Status: Active » Postponed (maintainer needs more info)

@hargobind any chance you could help me with a reproducable sample? I'm keen to get this addressed but need an environment where I can see the before and after effect.

hargobind’s picture

Category: Support request » Bug report
Status: Postponed (maintainer needs more info) » Needs review
FileSize
1.8 KB
654 bytes

While trying to provide a reproduceable example, I ended up writing the code that adds the property type as well as a property callback to get the values. See attached patch.

I was able to reproduce this using the following set up.

  1. Install Drupal 7 (7.56) with the "Standard" installation profile
  2. Install Entity module (1.8), and Dimension module (1.0)
  3. Modify the "article" content type to add a field called "field_dimensions". Doesn't matter what dimension configuration you choose.
  4. Install the attached mymodule module for testing. All it does is print out the value of the field using standard "field" notation and "entity_metadata_wrapper" notation.
  5. Create a new article node and add values to the Dimensions field. You should see the debugging messages when you view the node.
  6. Next, apply the attached patch to the dimensions module and clear your cache.
  7. Go back to the same node to see the debugging messages. If you see a message starting with "Wrapper loaded.", then it means the patch is working and the property callbacks are doing their job.
jurgenhaas’s picture

Title: EntityMetadataWrapperException: Unknown data property » Support for API of the entity module
Category: Bug report » Feature request
Status: Needs review » Needs work

Thanks @hargobind for your instructions on how to reproduce this effect. That helped me to understand, that this is not bug, instead there is another module (entity) which comes with their own API which may be supported in addition to the field API of Drupal core. That's why I changed the title and category of this issue.

To make it clear, the dimension module works just fine and does not require the entity module. But if you also install the entity module and want to use their additional API like e.g. meta data wrapper, then the dimension module may add additional code to support them as well.

Now, regarding your patch I'm not yet happy with that. As soon as I recognised that this is a request to support the entity API I checked their documentation which describes a new hook to introduce the property_type:

/**
 * Provide entity property information for fields.
 *
 * This is a placeholder for describing further keys for hook_field_info(),
 * which are introduced by the entity API.
 *
 * For providing entity property info for fields each field type may specify a
 * property type to map to using the key 'property_type'. With that info in
 * place useful defaults are generated, which suffice for a lot of field
 * types.
 * However it is possible to specify further callbacks that may alter the
 * generated property info. To do so use the key 'property_callbacks' and set
 * it to an array of function names. Apart from that any property info provided
 * for a field instance using the key 'property info' is added in too.
 *
 * @see entity_field_info_alter()
 * @see entity_metadata_field_text_property_callback()
 */
function entity_hook_field_info() {
  return array(
    'text' => array(
      'label' => t('Text'),
      'property_type' => 'text',
      // ...
    ),
  );
}

So, I implemented that hook into dimension.module (instead of adding the property type to the dimension_field_info()) but the problem is that this hook is never called.

Is their documentation broken or what else is going wrong? Can you help me understand this problem?

hargobind’s picture

Status: Needs work » Needs review

You are correct that this technically is not a bug in the dimension module, but a matter of making alterations to support integration with Entity API's entity_metadata_wrapper().

Regarding the snippet that you pasted above. Note the 2nd line in the comments:

 * This is a placeholder for describing further keys for hook_field_info(),
 * which are introduced by the entity API.

So that snippet is actually describing how you need to add the property_type and property_callback properties in your implementation of hook_field_info(). I can see why you were confused ... I think their use of the function name entity_hook_field_info() is misleading and it should just be hook_field_info().

The first few lines of code in my patch actually does what that hook is describing, i.e. it adds the property_type and property_callback properties to dimension_field_info(). And the remainder of the code is just the callback function for property_callback so that it returns the same property values that you get from the value of $node->field_dimensions[LANGUAGE_NONE][0].

Setting the issue back to Needs Review since my patch does exactly what you were trying to figure out with that hook in your snippet.

hargobind’s picture

For more reading on this topic, see these two articles as examples of other implementations of properties with multiple keys/values:
https://www.drupal.org/docs/7/api/entity-api/property-info-for-fields
https://www.drupal.org/node/1681610
And have another look at the following article which is what I mostly based my code on:
http://d7.thecarneyeffect.co.uk/describe-field-properties-make-custom-fi...

Also, I just realized when looking back at my code that it defines each property key as 'text'. Should be 'integer'. Fixed in the attached patch.

jurgenhaas’s picture

Version: 7.x-1.0 » 7.x-1.x-dev
FileSize
1.83 KB
1.45 KB

This is great @hargobind, thanks a lot for your support on this.

I have enhanced the patch a bit such that depending on the field settings, not all three properties are known but only some of them. What do you think?

hargobind’s picture

Ahh yes, this makes sense to only return the properties that are in use.

One suggestion to your patch though... instead of comparing $field['settings']['mode'] to a number, why not use constants? Or better yet, why not use the existing logic in your code:

list($has_length, $has_more) = _dimension_get_modes($field['settings']['mode']);
jurgenhaas’s picture

Of course, stupid me. Attached the version with the built-in logic.

If this is going to RTBC I was wondering about the D8 version of it. Are you familiar with the Entity API in API and is there anything similar to the MetaDataWrapper?

hargobind’s picture

I don't know Drupal 8 at all -- never installed it, never touched any code for it -- but I imagine something similar exists, and it may already built into Drupal core as far as how field values are set()/get(). You could probably open an issue in the Entity API module to see if there's a D8 equivalent.

The code looks great! I haven't tested it, but I bet you could test it with each of the 3 modes to see if you get back what you expect to see.

  • jurgenhaas committed 39764aa on 7.x-1.x
    Issue #2407799 by jurgenhaas, hargobind: Support for API of the entity...
jurgenhaas’s picture

Status: Needs review » Fixed

You're right, D8 is completely different. No reason to port this change as the classes there have fine grained access to properties already.

jurgenhaas’s picture

@hargobind please have a look at #2896843: Deprecate module in favour of the physical module and let me know what you think.

hargobind’s picture

Nice to see it committed!

Thanks for thinking of me regarding the other issue. However, I actually don't use the dimension module ;-) I only stumbled upon this issue when trying to figure out my own implementation of the hook_entity_info() for EMW, and wanted to contribute the info (and code) to get it working for dimension. I don't know all of this module's features or how similar/different it is to the physical module, and I have too much on my plate right now to do much exploration. Good luck!

jurgenhaas’s picture

Thanks @hargobind for letting me know, better still that we received your contribution. Much appreciated!

Status: Fixed » Closed (fixed)

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