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
Comment | File | Size | Author |
---|---|---|---|
#13 | interdiff.txt | 292 bytes | jurgenhaas |
#13 | support_for_api_of_the-2407799-13.patch | 1.87 KB | jurgenhaas |
#11 | interdiff-10-11.diff | 1.45 KB | jurgenhaas |
#11 | support_for_api_of_the-2407799-11.patch | 1.83 KB | jurgenhaas |
#10 | dimension-entity_property_type-2407799-10.patch | 1.81 KB | hargobind |
Comments
Comment #1
jurgenhaasThis 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.
Comment #2
TajinderSingh CreditAttribution: TajinderSingh commentedThanks 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'
Comment #3
jurgenhaasThanks 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.
Comment #4
hargobindI 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!Comment #5
jurgenhaasThanks @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.
Comment #6
jurgenhaas@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.
Comment #7
hargobindWhile 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.
mymodule
module for testing. All it does is print out the value of the field using standard "field" notation and "entity_metadata_wrapper" notation.Comment #8
jurgenhaasThanks @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:
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?
Comment #9
hargobindYou 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:
So that snippet is actually describing how you need to add the
property_type
andproperty_callback
properties in your implementation ofhook_field_info()
. I can see why you were confused ... I think their use of the function nameentity_hook_field_info()
is misleading and it should just behook_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
andproperty_callback
properties todimension_field_info()
. And the remainder of the code is just the callback function forproperty_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.
Comment #10
hargobindFor 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.
Comment #11
jurgenhaasThis 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?
Comment #12
hargobindAhh 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:Comment #13
jurgenhaasOf 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?
Comment #14
hargobindI 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.
Comment #16
jurgenhaasYou're right, D8 is completely different. No reason to port this change as the classes there have fine grained access to properties already.
Comment #17
jurgenhaas@hargobind please have a look at #2896843: Deprecate module in favour of the physical module and let me know what you think.
Comment #18
hargobindNice 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!
Comment #19
jurgenhaasThanks @hargobind for letting me know, better still that we received your contribution. Much appreciated!