Hi all, I have a similar error to #1480106: "unexpected error" crash site when activate order and #1376338: Failure to enable commerce_order_ui: Recoverable fatal error: Argument 2 passed to entity_views_field_definition() must be array, but nothing I do that was mentioned there seems to be working. In my case, when I try enabling the order sub-module, these are the two errors that get thrown:

Notice: Undefined index: commerce_order_total in commerce_order_entity_property_info_alter() (line 125 of /home/members/occucopy/sites/occucopy.org/web/sites/all/modules/commerce/modules/order/commerce_order.info.inc).
and
Recoverable fatal error: Argument 2 passed to entity_views_field_definition() must be an array, null given, called in /home/members/occucopy/sites/occucopy.org/web/sites/all/modules/entity/views/entity.views.inc on line 127 and defined in entity_views_field_definition() (line 149 of /home/members/occucopy/sites/occucopy.org/web/sites/all/modules/entity/views/entity.views.inc).

We are running on a shared server, which would explain the rather long pathnames. For us on this server, the root drupal directory is set as /home/members/occucopy/sites/occucopy.org/web, with everything else following on from there.

Even though I get the WSOD/these errors, most of the site still works. However, when I try to update or save anything to the database, the site keeps throwing the same errors. Usually just refreshing the page brings the page back out of WSOD-mode, and I can get on my way again. I have been able to install the rest of the Commerce sub-modules this way, and even put in some preliminary product info, but updating anything that has to do with entities throws the error again. I can't even flush caches via the UI, forcing us to resort to manual truncation in phpmyadmin. While annoying in the backend, this behavior is definitely not cut out for a production site, especially when we have customers complaining of the broken site.

I've tried everything mentioned in the other issue reports mentioned above to try to remedy the problem, including:
-Increasing PHP memory limit to 256M
-Disabling/uninstalling/erasing the install, manually wiping the db of %commerce%, and reinstalling DC (many, many times, including:)
-Running http://drupal.org/project/commerce_repair (which actually doesn't seem to fix the problem at all)
-Running the script in http://drupal.org/node/1480106#comment-5730318
-Disabling/Uninstalling/Reinstalling (once) again, but making sure to follow the step-wise procedure at http://drupal.org/node/1007434
-Making sure to clear/manually truncate caches, run cron, and back-up db between. Every. Single. Step.
-Looked briefly at working with http://drupal.org/project/registry_rebuild, but decided against it because although this issue is super annoying, it hasn't anywhere near borked the site, and I wouldn't want to unnecessarily fool around with registry stuff.

And the problem is still recurring. What am I doing wrong here? Is there really nothing else I can do, besides starting the entire site over from scratch with Commerce Kickstart? That would be an untenable proposition. It would be a damn shame to have to redo all that work, all for the sake of a few lines of code.

Looking at the actual files mentioned (entity.views.inc and commerce_order_info.inc), it seems the problem is that the field commerce_order_total hasn't been properly created in the commerce_order table in the database on installation by commerce_order.install, making it unavailable to send as an argument to the function entity_views_field_definition(). This happens because it looks like line 125 of commerce_order_info.inc packs the data in commerce_order into the array $info, which then gets sent via line 127 of entity.views.inc to the entity_views_field_definition() function (line 149). If commerce_order_total hasn't been created or can't be found, it can't be packed into the array as its own array. That is then sent on as a null value to the function, which is expecting an array, generating the second error report. So therefore, the error in commerce_order_total (the former error) leads on the the error in entity.views.inc (the latter error).

Does this make sense? Is this really what is going on? If it is, why would this lead to a WSOD every time I try to update anything?

Also, from the above, it would seem like the thing to do is to reinstate the commerce_order_total field within the commerce_order table in the db, a la the SQL commands in commerce_order.install. But I'm not sure how to do this, or even if it would really fix the problem.

If there are any drupal/commerce geniuses out there who can shed some light on this, we would definitely appreciate the assistance. I've been banging my head on this for days now, and my eyes are seriously starting to hurt.

Thanks!

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

rszrama’s picture

Category: bug » support

Hmm, you're saying Commerce Repair didn't create the missing Order Total field?

Anonymous’s picture

occucopy’s picture

Hi Ryan, thanks for the reply.

Yes, it doesn't do the job. I am assuming that Commerce Repair does its work immediately after hitting the link in the admin menu. It throws the same error when I click on the link, making me think that it's a chicken-and-egg kind of problem where Commerce Repair is unable to fix the error because the error itself keeps CR from operating correctly. Or something of the sort.

I see there is a commerce_line_items call in the same format one line above the one for commerce_order_total in commerce_order_info.inc. Tried manually duplicating the commerce_line_items field in the field_config and field_config_instance tables to see if that does the trick... but of course that would have been way too easy a fix.

Could someone come up with a step-wise process to manually set up the Order Total field? Or would it be possible to roll a simpler patch version of Commerce Repair that would do it automatically?

Thanks again!

occucopy’s picture

Oh no! Big step backwards! I tried uninstalling and reinstalling yet again, and now I'm getting a second undefined index error on top of the we've already got, this time for commerce_line_item:

Notice: Undefined index: commerce_line_item in field_info_instances() (line 687 of /usr/local/share/drupal-7.12/modules/field/field.info.inc).

tlangston’s picture

Replicated here. Repair doesn't create the order total field. Now hitting Fatal error: Unsupported operand types in ..\sites\all\modules\entity\entity_token.tokens.inc on line 93 - ostensibly because it can't find the field either.

Follow on note:

A) manually added rows to field_config and field_config_instance for this and error has cleared. The Price module was the module related to these rows.

B) Manually added tables 1) field_data_commerce_order_total and 2) field_revision_commerce_order_total

Was able to work thru the missing tables and data by doing an install of commerce kickstart locally and comparing databases. After adding rows indicated in A - errors thrown told me what additional tables needed to be added. Hope this helps with troubleshooting this issue and with others trying to get past this.

dankoB’s picture

I get the same error as tlangston (Fatal error: Unsupported operand types in ..\sites\all\modules\entity\entity_token.tokens.inc on line 93), while gradually enabling the Commerce submodules, specifically after Order_UI. I can't use Kickstart since I have an existing site. When I got this earlier today, I had to go to phpMyAdmin and one by one disable all the submodules before I got my site back for another try. Ran into the same issue the second time through. I may have to try the workaround described by tlangston, but it seems to be a long and tricky process, manually creating the tables with appropriate fields, as modeled after a separate local install with Kickstart. I will first have to get my site back online and wonder if I should first try the many other suggested remedies listed above. Though I'm not optimistic, considering that they didn't work for occucopy. I considered a memory limit problem since I have so many modules enabled, but it's already at 512M.

Christopher Riley’s picture

I too still run into this if EVA is installed. Disabling seems to stop the issue.

PatchRanger’s picture

Version: 7.x-1.2 » 7.x-1.x-dev
Category: support » bug
Status: Active » Needs review
FileSize
2.66 KB

Well, I've finally caught it.
I've tried flushing caches and even manual truncating.
I've tried Registry Rebuild.
I've tried re-installing one by one.
I've tried Commerce Repair.
And the reason is quite simple: we're trying to access missing property.
So we need a check before doing any actions with property we are going to alter.
See for example, how it is done in other implementations of hook_entity_property_info_alter:

Patch makes all of these implementations consistent - so there is no chance that such kind of problems will appear anywhere else as a ricochet.

FYI, there is a bunch of related and similar issues:

I guess they all could become fixed by this patch.
Please review.

rszrama’s picture

Still simply masks the problem of fields not existing that should have been created, but I suppose I don't mind adding the additional checks in since we do it already elsewhere. Will let the testbot have its say then give it a review / commit.

PatchRanger’s picture

@rszrama I agree, you are right telling that it is only a workaround to hide some strange behavior.
I have a suppose about the real nature of this situation.
I guess we can't find 'bundles' because it is not declared in hook_entity_property_info implementations though it is in place in hook_entity_info implementations. All of hook_entity_property_info implementations fill in 'properties' array but don't touch 'bundles' array: see for example commerce_line_item_entity_info, commerce_order_entity_info and commerce_product_entity_info. Could it be the real reason of the fact that we don't have 'bundles' array defined on stage of alteration?
This suggestion looks quite like truth since we have lines

  foreach (commerce_product_type_get_name() as $type => $name) {
    $return['commerce_product']['bundles'][$type] = array(
      'label' => $name,
    );
  }

in both commerce_line_item_entity_info and commerce_product_entity_info but NOT in commerce_order_entity_info.
What do you think?

PatchRanger’s picture

As Linus said, "Stop talking, show me the code" :)
Here you are a patch that describes what I mean.

Status: Needs review » Needs work
Issue tags: -WSOD, -Drupal, -order, -Commerce (duplicate), -commerce_order, -commerce_order_total, -entity.views.inc

The last submitted patch, d7-commerce-fix_missing_entity_properties-1509994-11.patch, failed testing.

PatchRanger’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work
Issue tags: +WSOD, +Drupal, +order, +Commerce (duplicate), +commerce_order, +commerce_order_total, +entity.views.inc

The last submitted patch, d7-commerce-fix_missing_entity_properties-1509994-11.patch, failed testing.

PatchRanger’s picture

What's the problem? "Fatal error: Allowed memory size of X bytes exhausted" for all tests.
Somebody please help me to tame the bot. :)

PatchRanger’s picture

Wow, the problem is deeper than it seemed. Wait a patch for a while.

PatchRanger’s picture

Status: Needs work » Needs review
FileSize
11.91 KB

Please review the patch.
I think it is the most appropriate way to solve this issue.

RealGecko’s picture

Patch from #17 helped to solve http://drupal.org/node/1376338, looks like connected.

Peter Buchanan’s picture

I solved this irritating problem by:
1. Removing the commerce module (using FTP)
2. Running update.php
3. Using PHP admin to drop all the tables in the SQL database with commerce in the table name
4. Loading and enabling the commerce and commerce_repair modules
5. Running commerce_repair as each sub module is installed
Rather boring but it fixed the problem for me and I've got commerce installed and operational.

acmaintainer’s picture

I have been through every scenario and fix attempt in this and other related issue queues, to no avail. However, I decided to try installing the latest dev version, in my case 1.4+28, to see if the amazing Commerce Guys had been working on this. I am happy to report that it installed and enable on my local (fresh installed) sandbox site with absolutely no problems. Just in case, I was still careful to enable sub modules one at a time, based on whether all the requirements for the particular sub module were enabled.
I have not actually starting using it yet, but was so excited I had to share.
Thanks Commerce Guys!
I am off to see if I can use it to break my local dev site:-) If you don't hear from me, all went well.

acmaintainer’s picture

I am sad to report that the new dev did indeed break my local dev site. Back to square 1.

rszrama’s picture

Did you try the patch in #17? That's what needs to be review; it hasn't been committed yet, or this issue would be marked "fixed".

rszrama’s picture

Issue summary: View changes

Edited some typos.

acmaintainer’s picture

This is a (near) duplicate comment that I posted on http://drupal.org/node/1376338. The issues seem very much related as I have gotten pretty much all of the mentioned errors:
My mystery is solved!!!! It is definitely a conflict with the Eva module. Everything was perfect after disabling it.
I saw a post where someone was having that same eva issue, and I disabled it locally. However at the time I began having fatal errors thrown by the lack of resources settings in my local dev site "my.ini" file (http://drupal.org/node/259580), and thought the eva thing was not helping.
So, I had 2 sets of problems going and had to peel the onion. It worked locally once I got past the resources issue, then had the original problem (this issue queue) on the staging site. Why? Because I had not disabled eva on the remote dev site. Dang.
Anyway, the eva module was not being used for much, so it goes, in favor of Commerce.
Great module! Nice job. I hope this helps anyone else who might have either or both of these issues.
BTW, KickStart is wonderful. I did all my "studying" on it, before attempting Commerce on the existing site.
Thank you, many times over.

rszrama’s picture

Title: Enabling Order Submodule throws WSOD/error » Missing entity property info results in notices / WSOD / fatal errors during installation
Status: Needs review » Needs work

On a quick review of the patch, I don't believe I want to commit the new order type info hooks. We intentionally left support for multiple order types out of the core of Commerce 1.x, so I'd prefer to simply hardcode the necessary array in commerce_order_entity_property_info() like we already are in commerce_order_entity_info().

Also, helior in a related issue has provided a list of notices / warnings we can use to ensure the patch works: #1361562-13: Re-enabling Commerce causes a PHP Fatal Error

arnoldbird’s picture

I'm running into this issue in Commerce 1.8. I'm not sure what is the best way forward.

PatchRanger’s picture

Status: Needs work » Needs review
FileSize
10.03 KB

Re-rolled given #24.

wimberb’s picture

Does anyone know if this fix has been added into the dev version? The EVA problem has been preventing me from installing Drupal Commerce for a long time. I tried disabling EVA so I could install Commerce but it ended up breaking all of my pages that use EVA so I had to revert my database to get the pages working again.

wimberb’s picture

Issue summary: View changes

Reformatting links to issues.

pcambra’s picture

Encountered #1430894: Recoverable fatal error: Argument 2 passed to entity_views_field_definition() must be an array on an install and the patch in #26 fixes the issue, here's a reroll that removes the extra order bundles support.

jnicola’s picture

Status: Needs review » Reviewed & tested by the community

Installed Ck1 multiple different ways both with and without the patch:

1- Using ck profile
2- Using standard profile, later enabling modules
3- Enabling modules via drush.

With, and without the patch I have no errors with latest version of ck 1.x

Using OSX Homebrew environment. PHp 5.5.3

bojanz’s picture

Status: Reviewed & tested by the community » Fixed

Committed #28, thank you everyone.

  • bojanz committed 77e72d6 on 7.x-1.x authored by PatchRanger
    Issue #1509994 by PatchRanger, pcambra: Missing entity property info...

Status: Fixed » Closed (fixed)

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