Disabling or uninstalling a node-type module (e.g. Forum), or removing a node type, results in "undefined index" notices

Ive seen this with other modules to fwiw.

Discovered a similar issue by deleting the article content type with enabled comments from the default install. Note that calling every possible cache flushing function did not help either nor did truncating the cache tables. (there is a related issue to cached field info generating warnings)

It appears that the comment body instance is not deleted.

This is the third record in the field instance table, where the article content type was deleted about 5 minutes after installing (1 month ago).

field_config_instance
'3','1','comment_body','comment','comment_node_article','a:6:{s:5:"label";s:7:"Comment";s:8:"settings";a:2:{s:15:"text_processing";i:1;s:18:"user_register_form";b:0;}s:8:"required";b:1;s:7:"display";a:1:{s:7:"default";a:5:{s:5:"label";s:6:"hidden";s:4:"type";s:12:"text_default";s:6:"weight";i:0;s:8:"settings";a:0:{}s:6:"module";s:4:"text";}}s:6:"widget";a:4:{s:4:"type";s:13:"text_textarea";s:8:"settings";a:1:{s:4:"rows";i:5;}s:6:"weight";i:0;s:6:"module";s:4:"text";}s:11:"description";s:0:"";}','0'

I do not think that any comments were added, so it may be this easy to replicate: install the default profile, delete the article content type and visit the report page, (but I haven't tested this).

Manually deleting this row and flushing the cache appears to resolve the issue.

Just wanted to add some related threads with reports of the same error message in hopes that it helps maintainers figure out where the real problem lies. It seems to be affecting many modules in many contexts when a content or field is deleted:

http://drupal.org/node/1304664
http://drupal.org/node/1334522
http://drupal.org/node/686938
http://drupal.org/node/1332872
http://drupal.org/node/1327038
http://drupal.org/node/1357792

Also, seems like this shouldn't have been changed to Drupal 8 given that it's affecting so many people running D7...

I recently ran into this problem, and here is what I found...

As comment #3 says, manually deleting the row, and flushing the cache seems to fix the problem...but which row to delete?

In the warning message, you want to look for the undefined indexes (in bold):
Notice: Undefined index: comment_node_forum in _field_ui_bundle_admin_path() (line 320 of /path/to/drupal/modules/field_ui/field_ui.module).
Notice: Undefined index: comment_node_forum in field_ui_fields_list() (line 35 of /path/to/drupal/modules/field_ui/field_ui.admin.inc).
Notice: Undefined index: forum in _field_ui_bundle_admin_path() (line 320 of /path/to/drupal/modules/field_ui/field_ui.module).
Notice: Undefined index: forum in field_ui_fields_list() (line 35 of /path/to/drupal/modules/field_ui/field_ui.admin.inc).
Notice: Undefined index: forum in _field_ui_bundle_admin_path() (line 320 of /path/to/drupal/modules/field_ui/field_ui.module).
Notice: Undefined index: forum in field_ui_fields_list() (line 35 of /path/to/drupal/modules/field_ui/field_ui.admin.inc).

Once we found the names of what is being incorrectly indexed, we can use it to delete the offending rows, with an sql command, like this:

delete from field_config_instance where bundle = 'forum' || bundle = 'comment_node_forum';

then flush your drupal cache.

This is what I found works for me. Hopefully it will help someone else save some time to fix the same/similar problem.

I was getting the index error on comment_node_panel and this solution worked completely.

thanks!

The same problem in the report page with enable/disable ubercart product module.

Notice: Undefined index: comment_node_product in _field_ui_bundle_admin_path() (line 325 of /path/to/modules/field_ui/field_ui.module).
Notice: Undefined index: comment_node_product in field_ui_fields_list() (line 35 of /path/to/modules/field_ui/field_ui.admin.inc).
Notice: Undefined index: comment_node_product_kit in _field_ui_bundle_admin_path() (line 325 of /path/to/modules/field_ui/field_ui.module).
Notice: Undefined index: comment_node_product_kit in field_ui_fields_list() (line 35 of /path/to/modules/field_ui/field_ui.admin.inc).
etc...

I had the same issue when I deleted ubercart. Deleting the records from field_config_instance table fixed it.

related: http://drupal.org/node/1558890

Marked #1351506: Disabling or uninstalling a node-type module (e.g. Forum), or removing a node type, results in "undefined index" notices as a duplicate

Recreate this problem as described above. Then note that in database table field_config, the comment_body field is still active and in table field_config_instance the comment_body bundle for the disabled module has not been deleted (because the module was disabled but not uninstalled).

Therefore, a call to field_read_instances() will return the comment_body instances for the disabled module. These bundles are returned up the call stack to field_info_instances() to $instances in field_ui_fields_list().

Meanwhile, field_info_bundles() returns only bundles of enabled modules. This information is returned up the call stack to $bundles in field_ui_fields_list().

Now field_ui_fields_list() iterates over $instances. When the iteration reaches the instance for the disabled module, there is an attempt to reference a field in $bundles which does not exist, because $bundles describes only the enabled modules. Hence the undefined index error.

I just started receiving these errors after disabling and uninstalling the filedepot module on 7.17 when viewing the list of fields. Comment #5 worked great for me.

Thanks for stopping my headache WormFood:-)

#5 fixed the issue for me. I was in the same boat as #6 with comment_node_panel being the offending field...

I ran into this problem too.
I agree with #11. This is what is causing the problem.
I agree with #5. Deleting the field instance solves the problem.

But I think the code should be modified to cope with this situation. I'm using 7.21.

I'm posting a patch for this.

watching for reports of this patch.. to see if it works for others.

I haven't dig into the logic behind this all, so not gonna change the status to RTBC, even though the patch solved the issue for me - which essentially means that all those pesky notices are gone after applying the patch.

Patch looks good but bug fixes need tests so we never see this again.

trying to reproduce any of this via tests and got no success , but here is possibly true bug, that is rising after comment module uninstall

Yeah that is weird, why is comment_node_load running when comment is disabled? Surely that's a static cache somewhere in the test environment?

2 #21 hmmm
Static cache...
So how to catch this via tests? )

Comment is enabled when Forum is enabled. Forum depends on Comment.

I'm uploading 2 patches:
- test only (drupal-check-for-disabled-bundles-1351506-24-test.patch)
- test + the patch at #15 (drupal-check-for-disabled-bundles-1351506-24-complete.patch)

#24 looks good

+1 rtbc

This seems to be reproducible in Drupal 8 too. Not sure why it was moved back to Drupal 7?

Ok, I'll post a patch for Drupal 8.

These are the patches for Drupal8.
- test only (drupal-check-for-disabled-bundles-1351506-d8-30-test.patch)
- test + the patch at #15 slightly modified (drupal-check-for-disabled-bundles-1351506-d8-30-complete.patch)

I forgot to update the status.

status for bot

crosspost

Modules can't be disabled anymore, so moving.

No change notice yet, but here is the issue that swentel raise: #1199946: Disabled modules are broken beyond repair so the "disable" functionality needs to be removed

Note that this patch tried to resolve notices occurring from multiple undetermined paths, although most appear related to disabling. For example I was able to replicate the error by simply removing a content type (comment 3).

Note. If this data is migrated from d7 to d8, then this should still be a d8 issue. Maybe the title should be "Band-aid for preventing errors due to leftover field metadata"?

The patch from comment 24 targets D7.

Patch in #13 works fine on a D7.23 install, ie. the error messages disappear.
#5 only removed 4 out of 6 error messages (two each for unneeded rows in the table).

I had a similar issue with the 'FAQ' module - 'Undefined index: faq in ...'

I was able to remove the error messages by manually creating a content type with the same machine name 'faq' and then deleting it. Of course this doesn't actually fix the root issue...

Ah, this is suggesting that the (primary?) root cause for this are content types that modules define via hook_node_info(). Then these do not get their comment fields removed on uninstall / disable. I think I was getting this after uninstalling, so maybe this is still D8 territory.

Also, I wonder that if the type is edited first before being disabled / removed if the error does not appear. This may obscure the bug for most users.

Marked as duplicates:
#1332872: Line 320 in function _field_ui_bundle_admin_path()
#1357792: Field UI Notice of Undefined Index on line 320

This is still an issue in Drupal 8.

On the field reports page (after uninstalling the Forum module) I see:

Notice: Undefined index: node__comment_forum in Drupal\field_ui\FieldListController->buildRow() (line 119 of core/modules/field_ui/lib/Drupal/field_ui/FieldListController.php).

Attempting to retitle this to reflect all the ways this can apparently happen :)

Well that's weird. I found myself uninstalling Forum again and this time the PHP notice wasn't there.

But still seems like there are various ways to reproduce this in Drupal 8, just not sure of the exact steps.

I replicated on a clean D8 8.x branch installed using standard profile.

Fresh install. No issues initially.

Enable Forums module then uninstall it.

Notice is shown on the Field list report.

Enable, no notice on Field list report

Uninstall, notice on Field list report

Enable and add another field to the comment field settings for the forum. No notices

Uninstall, 2 notices on Field list report. New field still present in listing, no value for the used in cell, comment body field shows with a "Comment settings, ".

Just for fun, I tried what happened when the article content type was deleted.

So with the forum module enabled, I deleted the article content type (comments enabled as per the default install) and the same notice was thrown, this time the comment body was showing ", Comment settings"

Seems fairly replicable, although this is worth a followup issue on seeing why the associated fields from the dependent comment bundle are not being deleted when the parent content type is removed.

#5 fixed for me.

#5 worked for me to fix the issue. Was getting the error for 'comment_node_panel'.

Mine are fixed by simply un-enabling the mods in question, refreshing the "fileds list" page then re-enabling the same mods and once again refreshing the "fileds list" page

This is probably fixed now by #2080823: Create API to discover config entities' soft dependencies and use this to present a confirm form on module uninstall

Using steps from #42 failed to replicate, so back to d7 :)

[edit]
Nearly 2 sec page loads on localhost minimal D8 install :( Is that the new normal?

24: drupal-check-for-disabled-bundles-1351506-15-test.patch queued for re-testing.

24: drupal-check-for-disabled-bundles-1351506-15-complete.patch queued for re-testing.

Tentatively marking #30 rtbtc

#5 worked for me. Thanks to all those who posted thorough explanations.

@mfernea thanks!

#24-2 works fine for me in Drupal 7.27

So shouldn't we get the tests in to Drupal 8 to verify that it's fixed or not? This has been reproduced intermittently (on and off) in Drupal 8 by a couple of us, so it's hard to know for sure it's been fixed, and at the very least there's some missing test coverage.

Seems like the patches in #30 could be changed to be more like #42 (mainly, uninstall rather than disable) and that would mostly do it.

15: drupal-check-for-disabled-bundles-1351506-15.patch queued for re-testing.

Funny bad solotion

Notice: Undefined index: "xyz" in ...
i search "xyz" on db
i see some rows that they are not important and clear them
For
"Notice: Undefined index: in ... bundle ..."
i search "field_config_instance" table on database for empty bundle rows and remove them

For
"PDOException: in field_sql_storage_field_storage_write() (line 494 of"
use this patch to see real peoblem
https://www.drupal.org/node/1929862#comment-7565743

I was able to resolve these messages by going directly into the database in table drupal_field_config_instance and removing the fields that should not be there, they were installed by a module and left when it was uninstalled. You can match the error "undefined index" to the column "bundle" to find the rows to delete and then manually deleted them. I used this query (change placeholder) to find them:

SELECT * FROM cjpDrupal.drupal_field_config_instance where bundle = "<undefinedIndexBundle>";

Thanks, WormFood for #5. Deleting the table entries worked for me on Drupal 7.37.

Also thanks from me WormFood for #5. Worked for me with the faq module which had been uninstalled.

Thumbs up to WormFood for #5 too. It was "image" for me on D7.41.

D8 patch - one line in ForumUninstallTest

Actually, scratch that, wrong patch (route wasn't even available)
Added extra check to make sure the route and field exists.

#5 worked a treat. Thanks

I get the same issue uninstalling and removing migrate related modules (Drupal 7.43).

I have created a custom module extending migrate framework to migrate contents from D6 to D7 (one of the migrate content was image content-type).
All worked fine and after successful migrations I have deregistered all my migrations (via drush) and uninstalled migrate, migrate_d2d modules and my custom modules.

Here the error message come up:

Notice: Undefined index: image in ...

#5 fix the error with:
DELETE FROM field_config_instance WHERE bundle = 'image';

Thank you

@mfernea, the patch in #24 looks good, but I believe there is a missing component.

There are replies on this thread regarding "comment_node_panel" causing an issue. I've investigated this since I encountered the same problem.

The issue has to do with the comment installation process. In comment_modules_enabled, node_type_get_types() is called, which calls _node_types_build().

_node_types_build() accurately sets $type_object->disabled = TRUE for base tables that are not node_content and have an empty $_node_types->types. The problem is the comment module doesn't use this information. It should be checking at the time of installation if disabled = TRUE.

Please see the attached patch and interdiff for review, thanks.

I looked at the patch in #69 and was wondering how the field_create_field($field) gets called to install the 'field_name' => 'comment_body' when the "$info->disabled" argument changes to "$info->enabled" (or what ever its value becomes when changed and is no longer disabled).

I use #69 to isolate a place to provide a temporary solution to implement #5's suggestion in the field_ui.admin.inc - thanks Ron S.
I used the advice from #5 where it said to delete the instance - thanks WormFood.

As a work around, I placed the following code in the field_ui.admin.inc (around line 20). It sets the table "field_config_instance" column "deleted" to "1" (TRUE). The record of the field remains but is marked as deleted.

I have noticed that one of my modules "SimpleLeads" has a problem when enabling and then disabling it's "Simple Ads". I get 10 sets of errors similar to the following (1 for each field installed by "SimpleAds").

Notice: Undefined index: simpleads in _field_ui_bundle_admin_path() (line 335 of /var/www/html/mysite.com/modules/field_ui/field_ui.module).
Notice: Undefined index: simpleads in field_ui_fields_list() (line 35 of /var/www/html/mysite.com/modules/field_ui/field_ui.admin.inc).

I don't know if this is related to the comment_body problem but it has similar notices and disabling the fields by setting their "deleted" columns to true seems to be a good way of handling the problem. I created the "else" case in my code to handle this.

You don't need the "else" case if you only want a work around for the "comment_body" problems.

foreach ($instances as $entity_type => $type_bundles) {
    foreach ($type_bundles as $bundle => $bundle_instances) {
+      // Some fields might belong to bundles that are disabled (which are not
+      // returned by field_info_bundles()).
+      if (!isset($bundles[$entity_type][$bundle])) {
+       //handles uninstalled modules with notices related to comment_body - field uninstalled so no cleanup
+       if (isset($bundle_instances['comment_body'])) {
+         $del_instance = $bundle_instances['comment_body'];
+         $cleanup = FALSE;
+         field_delete_instance($del_instance, $cleanup);
+       }
+       //handles disabled modules with notices - no cleanup modules be designed for cleanup only if uninstalled
+       else {
+         foreach($bundle_instances as $del_instance) {
+           $cleanup = FALSE;
+           field_delete_instance($del_instance, $cleanup);
+         }
+       }
+        continue;
+      }
      foreach ($bundle_instances as $field_name => $instance) {

My experience is limited but I think this works for any occurrence of the field instance not being properly deleted, regardless of the module.

@David_Rothstein

Should this issue be split into two to move things forward?

Forum comment issue creating invalid field config

Patch was set to 8.x with Needs works as D8 tests were requested to prove it is not an issue even though no apparent D8 issues ever been recorded

To move forward
Tests for D8
Tests for D7 and prevention check for field creation. Likely to need more work.

Prevent notices on the Field UI reports page

Again, only reported against Drupal 7.

Pure preventive check if the entity and/or bundle is not defined?

Or is it worth a watchdog() notice for these instead?

We have a system from 2014, and it is showing notices from invalid File entity and Bean fields.

Related issues from cTools (though that doesn't define fields), Panels, Display Suite, likely many others as well as Forum module.

I have added the steps to fix in the summary, please update if anyone see's an issue.

Some of the suggested SQL fixes don't actually limit themselves to the single row, like #59 and #67.

For the second.

Maybe just Missing / Disabled (Entity %entity_type Bundle %bundle)

And log it with watchdog().

And if found, link to a handbook page that explains the advanced solutions for resolving the issue

The ultimate developers solution is to provide the SQL too, but probably not recommended

Invalid field configuration detected for comment_body for the entity comment bundle comment_node_forum. This may be due to a missing or disabled bundle, see URL for more details..

Advanced users only (deleted fields): DELETE FROM {field_config_instance} WHERE bundle = 'comment_node_forum' AND entity_type = 'comment' AND field_name = 'comment_body'

function field_ui_fields_list() {
....
  foreach ($instances as $entity_type => $type_bundles) {
    foreach ($type_bundles as $bundle => $bundle_instances) {
      foreach ($bundle_instances as $field_name => $instance) {
        ....
        // Link to enabled and valid bundles, otherwise indicate an issue and log an error.
        if (isset($bundles[$entity_type][$bundle])) {
          ....
        }
        else {
          $rows[$field_name]['data'][2][] = t('<em>Missing / Disabled (Entity: %entity_type Bundle: %bundle)</em>', array(
            '%entity_type' => $entity_type,
            '%bundle' => $bundle,
          ));
          $instance_sql = "DELETE FROM {field_config_instance} WHERE bundle = '{$bundle}' AND entity_type = '{$entity_type}' AND field_name = '{$field_name}'";
          watchdog('field', '<p>Invalid field configuration detected for %field_name for the entity %entity_type bundle %bundle. This may be due to a missing or disabled bundle, see URL for more details.</p>'
              . '<p>Advanced users only (deleted fields): !sql', array(
            '%field_name' => $field_name,
            '%entity_type' => $entity_type,
            '%bundle' => $bundle,
            '!sql' => $instance_sql,
          ), WATCHDOG_DEBUG);
        }
      }
    }
  }

Hi there I'm getting following error in admin/reports/fields.
Notice: Undefined index: comment_node_filedepot_folder in _field_ui_bundle_admin_path() (line 335 of public_html/modules/field_ui/field_ui.module).
Notice: Undefined index: comment_node_filedepot_folder in field_ui_fields_list() (line 35 of public_html/modules/field_ui/field_ui.admin.inc).
How can i fix this error.
I've reinstall the filedepot module and uninstall again.
but the problem is still there, if i available the module then the error will gone.
otherwise they are still standing there, even i have try from drush by deleteing these field from field_config or field_config_instance tables.
but the problem is still.
please help me to get away from these errors i'm tired now.

1. Enable module (e.g. Forum, Blog, etc .... );
2. Delete Above (Forum, Blog, etc .... ) Fields and Comment Fields;
3. Disable module;
4.Uninstall module;
5.Done

Adding @mimalef70 solution to the summary.

So for drupal 7 this check that the patch adds removes the notices.

      // Some fields might belong to bundles that are disabled (which are not
      // returned by field_info_bundles()).
      if (!isset($bundles[$entity_type][$bundle])) {
        continue;
      }

My only thought is why aren't we pursuing a solution to remove the orphaned config_instances?

The Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

This issue has bounced back and forth from Drupal 7 to Drupal 8 several times!

I tested this on Drupal 10.1.x, standard install using the steps in the Issue Summary and in #42. I was not able to reproduce this problem. The forum module can not be uninstalled until the terms created by the forum are deleted. Once I did that, using the handy link on the uninstall page, I loaded the Field list page without error. Then, it was possible to select Forum and uninstall it. When uninstalling it all the configuration was removed and the Field list page loaded without error.

I did not test this on Drupal 7 so I am moving it back to Drupal 7.