Line 320 in function _field_ui_bundle_admin_path()

Please give more information on how to reproduce this.

I am getting this too, using D 7.9. I tried to add a new content type, and it gave this when I tried to edit its fields (and maybe when I first saved the content type? I can't remember).

I am also using Display Suite, and when I went to the display settings for the content type and added a default Display Suite layout (1-column or whatever, sort of like a mini Panel setting within the content region - in DS, the default is none, which means there's no place to display any fields), the error went away.

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/1351506
http://drupal.org/node/1327038
http://drupal.org/node/1357792

I am having the same problem. How to reproduce? basically install ubercart version 7.x-dev and uninstall it. Afterwards goto admin -> report -> fields

And you will see the error messages. Basically occurs when certain fields are not properly uninstalled.

This becomes a critical error when you enable the filed permissions module - it kills the add/edit content page.

$bundle_info = $bundles[$bundle_name];

Change that line to $bundle_info = !empty($bundles[$bundle_name]) ? $bundles[$bundle_name] : array();

Issue Summary

User gets error notices:

Notice: Undefined index: <undefined_index_name_here> in _field_ui_bundle_admin_path() (line 325 of /***/modules/field_ui/field_ui.module).
Notice: Undefined index: <undefined_index_name_here> in field_ui_fields_list() (line 35 of /***/modules/field_ui/field_ui.admin.inc).

Steps to reproduce this issue

1. Execute SQL command:

insert into field_config_instance ( field_id, field_name, entity_type, bundle, data ) values ( 1, "issue_1332872_field", "node", "issue_1332872_node", 0x613a373a7b733a353a226c6162656c223b733a31323a224f746865722067726f757073223b733a363a22776964676574223b613a343a7b733a363a226d6f64756c65223b733a31353a22656e746974797265666572656e6365223b733a383a2273657474696e6773223b613a333a7b733a31343a226d617463685f6f70657261746f72223b733a383a22434f4e5441494e53223b733a343a2273697a65223b693a36303b733a343a2270617468223b733a303a22223b7d733a343a2274797065223b733a32383a22656e746974797265666572656e63655f6175746f636f6d706c657465223b733a363a22776569676874223b693a33323b7d733a31303a2276696577206d6f646573223b613a323a7b733a343a2266756c6c223b613a333a7b733a353a226c6162656c223b733a343a2246756c6c223b733a343a2274797065223b733a31353a226f675f6c6973745f64656661756c74223b733a31353a22637573746f6d2073657474696e6773223b623a303b7d733a363a22746561736572223b613a333a7b733a353a226c6162656c223b733a363a22546561736572223b733a343a2274797065223b733a31353a226f675f6c6973745f64656661756c74223b733a31353a22637573746f6d2073657474696e6773223b623a303b7d7d733a373a22646973706c6179223b613a313a7b733a373a2264656661756c74223b613a353a7b733a343a2274797065223b733a31353a226f675f6c6973745f64656661756c74223b733a353a226c6162656c223b733a353a2261626f7665223b733a383a2273657474696e6773223b613a303a7b7d733a363a226d6f64756c65223b733a353a226f675f7569223b733a363a22776569676874223b693a323b7d7d733a383a2273657474696e6773223b613a313a7b733a31383a22757365725f72656769737465725f666f726d223b623a303b7d733a383a227265717569726564223b623a303b733a31313a226465736372697074696f6e223b733a303a22223b7d ) ;

2.Clear cache
3.Go to /admin/reports/fields

Cause

This is probably caused by an incomplete uninstall and leaving orphaned entries in table {field_config_instance}.

Temporary Solution

I can find orpahed entries using SQL command:
SELECT * FROM `field_config_instance` as a WHERE bundle LIKE <undefined_index_name_here>;
Removing of the table entry found above and clearing the cache removed the notice messages for me.

Environment

Drupal 7.12

What needs review:
I personally don't think such database inconsistencies caused by direct sql database manipulations or non-clean uninstall of contributed modules be handled in Core.

Should #5 be enough to close this issue as won't fix ?
Should users fill a new issue for each module causing these notices ? If so, how will users know which module to blame ?

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