If you remove all product types you get this on some pages. I'm not sure it's important, as it's an unusual occurrence, but :
Notice: Undefined index: commerce_product in field_info_instances() (line 682 of /home/rfay/workspace/commerce/modules/field/field.info.inc). Backtrace:
field_info_instances('commerce_product') commerce_product_reference.module:40
commerce_product_reference_field_extra_fields()
call_user_func_array('commerce_product_reference_field_extra_fields', Array) module.inc:819
module_invoke_all('field_extra_fields') field.info.inc:231
_field_info_collate_fields() field.info.inc:658
field_info_field_by_ids() field.attach.inc:603
field_attach_load('rules_config', Array) entity.controller.inc:633
EntityAPIControllerExportable->attachLoad(Array, ) rules.core.inc:36
RulesEntityController->attachLoad(Array, ) entity.controller.inc:230
EntityAPIController->load(, Array) entity.controller.inc:532
EntityAPIControllerExportable->load(, Array) common.inc:7448
entity_load('rules_config', , Array) entity.module:143
entity_load_multiple_by_name('rules_config', , Array) rules.module:603
rules_config_load_multiple(, Array) rules.plugins.inc:696
RulesEventSet->rebuildCache(Array, Array) rules.module:260
_rules_rebuild_cache(Array) rules.module:239
rules_get_cache('data') rules.module:232
rules_get_cache('event_init') rules.module:722
rules_invoke_event('init') rules.module:26
rules_init()
call_user_func_array('rules_init', Array) module.inc:819
module_invoke_all('init') common.inc:4942
_drupal_bootstrap_full() bootstrap.inc:1933
drupal_bootstrap(7) index.php:20
Comments
Comment #1
rfayThis is a core problem. The attached patch works around this problem.
Comment #2
marcingy commentedLook sensible as far as I can see.
Comment #3
sunI think we need to use a ternary operator in the return value - otherwise, we're not entering the condition when we're supposed to.
Second, this looks important enough for me to require tests.
20 days to next Drupal core point release.
Comment #4
dave reidThis is the syntax I'm used to for this type of double-optional function which also makes the most sense to me. Adding tests.
Comment #6
dave reidRevised patch, passes tests.
Comment #7
yched commentedCode looks good, however the test is wrong :
$instances = field_info_instances('test_entity');is always keyed by the bundles known for the entity type (known = exposed in hook_entity_info())Comment #8
dave reidIsn't that what we're testing?
Comment #9
yched commentedOoops, crosspost, my comment was for patch #4.
RTBC :-)
Comment #10
dave reidSmall change to the assertion messages, no functional change so leaving RTBC.
Comment #11
catchThanks!
Committed/pushed to 8.x, moving to 7.x for backport.
Comment #12
purencool commentedComment #13
purencool commentedComment #14
willvincent commentedRerolled patch from #10 for D7.
I've also included p0 format patch for the benefit of those not using a git checkout of core.
Comment #15
webchickMoving to 'needs review'.
Comment #17
rfayTo make a patch not be tested, name it like
field_info_instances_...-p0-do-not-test.patch
But anybody using the patch tool can use
patch -p1with a standard git patch.Comment #18
willvincent commentedGood call, though I don't believe it's possible to specify that -p1 flag with drush make
Comment #19
rfaydrush make has handled git-style patches for many months now.
Comment #20
willvincent commentedBut will they apply to a project that's not checked out from the git repo?
EDIT: Just tested that myself, and color me surprised.. it sure does. Thanks for the info on that Randy, I had no idea drush make would apply a git patch to a project that's downloaded rather than cloned from the repo. :)
Comment #21
rfayYes, git patches are just
patch -p1patches. nothing special.Drush make added support for all regular git patches in the issue queue in #745224-132: Apply patches from git diff and git format-patch in July, 2011.
Comment #22
willvincent commentedAt any rate, the patch in #14 does apply cleanly and resolves this issue.
I don't seem to be able to run the tests locally at all without them simply timing out and failing. Probably a server config issue I imagine, but I'm not clear why the one test is failing with the testbot, that shouldn't be affected by this patch at all as far as I can tell.
Queuing for re-test.
Comment #23
willvincent commented#14: field_info_instances_fix_returns-1245332-14-7.x.patch queued for re-testing.
Comment #24
dave reidRe-uploading D7 patch only.
Comment #25
dimitriseng commentedI have tested #24 and I can confirm that it seems to resolve the issue, thank you!
Comment #26
dave reidFeel free to mark this issue as 'reviewed and tested by the community' then so we can get this fixed in Drupal 7. :)
Comment #27
yched commentedyup, same as for D8
Comment #28
willvincent commentedWeird. Why did it pass when you uploaded it?
Comment #29
marcingy commentedBumping to d8 because it needs to go in there first
Comment #30
marcingy commentedMy bad
Comment #31
webchickCommitted and pushed to 7.x. Thanks!
Comment #33
dig1 commentedFYI I did a fresh install of D7.12 and some modules. I deleted all content types and then got this message:
I installed the patch in #24 and the error messages disappeared after the cache was cleared. So that worked, thanks :)
Comment #34
funature commentedit works for me too
Comment #35
drupalninja99 commentedDid this ever make it to a stable release? I don't see a note anywhere
Comment #36
rfayIt was committed to D7 on March 11, so is part of 7.14. The commit was http://drupalcode.org/project/drupal.git/commitdiff/f145e08cfd0c67f05ec8...