This issue keeps coming up and it's time to wrap them all up into a single issue so folks have a clear understanding of what's going on. The presenting problem is a FieldException error on install informing you that some Field or another didn't get created because it doesn't exist. Sadly, this is not true - as long as the installer is installing module dependencies in order, the Fields actually do exist but because of a stale cache Drupal doesn't know about them.

What this means is you cannot install a module and its dependency at the same time without risking these errors (particularly this applies to products, orders, and line item). To avoid the problem completely, install the modules iteratively in the order of their dependencies or use the installation profile at http://github.com/rszrama/drupalcommerce.

The fact that this works properly through the installer and not the system modules form is the reason this should be classified as a core bug. During the installer, caches are getting cleared as necessary thanks to the batch process (I presume). The behavior here then is different from what you get when you enable modules via the normal admin interface, and that shouldn't happen.

So, the solutions at a core level would involve changing the nature of that form's submission to be more like the installer or flushing more caches after each module is installed than just the entity cache (the Field cache, for example... or really any cache that contains module defined information).

For the sake of Drupal Commerce, in our install-time functions that depend on Fields from other modules, I have a working solution - I just can't commit it / make a patch immediately because it involves files that I have w.i.p. code in. :-/ Basically, if I know a Field should exist by virtue of a module's dependencies and it does not exist, I'm flushing the Field cache prior to creating the new Field. This is poor, though, in that it will result in the Field cache being cleared and rebuild at unnecessary times, but it's better than fielding a new FieldException issue every few days. The real fix should be in core.

For more information, see the stalled core issue: #727876: Enabling modules one at a time works differently than enabling them all at once

CommentFileSizeAuthor
#2 906668.field_cache_clear.patch3.11 KBrszrama

Comments

rszrama’s picture

rszrama commented

Ugh, the installation profile is actually at http://github.com/rszrama/commercedev. :-/

rszrama’s picture

rszrama commented
StatusFileSize
new 906668.field_cache_clear.patch3.11 KB

And here's the patch.

Anonymous’s picture

Anonymous (not verified) commented

Subscribing.

As a note for any Drush users out there, until this issue is resolved, here are the two separate Drush commands I am using to work around this issue (after Drupal commerce and it's dependencies have been downloaded).

drush en entity entity_metadata rules views rules_admin views_ui addressfield commerce commerce_product commerce_price commerce_customer commerce_line_item commerce_ui commerce_line_item_ui
drush en commerce_order commerce_checkout commerce_product_reference commerce_order_ui commerce_payment commerce_cart commerce_product_ui commerce_customer_ui commerce_payment_ui commerce_payment_null

Also, here is ksenzee's thoughts on the drupal core bug that rszrama linked to http://drupalbin.com/15984

I'll test out the patch later today.

Anonymous’s picture

Anonymous (not verified) commented

Testing out the patch.

I just disabled all of the modules and then enabled them all (using Drush). And the same errors came back

WD php: FieldException: Attempt to create field name line_items which already exists, although it is inactive. in field_create_field() (line 272 of                     [error]
/Users/auzigog/Sites/d7head/modules/field/field.crud.inc).
WD php: Warning: Cannot modify header information - headers already sent by (output started at /Users/auzigog/Development/.drush/includes/drush.inc:820) in             [warning]
drupal_send_headers() (line 1048 of /Users/auzigog/Sites/d7head/includes/bootstrap.inc).
FieldException: Attempt to create field name <em class="placeholder">line_items</em> which already exists, although it is inactive. in field_create_field() (line 272 of /Users/auzigog/Sites/d7head/modules/field/field.crud.inc).

Should I have uninstalled them as well?

Any idea how to trace this?

Anonymous’s picture

Anonymous (not verified) commented

Same FieldException error when I do it from the

Was this patch targeted at people who were installing Commerce for the first time?

Anonymous’s picture

Anonymous (not verified) commented
Status: Active » Needs work
rszrama’s picture

rszrama commented
Status: Needs work » Active

Ahh, yeah, it was targeting first time installs, but it really should work for anything. You're actually getting different errors that I'm guessing should be in a separate issue... it's attempting to recreate a field that already exists.

Anonymous’s picture

Anonymous (not verified) commented

I just tried this on a clean database and got:

WD php: FieldException: Attempt to create a field of unknown type commerce_line_item_reference. in field_create_field() (line 297 of                                    [error]
/Users/auzigog/Sites/d7head/modules/field/field.crud.inc).
WD php: Warning: Cannot modify header information - headers already sent by (output started at /Users/auzigog/Development/.drush/includes/drush.inc:820) in             [warning]
drupal_send_headers() (line 1048 of /Users/auzigog/Sites/d7head/includes/bootstrap.inc).
FieldException: Attempt to create a field of unknown type <em class="placeholder">commerce_line_item_reference</em>. in field_create_field() (line 297 of /Users/auzigog/Sites/d7head/modules/field/field.crud.inc).

*shrug*

Maybe there are two different problems here. Ksenzee mentioned a workaround for the problems with hook_modules_enabled() (which line item does use).

Maybe we could try that workaround?

pieterdc’s picture

pieterdc
Primary language Dutch
Location Ghent
commented

Using yesterday's version of all required code (Sept. 27th) and the commerce installation profile; my installation worked just fine.

But that's probably not what you're testing here?

Just saying cuz I'm trying to help.

rszrama’s picture

rszrama commented

Yeah, it's actually always worked w/ the installation profile - doesn't seem to like the normal module enabling process, though. I think the difference is the Batch API is used in the installer to install one module at a time on separate page requests... dunno if I researched that fully or not, though.

rszrama’s picture

rszrama commented

For what it's worth, #931190: Enabling modules via the UI breaks module dependencies might have solved this issue. We'll know once we update to the first D7 beta.

rszrama’s picture

rszrama commented
Status: Active » Fixed

Ok, I can't reproduce the bugs we'd been having on D7-beta1, and I'm not seeing FieldException errors anywhere. I'm going to mark this fixed thanks to core, but we can reopen if necessary.

mertskeli’s picture

mertskeli commented

I'm keeping it as fixed although I had all the possible errors while installing today.
Honestly, I do not understand how this module is going to be used for any commercial site.
I have been installing DC for half a year already, and it never installs. Never. Maybe I'm stupid?
Drupal, Views, Entity, Rules, Address are fine - no errors.
Enabling all DC checkmarks at once - WSOD, finita la comedia.

rszrama’s picture

rszrama commented

WSOD sounds like you need to up your PHP memory limit. As for how the modules will be used, I've never had a problem with the errors and the workarounds to core Drupal behavior are fully documented. Have you still not tried the installation profile, http://github.com/rszrama/commercedev?

mertskeli’s picture

mertskeli commented

Memory is sufficient. It's a local install anyway. Numerous errors followed by Drupal's death - no interfave, only error messages. Wsod was a wrong word.
No, I haven't tried the installation profile, and I do not expect everybody will :)

rszrama’s picture

rszrama commented

Certainly, the modules stand on their own two feet, but I've never had a problem with the profile - I recommend it for alpha testing, as it avoids the common installation problems of Drupal itself. That said, I did test a Commerce install by using the Standard installation profile w/ D7-beta1 and then just checking boxes by the UI modules for Drupal Commerce. The dependencies were installed and everything was configured just fine with no errors. Without error messages, there's not much I can do to help... other than to say start using that profile. I've been recommending it for months. : P

mertskeli’s picture

mertskeli commented

Ok, I'll try to use that profile...
rszrama, your increadible humanity keeps my belief in DC alive :)

rszrama’s picture

rszrama commented

hehe Thanks for the vote of confidence - and sorry for being short in my comments above. If you do turn up error messages, though, please post an issue for them. I definitely want the stuff to be usable without an installation profile. ; )

Status: Fixed » Closed (fixed)

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

stephthegeek’s picture

stephthegeek commented
Version: 7.x-1.x-dev » 7.x-1.0-alpha3

Just for anyone searching... I ran into this error but enabling modules just a couple at a time seemed to fix it.

gargsuchi’s picture

gargsuchi commented

Please refer to http://drupal.org/node/867118#comment-3400616

I had the same issue today - with the following install:
drupal-7.0.tar.gz
addressfield-7.x-1.0-alpha1.tar.gz
schema-6.x-1.7.tar.gz
commerce-7.x-1.0-alpha4.tar.gz
entity-7.x-1.0-beta6.tar.gz
views-7.x-3.0-alpha1.tar.gz
ctools-7.x-1.0-alpha2.tar.gz
rules-7.x-2.0-alpha4.tar.gz

But if i enable views/ rules/ ctools etc. BEFORE enabling commerce module and it's sub-modules, I was able to install without any errors.

Thx
Suchi Garg

blup’s picture

blup commented
Issue tags: +dcsprint5

New branch with working changes. https://github.com/blup/drupalcommerce/tree/906668

rszrama’s picture

rszrama commented
Status: Closed (fixed) » Needs review
rszrama’s picture

rszrama commented
Status: Needs review » Fixed

Reviewed by recidive, committed by me.

Status: Fixed » Closed (fixed)
Issue tags: -dcsprint5

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

Issue tags: +dcsprint5

Restoring issue tags, see #2125755: System messages removed all issue tags during D7 upgrade.