Error message

Deprecated function: implode(): Passing glue string after array is deprecated. Swap the parameters in drupal_get_feeds() (line 394 of /home1/tylerfra/public_html/includes/common.inc).

EntityMetadataWrapperException: Unknown data property commerce_product. in EntityStructureWrapper->getPropertyInfo()

Category: 

After struggling with this issue for days, and days, and days, and more days, I was finally able to debug it by placing the following line of code in the getPropertyInfo() function inside of the sites/all/modules/entity/includes/entity.wrapper.inc file (be sure to have the Devel module enabled on your Drupal site):

dpm(debug_backtrace());

The code above should go right before this line:

throw new EntityMetadataWrapperException('Unknown data property ' . check_plain($name) . '.');

Don't ask me why it took me so long to think about using debug_backtrace(), but luckily I learned a whole bunch of good stuff in the process.

What the debug_backtrace() told me was, the file (and line number) who was making the bad call. Here was my culprit line of code:

$product_type = $line_item_wrapper->commerce_product->type->value();

All in all, this issue can happen for various reasons. In my case, it was someone (me) assuming there would always be a commerce_product variable on all line item wrappers. This is NOT true, there are a few popular Commerce contrib modules that expose custom line items without the product reference. This means all I had to do was do an isset() check before trying to continue:

if (!isset($line_item_wrapper->commerce_product)) { return; }

Thanks to Kazanir in #drupal-commerce on IRC for the nudge in the right direction!

Comments

YOU ARE THE MAN! (Unless, you're a woman, in which case, YOU ARE THE WOMAN!)

Either way, gender aside, thankyou, thankyou, thankyou, thankyou etc. repeat ad infinitum.

Had our own commerce module (custom) which made the exact same assumption, and after the many 4-legged chicken chases down Google lane, I finally stumbled upon this and now we're back in business!

 

 

 

As a follow up, just to anyone else that may find this page, the Commerce Shipping module does indeed create a line item, which does not have commerce product.

As pointed there http://www.mediacurrent.com/blog/entity-metadata-wrapper#4, I think "

if (!isset($line_item_wrapper->commerce_product)) { return; }

"

is wrong. You should check values with intermediates variables.

YOU ARE THE MAN! (Unless, you're a woman, in which case, YOU ARE THE WOMAN!) .. I second the motion 

I traced the error using debug_backtrace() and I easily found the bug

@Judapriest, on the contrary; EntityMetadataWrapper implements __isset() so 

isset($line_item_wrapper->commerce_product)

is valid, and will return true if the property commerce_product is known.

It's not especially clear in the mediacurrent blog post, but I think they're referring to the problems using isset() to determine if the field has a *value* as opposed to determining whether the field *exists*.

Let me start by saying I am very new to using Drupal, but I have encountered the same exact error on a prototype site here

I've looked over the entity.wrapper.inc file and line 335, which appears to be the problem

      throw new EntityMetadataWrapperException('Unknown data property ' . check_plain($name) . '.');

I'd like to try out the above-mentioned solution with the isset() check, but I'm not sure where to place this in my entity.wrapper.inc file or if it will even work.

I've uninstalled and reinstalled Drupal Commerce at least a half dozen times now with no luck.

If anyone has a moment, I'd really appreciate some suggestions or guidance!

tyler's picture

You'll have to print out the back trace before it throws the exception. Add this before the thrown exception in entity.wrapper.inc:

dpm(debug_backtrace());

That will let you dig in and find the files (and line numbers) that have been executed, then you can trace backwards to find the culprit(s).

Glad it's only a matter of isset(), but wouldn't it be nice if the wrapper just returned nothing or a warning in the case of a missing field, instead of throwing a fatal error? It bugs me that this and EntityFieldQuery both just enitrely crash stuff whenever something's missing.