Undefined index _field_info_prepare_instance_widget

hmm.. what am i overlook.. $field_type is never used in this function

we can remove

  $field_type = field_info_field_types($field['type']);

It doesn't look to me like $field_type is unused. Here is the full snippet:

  $field_type = field_info_field_types($field['type']);

  // Fill in default values.
  $widget += array(
    'type' => $field_type['default_widget'],
    'settings' => array(),
    'weight' => 0,
  );

So is there an actual bug here? If the PHP notice only showed up on a site that upgraded from 7.0-beta2, then it doesn't sound like a bug because that upgrade path is not officially supported. I think you are lucky if all you get is a PHP notice or two :)

Plus, if the problem no longer exists anyway, should we close this issue?

haha. I'm think into wrong way, stupid enough.

ok. the problem is it haven't check $widget array keys.

$widget['module'] = $widget_type['module'];

we could see lots code inside Drupal missing this step, eg
http://drupal.org/node/1002380

I dont know what happened but i get this when i go to manage fields. It also doesnt let me add any text fields even exisiting ones. When i go to add content, the body field is missing.

    * Notice: Undefined index: module in _field_info_prepare_instance_widget() (line 385 of C:\Program Files\xampp\htdocs\town\modules\field\field.info.inc).
    * Notice: Undefined index: module in _field_info_prepare_instance_display() (line 353 of C:\Program Files\xampp\htdocs\town\modules\field\field.info.inc).
    * Notice: Undefined index: module in _field_info_prepare_instance_widget() (line 385 of C:\Program Files\xampp\htdocs\town\modules\field\field.info.inc).
    * Notice: Undefined index: module in _field_info_prepare_instance_display() (line 353 of C:\Program Files\xampp\htdocs\town\modules\field\field.info.inc).
    * Notice: Undefined index: module in _field_info_prepare_instance_widget() (line 385 of C:\Program Files\xampp\htdocs\town\modules\field\field.info.inc).
    * Notice: Undefined index: module in _field_info_prepare_instance_display() (line 353 of C:\Program Files\xampp\htdocs\town\modules\field\field.info.inc).
    * Notice: Undefined index: module in _field_info_prepare_instance_widget() (line 385 of C:\Program Files\xampp\htdocs\town\modules\field\field.info.inc).
    * Notice: Undefined index: module in _field_info_prepare_instance_display() (line 353 of C:\Program Files\xampp\htdocs\town\modules\field\field.info.inc).
    * Notice: Undefined index: module in _field_info_prepare_instance_widget() (line 385 of C:\Program Files\xampp\htdocs\town\modules\field\field.info.inc).
    * Notice: Undefined index: module in _field_info_prepare_instance_display() (line 353 of C:\Program Files\xampp\htdocs\town\modules\field\field.info.inc).
    * Notice: Undefined index: module in _field_info_prepare_instance_widget() (line 385 of C:\Program Files\xampp\htdocs\town\modules\field\field.info.inc).
    * Notice: Undefined index: module in _field_info_prepare_instance_display() (line 353 of C:\Program Files\xampp\htdocs\town\modules\field\field.info.inc).
    * Notice: Undefined index: module in _field_info_prepare_instance_widget() (line 385 of C:\Program Files\xampp\htdocs\town\modules\field\field.info.inc).
    * Notice: Undefined index: module in _field_info_prepare_instance_display() (line 353 of C:\Program Files\xampp\htdocs\town\modules\field\field.info.inc).
    * Notice: Undefined index: module in _field_info_prepare_instance_widget() (line 385 of C:\Program Files\xampp\htdocs\town\modules\field\field.info.inc).
    * Notice: Undefined index: module in _field_info_prepare_instance_display() (line 353 of C:\Program Files\xampp\htdocs\town\modules\field\field.info.inc).
    * Notice: Undefined index: module in _field_info_prepare_instance_widget() (line 385 of C:\Program Files\xampp\htdocs\town\modules\field\field.info.inc).
    * Notice: Undefined index: module in _field_info_prepare_instance_display() (line 353 of C:\Program Files\xampp\htdocs\town\modules\field\field.info.inc).
    * Notice: Undefined index: module in _field_info_prepare_instance_widget() (line 385 of C:\Program Files\xampp\htdocs\town\modules\field\field.info.inc).
    * Notice: Undefined index: module in _field_info_prepare_instance_display() (line 353 of C:\Program Files\xampp\htdocs\town\modules\field\field.info.inc).
    * Notice: Undefined index: module in _field_info_prepare_instance_widget() (line 385 of C:\Program Files\xampp\htdocs\town\modules\field\field.info.inc).
    * Notice: Undefined index: module in _field_info_prepare_instance_display() (line 353 of C:\Program Files\xampp\htdocs\town\modules\field\field.info.inc).
    * Notice: Undefined index: text_long in field_ui_existing_field_options() (line 1490 of C:\Program Files\xampp\htdocs\town\modules\field_ui\field_ui.admin.inc).
    * Notice: Undefined index: text_long in field_ui_existing_field_options() (line 1490 of C:\Program Files\xampp\htdocs\town\modules\field_ui\field_ui.admin.inc).
    * Notice: Undefined index: text_long in field_ui_existing_field_options() (line 1490 of C:\Program Files\xampp\htdocs\town\modules\field_ui\field_ui.admin.inc).
    * Notice: Undefined index: text_long in field_ui_existing_field_options() (line 1490 of C:\Program Files\xampp\htdocs\town\modules\field_ui\field_ui.admin.inc).
    * Notice: Undefined index: text_long in field_ui_existing_field_options() (line 1490 of C:\Program Files\xampp\htdocs\town\modules\field_ui\field_ui.admin.inc).

I'm seeing this same problem in v.7.0. Not an upgrade, a fresh install from 7.0. It does not appear to be a conflict with any other module. I can turn every contrib and most core modules off, but the error is still thrown.

Just one of several "undefined index" errors. Custom fields don't function as a result.

@tinny & @cdesautels - If you post to a closed issue you should reopen it; otherwise it's unlikely anyone monitoring the issue queue will see it.

I'm having the same first two error messages that tinny reports, on a site that was originally installed at 7.0, so core has never been upgraded. I have not done enough testing to determine whether this might be related to contrib or core, but I'll post anything I discover here.

@mcfilms - In my case this is on a D7 site that was installed after D7 was officially released, so all three of those modules got installed the second week of January. It's certainly possible that I briefly had Views installed without one of the others, but they're all up to date now.

Would you recommend completely uninstalling and reinstalling Views? Or all three modules? The error has persisted for a long time so I'd love to get it fixed.

I'm working from a clean install of 7.0 and I turned off everything I could. All I left on was a few fields module. Just enough to support a few custom fields and the UI. And I still got the error message.

Same here after updating to new views (incl ctools, date) - all modules are up to date (dev versions):

Notice: Undefined index: module in _field_info_prepare_instance_widget() (Zeile 385 von /www/htdocs/w005aa45/schaffa-neu/modules/field/field.info.inc).
Notice: Undefined index: module in _field_info_prepare_instance_display() (Zeile 353 von /www/htdocs/w005aa45/schaffa-neu/modules/field/field.info.inc).

Think the solution is to rebuild views and reset the fields. Hopefully this will be the solution.

This requires additional debug info.

People facing that bug, please replace the _field_info_prepare_instance_display() function in modules/field/field.info.inc with the following, and post back the resulting debug messages (preferably in attached txt files, please) :

function _field_info_prepare_instance_display($field, $display) {
  $field_type = field_info_field_types($field['type']);

  $orig_display = $display; // <-- new

  // Fill in default values.
  $display += array(
    'label' => 'above', 
    'type' => $field_type['default_formatter'], 
    'settings' => array(), 
    'weight' => 0,
  );
  if ($display['type'] != 'hidden') {
    $formatter_type = field_info_formatter_types($display['type']);

    if (empty($formatter_type['module'])) { // <-- new
      debug($field['field_name'], 'field name');
      debug($field['type'], 'field type');
      debug($orig_display['type'], 'incoming formatter');
      debug($display['type'], 'computed formatter');
    }

    // Fallback to default formatter if formatter type is not available.
    if (!$formatter_type) {
      $display['type'] = $field_type['default_formatter'];
      $formatter_type = field_info_formatter_types($display['type']);
    }
    $display['module'] = $formatter_type['module'];
    // Fill in default settings for the formatter.
    $display['settings'] += field_info_formatter_settings($display['type']);
  }

  return $display;
}

Does anyone know how to trigger this? I upgraded all the modules on my site to the latest versions, ran update.php successfully, hit the homepage, and got the same two errors. So then I found the updates to this thread, modified field.info.inc per yched's instructions, and now I can't get it to throw the error again. Does it only happen after you upgrade Views/CTools? (per #13, and consistent with my my recent experience getting this error.)

I did get the following error when I visited the Field List page (trying to trigger it per #6), but I don't think this is what yched is looking for:
Notice: Undefined index: group in field_ui_fields_list() (line 24 of /home/user/public_html/hurleyschool/modules/field_ui/field_ui.admin.inc).

I'd love to help troubleshoot so if anyone knows how to trigger it let me know and I'll post the debug info.

Update - got it! Cleared the cache. Debug info is attached for yched and here for anyone else who's interested:

Debug: field name:
'group_audience'
in _field_info_prepare_instance_display() (line 352 of /home/user/public_html/hurleyschool/modules/field/field.info.inc).
Debug: field type:
'group'
in _field_info_prepare_instance_display() (line 353 of /home/user/public_html/hurleyschool/modules/field/field.info.inc).
Debug: incoming formatter:
'og_list_default'
in _field_info_prepare_instance_display() (line 354 of /home/user/public_html/hurleyschool/modules/field/field.info.inc).
Debug: computed formatter:
'og_list_default'
in _field_info_prepare_instance_display() (line 355 of /home/user/public_html/hurleyschool/modules/field/field.info.inc).

Looks like it's mad at OG, which I have installed but not enabled.

@BrightBold: thanks for the info. What does "OG, which I have installed but not enabled" exactly mean ?
You enabled it and then disabled it ?
You enabled it and then disabled it and then uninstalled it (uninstall as in "using the 'uninstall' tab on the modules administration page") ?

I'm still interested in similar debug reports from other people in the thread. See comment #14.

Well, good question. I believe I must have enabled then disabled it. I know I didn't uninstall it. If I had put it in the modules folder but never enabled it, then there wouldn't be OG tables in the database (right?) and there are, so that must mean that I had it enabled briefly. It's currently disabled but not uninstalled.

I wanted to see what happened if I unistalled and reinstalled OG, since I'm finding many of my Drupal 7 problems result from having had a development version of a module installed at one time, and while OG was already stable when I first installed it, Entity API, on which it's dependent, was not. So I was thinking reinstalling OG with a more stable version of Entity might fix it up.

After uninstalling all the OG sub-modules, I uninstalled the main OG module and got the following error:
PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'tremon5_hurleydru.field_data_group_audience' doesn't exist: UPDATE {field_data_group_audience} SET deleted=:db_update_placeholder_0 WHERE (entity_type = :db_condition_placeholder_0) AND (bundle = :db_condition_placeholder_1) ; Array ( [:db_update_placeholder_0] => 1 [:db_condition_placeholder_0] => user [:db_condition_placeholder_1] => user ) in field_sql_storage_field_storage_delete_instance() (line 629 of /home/tremon5/public_html/hurleyschool/modules/field/modules/field_sql_storage/field_sql_storage.module).

I manually dropped the OG tables and OG rows from the System table, and deleted the module. However Schema module still reports missing db tables:

MISSING (2)
Tables in the schema that are not present in the database:
Hide field_sql_storage

• field_data_group_audience
• field_revision_group_audience

Apparently there are issues with OG uninstalling properly: #997714: OG does not clean up after itself on uninstall. I'm not clear on how to get rid of tables in the schema (or whether this is really a problem, given that eventually I plan to reinstall OG, but I'm concerned it may not create the table properly if the schema thinks the table's already there.)

So, sorry to stray so far from the original issue — I just wasn't sure how much of this was helpful. (Obviously OG issues need to be handled in the OG queue.) It will be interesting to see what other people report with the new debugging information. It was certainly helpful to get clearer information from the error message — so I could track down which module this was (I think — I guess Entity could be the root cause?) related to in my case.

I am getting this same error, after migrating a local site to the server. I have never loaded OG this drupal 7 install so it shouldn't have anything to do with that.

Here are the things I have attempted after surfing these forums.

1. Updated the following modules up to their most recent dev versions: ctools, views, and entity.
2. Uninstalled Locale and Translation
3. Cleared Cache a bunch of times
4. Ran Update.php but nothing ever needed updating.

Notice: Undefined index: module in _field_info_prepare_instance_widget() (line 392 of drupal/modules/field/field.info.inc).
Notice: Undefined index: module in _field_info_prepare_instance_display() (line 360 of drupal/modules/field/field.info.inc).
Notice: Undefined index: module in _field_info_prepare_instance_widget() (line 392 of drupal/modules/field/field.info.inc).
Notice: Undefined index: module in _field_info_prepare_instance_display() (line 360 of drupal/modules/field/field.info.inc).
Notice: Undefined index: module in _field_info_prepare_instance_widget() (line 392 of drupal/modules/field/field.info.inc).
Notice: Undefined index: module in _field_info_prepare_instance_display() (line 360 of drupal/modules/field/field.info.inc).
Status message
Debug: field name:
'field_authors'
in _field_info_prepare_instance_display() (line 349 of drupal/modules/field/field.info.inc).
Debug: field type:
'node_reference'
in _field_info_prepare_instance_display() (line 350 of drupal/modules/field/field.info.inc).
Debug: incoming formatter:
'node_reference_default'
in _field_info_prepare_instance_display() (line 351 of drupal/modules/field/field.info.inc).
Debug: computed formatter:
'node_reference_default'
in _field_info_prepare_instance_display() (line 352 of drupal/modules/field/field.info.inc).
Debug: field name:
'field_editors'
in _field_info_prepare_instance_display() (line 349 of drupal/modules/field/field.info.inc).
Debug: field type:
'node_reference'
in _field_info_prepare_instance_display() (line 350 of drupal/modules/field/field.info.inc).
Debug: incoming formatter:
'node_reference_default'
in _field_info_prepare_instance_display() (line 351 of drupal/modules/field/field.info.inc).
Debug: computed formatter:
'node_reference_default'
in _field_info_prepare_instance_display() (line 352 of drupal/modules/field/field.info.inc).
Debug: field name:
'field_articles'
in _field_info_prepare_instance_display() (line 349 of drupal/modules/field/field.info.inc).
Debug: field type:
'node_reference'
in _field_info_prepare_instance_display() (line 350 of drupal/modules/field/field.info.inc).
Debug: incoming formatter:
'node_reference_node'
in _field_info_prepare_instance_display() (line 351 of drupal/modules/field/field.info.inc).
Debug: computed formatter:
'node_reference_node'
in _field_info_prepare_instance_display() (line 352 of drupal/modules/field/field.info.inc).

btw. Deleting and readding views fields solved it some weeks ago.

I finally encountered this myself. Happened after having to manually disable a field-type module directly in the system table. In such cases, hook_modules_disabled() doesn't run, and the field does not get marked as inactive. Same thing would happen if the module files suddenly disappear, BTW.

Such cases could be caught at run time by adding extra checks in _field_info_collate_fields() (patch attached for the record, intentionally not set to 'needs review'), but I'd really prefer not to add "double-check" cruft code in there, especially to handle setups that are broken after some non-regular manipulations.

I'd much rather have a way to easily re-check the state of enabled / disabled modules and udpate the list of inactive fields accordingly. Right now, field_modules_disabled() is the only chance we get to mark fields as inactive, and if this gets skipped for some reason, there's no easy refresh.

'Cache clear all' seems a good spot for this. However, the only hook fired in drupal_flush_all_caches() is hook_flush_caches(), which is supposed to return a list of cache tables, and is not really intended to execute actual code.

Thoughts ?

Hi
Joining the club. D6.22 upgraded to D7.2. Got a few of these on the site. No poking around in the system table and disabling fields/widgets have been performed. With patch #23 installed, Notice: Undefined index: module in _field_info_prepare_instance_display() (line 357 of /drupal-7.2/modules/field/field.info.inc). on admin/structure/types/manage/yout_content_type/fields.

Reading up on this issue and if I got it right, It is caused by a missing widget that are still used by one or more of the content types?

yched, any tips how we should move this forward, and/or work around it?

Best regards
Steinmb

The current approach to solve #943772: field_delete_field() and others fail for inactive fields includes the fix I proposed in #23 above - rechecking the status of active / inactive fields on cache clear. This issue will therefore be fixed as a side effect over there.

Leaving open for now, though.

Thanks, I'll hop in, and join the discussion. I'll hope feedback related to this issues could be posted in to that issue also.

Subscribe.

Subscribing, as I have the same issue with these notices:

Notice: Undefined index: module in _field_info_prepare_instance_widget() (line 382 of /home/user/Public/Sites/drupal/modules/field/field.info.inc).
Notice: Undefined index: module in _field_info_prepare_instance_display() (line 350 of /home/user/Public/Sites/drupal/modules/field/field.info.inc).
Notice: Undefined index: module in _field_info_prepare_instance_widget() (line 382 of /home/user/Public/Sites/drupal/modules/field/field.info.inc).
Notice: Undefined index: module in _field_info_prepare_instance_display() (line 350 of /home/user/Public/Sites/drupal/modules/field/field.info.inc).

I have the same as #29 in all field management screens, and in some more places (for example in Modules list just after disabling any module).

And also

Notice: Undefined index: required in entity_metadata_field_default_property_callback() (line 64 from ..../sites/all/modules/entity/modules/field.info.inc).
between them (fifth notice, and then 4 notices again as #29)

This happens when modules defining field types that are in use on the site are unreacheable, but the corresponding fields have not been marked 'inactive' - which happens in hook_modules_disabled().

Thus the only way I've personally been able to reproduce those warnings is by removing the code of the modules from the server, or manually setting their 'status' column to 0 in the 'system' db table - without properly disabling them (through the modules admin page or through "drush dis").

For people reporting those warnings : we need more detailed reports.
Please apply the debug patch attached below, clear your caches if needed, and note the modules indicated in the debug messages ("Unknown field type: X (module: Y)"). We need reports on how those modules got out of your system.
If it's through one of the (unsupported) methods mentioned above, then it's not a bug, please don't report it. You can fix your setup by
- running the following query : UPDATE field_config SET active = 0 WHERE module = "THE_MODULE_NAME" (replace with the right module name, of course),
- and clearing your caches.

Until then, marking as "needs more info".

Thanks for this response.

I had uninstalled og, however it left one field as active which was causing the problem.

I found this by running the following query:

select distinct module from `field_config` where active > 0

When I noticed og was the problem, I ran the following:

UPDATE `field_config` set active = 0 where module = 'og'

Seems like problem is solved. Thanks.

I've been keeping my eye on this issue because I too had installed Organic Groups and could not disable it so I removed it via ftp but still received errors while working in: Content types/new content/manage fields and comment fields in the #overlay panel. The attached is my documentation of the error reports as I have tried to apply the supplied patch in #31 and updates, including post #32 per thomsol and update.php.

n/a

just upgraded to 7.7 and I'm having the "body field disappearing" issue myself. All my modules are up to date... I had the same

Notice: Undefined index: module in _field_info_prepare_instance_widget() (line 382 of /var/www/gisele-drupal/modules/field/field.info.inc).
Notice: Undefined index: module in _field_info_prepare_instance_display() (line 350 of /var/www/gisele-drupal/modules/field/field.info.inc).
Notice: Undefined index: module in _field_info_prepare_instance_widget() (line 382 of /var/www/gisele-drupal/modules/field/field.info.inc).
[…]

message some people talked about before but now they're gone... the body field is still gone though

+1
Updated a simple site, stripped bare of all but core, from 6.22 to 7.7 and the recurrent warning is
"Notice: Undefined index: module in _field_info_prepare_instance_widget() (line 382 of /home3/daquella/public_html/streetlanguage/modules/field/field.info.inc)." It shows up after running update.php, and then when visiting the modules page. In addition, body content fields are empty in all but 2 out of 122 existing nodes... which is actually the serious part.

I restored the site back to 6.22 and made sure, to my knowledge, that all was clean, lean and ready, upgraded again to 7.7 and the same happened again.

This was a site created in 6 and all the version 6 updates ran fine until this upgrade. A couple of days before I updated another simple site that I have had running since maybe drupal 4x? Its upgrade from 6.22 to 7.7 ran smoothly and without any of these issues so I'm a bit confused now.

Until I can figure it out I guess I'll restore the working 6.22 version of the faulty site and run with it...

Screenshot of the mentioned error/warning attached.

Cheers

Pls. read #31, give it a run and report back your findings.

I applied the patch from #31 and this is what I got:

  * Caches cleared.
  * Debug:

  'Unknown field type:  (module: taxonomy)'
  in _field_info_prepare_field() (line 260 of [...]\modules\field\field.info.inc).

hth

EDIT:
Temporarily activating the Taxonomy module seems to have solved the issue.

Notice : Undefined index : module dans _field_info_prepare_instance_widget() (ligne 382 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Notice : Undefined index : module dans _field_info_prepare_instance_display() (ligne 350 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Notice : Undefined index : location dans field_ui_existing_field_options() (ligne 1493 dans C:\wamp\www\drupal7\modules\field_ui\field_ui.admin.inc).

Result with patch :

Debug : field name:

'field_emplacement'

dans _field_info_prepare_instance_display() (ligne 375 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : field type:

'location'

dans _field_info_prepare_instance_display() (ligne 376 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : incoming formatter:

'location_default'

dans _field_info_prepare_instance_display() (ligne 377 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : computed formatter:

'location_default'

dans _field_info_prepare_instance_display() (ligne 378 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : field name:

'field_photos_facade'

dans _field_info_prepare_instance_display() (ligne 375 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : field type:

'media'

dans _field_info_prepare_instance_display() (ligne 376 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : incoming formatter:

'media_large'

dans _field_info_prepare_instance_display() (ligne 377 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : computed formatter:

'media_large'

dans _field_info_prepare_instance_display() (ligne 378 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : field name:

'field_photos_hall'

dans _field_info_prepare_instance_display() (ligne 375 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : field type:

'media'

dans _field_info_prepare_instance_display() (ligne 376 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : incoming formatter:

'media_large'

dans _field_info_prepare_instance_display() (ligne 377 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : computed formatter:

'media_large'

dans _field_info_prepare_instance_display() (ligne 378 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : field name:

'field_photos_chambres'

dans _field_info_prepare_instance_display() (ligne 375 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : field type:

'media'

dans _field_info_prepare_instance_display() (ligne 376 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : incoming formatter:

'media_large'

dans _field_info_prepare_instance_display() (ligne 377 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : computed formatter:

'media_large'

dans _field_info_prepare_instance_display() (ligne 378 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : field name:

'field_photos_piscine'

dans _field_info_prepare_instance_display() (ligne 375 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : field type:

'media'

dans _field_info_prepare_instance_display() (ligne 376 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : incoming formatter:

'media_large'

dans _field_info_prepare_instance_display() (ligne 377 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : computed formatter:

'media_large'

dans _field_info_prepare_instance_display() (ligne 378 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : field name:

'field_photos_restaurant'

dans _field_info_prepare_instance_display() (ligne 375 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : field type:

'media'

dans _field_info_prepare_instance_display() (ligne 376 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : incoming formatter:

'media_large'

dans _field_info_prepare_instance_display() (ligne 377 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : computed formatter:

'media_large'

dans _field_info_prepare_instance_display() (ligne 378 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : field name:

'field_photos_bar'

dans _field_info_prepare_instance_display() (ligne 375 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : field type:

'media'

dans _field_info_prepare_instance_display() (ligne 376 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : incoming formatter:

'media_large'

dans _field_info_prepare_instance_display() (ligne 377 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : computed formatter:

'media_large'

dans _field_info_prepare_instance_display() (ligne 378 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : field name:

'field_photos_bien_etre'

dans _field_info_prepare_instance_display() (ligne 375 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : field type:

'media'

dans _field_info_prepare_instance_display() (ligne 376 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : incoming formatter:

'media_large'

dans _field_info_prepare_instance_display() (ligne 377 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : computed formatter:

'media_large'

dans _field_info_prepare_instance_display() (ligne 378 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : field name:

'field_photos_diverses'

dans _field_info_prepare_instance_display() (ligne 375 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : field type:

'media'

dans _field_info_prepare_instance_display() (ligne 376 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : incoming formatter:

'media_large'

dans _field_info_prepare_instance_display() (ligne 377 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : computed formatter:

'media_large'

dans _field_info_prepare_instance_display() (ligne 378 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : field name:

'field_video'

dans _field_info_prepare_instance_display() (ligne 375 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : field type:

'media'

dans _field_info_prepare_instance_display() (ligne 376 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : incoming formatter:

'media_large'

dans _field_info_prepare_instance_display() (ligne 377 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : computed formatter:

'media_large'

dans _field_info_prepare_instance_display() (ligne 378 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : field name:

'field_emplacement'

dans _field_info_prepare_instance_display() (ligne 375 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : field type:

'location'

dans _field_info_prepare_instance_display() (ligne 376 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : incoming formatter:

'location_default'

dans _field_info_prepare_instance_display() (ligne 377 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : computed formatter:

'location_default'

dans _field_info_prepare_instance_display() (ligne 378 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : field name:

'field_photos_facade'

dans _field_info_prepare_instance_display() (ligne 375 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : field type:

'media'

dans _field_info_prepare_instance_display() (ligne 376 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : incoming formatter:

'media_large'

dans _field_info_prepare_instance_display() (ligne 377 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : computed formatter:

'media_large'

dans _field_info_prepare_instance_display() (ligne 378 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : field name:

'field_photos_hall'

dans _field_info_prepare_instance_display() (ligne 375 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : field type:

'media'

dans _field_info_prepare_instance_display() (ligne 376 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : incoming formatter:

'media_large'

dans _field_info_prepare_instance_display() (ligne 377 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : computed formatter:

'media_large'

dans _field_info_prepare_instance_display() (ligne 378 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : field name:

'field_photos_chambres'

dans _field_info_prepare_instance_display() (ligne 375 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : field type:

'media'

dans _field_info_prepare_instance_display() (ligne 376 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : incoming formatter:

'media_large'

dans _field_info_prepare_instance_display() (ligne 377 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : computed formatter:

'media_large'

dans _field_info_prepare_instance_display() (ligne 378 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : field name:

'field_photos_piscine'

dans _field_info_prepare_instance_display() (ligne 375 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : field type:

'media'

dans _field_info_prepare_instance_display() (ligne 376 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : incoming formatter:

'media_large'

dans _field_info_prepare_instance_display() (ligne 377 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : computed formatter:

'media_large'

dans _field_info_prepare_instance_display() (ligne 378 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : field name:

'field_photos_restaurant'

dans _field_info_prepare_instance_display() (ligne 375 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : field type:

'media'

dans _field_info_prepare_instance_display() (ligne 376 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : incoming formatter:

'media_large'

dans _field_info_prepare_instance_display() (ligne 377 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : computed formatter:

'media_large'

dans _field_info_prepare_instance_display() (ligne 378 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : field name:

'field_photos_bar'

dans _field_info_prepare_instance_display() (ligne 375 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : field type:

'media'

dans _field_info_prepare_instance_display() (ligne 376 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : incoming formatter:

'media_large'

dans _field_info_prepare_instance_display() (ligne 377 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : computed formatter:

'media_large'

dans _field_info_prepare_instance_display() (ligne 378 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : field name:

'field_photos_bien_etre'

dans _field_info_prepare_instance_display() (ligne 375 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : field type:

'media'

dans _field_info_prepare_instance_display() (ligne 376 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : incoming formatter:

'media_large'

dans _field_info_prepare_instance_display() (ligne 377 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : computed formatter:

'media_large'

dans _field_info_prepare_instance_display() (ligne 378 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : field name:

'field_photos_diverses'

dans _field_info_prepare_instance_display() (ligne 375 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : field type:

'media'

dans _field_info_prepare_instance_display() (ligne 376 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : incoming formatter:

'media_large'

dans _field_info_prepare_instance_display() (ligne 377 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : computed formatter:

'media_large'

dans _field_info_prepare_instance_display() (ligne 378 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : field name:

'field_video'

dans _field_info_prepare_instance_display() (ligne 375 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : field type:

'media'

dans _field_info_prepare_instance_display() (ligne 376 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : incoming formatter:

'media_large'

dans _field_info_prepare_instance_display() (ligne 377 dans C:\wamp\www\drupal7\modules\field\field.info.inc).
Debug : computed formatter:

'media_large'

dans _field_info_prepare_instance_display() (ligne 378 dans C:\wamp\www\drupal7\modules\field\field.info.inc).

Should be fixed in 7.8 now after #943772: field_delete_field() and others fail for inactive fields got in.
A cache clear should make the errors disappear.

Have to reopen this, unfortunately.

I used custom fields and custom node types extensively since D7.0, but faced this problem only in D7.8, where it should be fixed. After that patch from #31 was applied, it's output and initial error messages are in attached TXT files. I didn't disable any field-providing modules before this error arise, so there should be no "orphan" fields. But, just in case, I tried to execute such SQL queries:
UPDATE field_config SET active = 0 WHERE module = "link";
UPDATE field_config SET active = 0 WHERE module = "og";
1 and 4 rows were affected accordingly, but nothing has changed.

It should be noted, that this message appears when I try to add new field or content type, but if I try to add existing field, everything runs smoothly.

Would be glad to provide any additional information.

Afraid I'm getting it also, with D7.8.

Adam, future investigation showed, that this issue was caused by conflict of two contributed modules (Entity Reference and Field collection) in my case: http://drupal.org/node/1292090
Would be interesting to know, is it the same reason on your site? I didn't closed this (core) issue yet, as far it is not clear, why did that conflict appeared, maybe changes in core between D7.7 and D7.8 caused it somehow?

Thanks for the feedback, Renat. I am using those two modules, so it does appear to be related.

got it as well, and posted some debugging info in the field_collection issue queue

http://drupal.org/node/1292090#comment-5107786

I'm not using Field collection, and still run into these. We should therefore keep that as a separate issue.

Had the same. Am using both field collection and entity reference. Have just dropped entity reference and the errors have gone.

Just updated to 7.x-1.0-beta3 of entity reference and all is ok.

I saw this same problem in d7 and updated entity reference to 7.x-1.0-rc1 and it went away.

While working on a fresh install of the latest Commons-7.x-3.x-dev version and adding in additional modules, I'd get the same error with any/every scenario - from forgetting a dependency, to rollbacks and/or uninstalls. I came across a similar error report with filefield_paths (http://drupal.org/node/1601104), and it prompted a look at the field.info.inc line#386 to see if the same type of fix could apply.

A change from:
$widget['module'] = $widget_type['module'];
to:
$widget['module'] = isset($widget_type['module']) ? $widget_type['module'] : NULL;
seems to have quieted the notice messages.

Commons dev shows the Drupal base at 7.15, and this may have been discovered/fixed in the standard D7 core... so this is more informational for someone in a similar situation

Just went from 7.14 to 7.15 and got the same message. Followed #51 and error seemed to go away.

@yched To recreate the problem, you can run my install profile which are using Drupal 7.15 with features exported by the most recent features module.

drush make https://raw.github.com/vih/vih.dk-deploy/master/vih_dk.build /path/to/localhost/vih_dk_build

After going through the install process the error is present both in the installation, and when you view a node afterwards.

@HumanTex - thanks that helped me. I dont seem to have other issues connected with that. The stupid mssge disappered once for all.
:beer:

The edit to /modules/field/field.info.inc line 386 (D7.15) appears to have prevented the report of the error though I do not know about the ramifications of that change, just glad not to have to scroll through pages of the same error notice on most admin pages. yay. Thanks HumanTex.

I'd reported this after updating File (Field) Paths, unsure where the actual issue lies, in that module or in core:
http://drupal.org/node/1724170#comment-6448950

I've created a patch following #51 comment.

Just setting this to "Needs review".

@HumanTex, it worked for me
i had to change this lines in field.info.inc to get rid of the errors:

in function _field_info_prepare_instance_display($field, $display)

//$display['module'] = $formatter_type['module'];
$display['module'] = isset($formatter_type['module']) ? $formatter_type['module'] : NULL;

in function _field_info_prepare_instance_widget($field, $widget)

// $widget['module'] = $widget_type['module'];
$widget['module'] = isset($widget_type['module']) ? $widget_type['module'] : NULL;

@likes_drupal... your '$formatter_' change seems reasonable (in hind-site for me, at least) if it's doing what it appears to be via the if ($display['type'] != 'hidden') check routine it's part of. I installed Clean Module List very early in my process of bulding, so my initial assumption is that any errors associated with the '$formatter_' stuff that you might have seen would get bypassed/suppressed in my case - but for now - that's just a wild guess on my part.

So, in order to see if there's even more happening along the same lines (and even deeper)... I added your line change, enabled a new module, and my only persistent error message as of now, is: Warning: Invalid argument supplied for foreach() in element_children() (line 6300 of C:\xampp\htdocs\commons73dev\includes\common.inc).

Looking at lines 6300-6308, with my inserted comment:

  foreach ($elements as $key => $value) {
    if ($key === '' || $key[0] !== '#') {
      $children[$key] = $value;
      // could it be?... if (is_array($value) && isset($value['#weight']) ? $value['#weight']  : NULL) {
      if (is_array($value) && isset($value['#weight'])) {
        $sortable = TRUE;
      }
    }
  }

@emorency... I don't have anything to offer on why the patch failed with such a simple change. I am not by any means an expert in Drupal core and its codeflow , but... some things are lining up in a pattern that seems to stem from the core with the potential to impact any contribs that follow. These lines from my remaining warning are pointing to yet another check routine - this time for weighting.

I'll assume the idea of limiting (from previous Drupal versions) what might seem to be unnecessary null checking routines for every instance of a single/array value (for not only nulls, but default values, presence or absence of 'xyz', or whatever...) is to reduce overall bloat, code complexity, resource/threads/memory/handles/cache 'grabs' of any kind, etc. The flip side CAN be (not WILL be), that any contrib has to be much more precise in matching the no-longer-null-checked expectations being set by core for every possible checked value - AND - in what order it's processed - AND - if it's expected to have a preset/default value at all - AND - if it will pass any check routine during both it's installing state as well as its operating state. It's difficult to imagine anyone ever coding a crystal ball function for core that's always accurate in predicting all possibilities and combinations under every operating state. It might be a pretty big leap to think that all conceivable check routines could ever operate correctly from the core side without a mandate of specific values/settings from every contribution during installs, without any nulls whatsoever.

My own personal opinion is that there's no way for any contrib author to foretell what any end-user will want or need for every value when they are presented as a valid choice. I don't think it's unreasonable to expect there will always be some nulls the very instant a module/theme/feature is enabled - even if it/they may not stay a null soon after. Along with that, if the process order of whatever checking routine(s) won't allow for those unknowns or currently missing values, then they might be more effective if they are delayed in running until after the first time setup occurs - even if it means that a first run is 'forced' after something is enabled, but prior to it actually being usable. I'd rather have an internal flag set that verifies a contrib as 'ready for use' and have core run a check routine once, than have any case where there's a check routine that runs on every function call. One Boolean value as a flag can bypass a million lines of bloat.

#57: field-undefined-index-module-1001060-57.patch queued for re-testing.

Just found this was still an issue after updating to Drupal 7.16. Wow, almost 2 years old.

Same thing with Drupal 7.17 forcing it if if clause as #51 throw the error away but not sure what the other implication will be by setting the variable to null.

I only began getting this kind of error messages a few days ago on drupal 7.16, and it has unfortunately not gone away after upgrading to 7.17 (+ clearing all caches).

Being as yet a Drupal novice, I'm not sure what kind of information is really relevant here to help identify where this is coming from, but here's my go at it anyway:

1. my setup:
   drupal core, first 7.16 now 7.17
   running with default bartik theme
   all's apparently well (see attached status report)
   installed modules: see attached module list for details.
2. the displayed notice:
   

   Notice: Undefined index: module in _field_info_prepare_instance_widget() (line 387 of W:\sli\drupal\modules\field\field.info.inc).
   Notice: Undefined index: module in _field_info_prepare_instance_display() (line 355 of W:\sli\drupal\modules\field\field.info.inc).

3. When it began appearing:
   Checking the logs, this notice has begun cropping up after I installed & enabled various modules (unfortunately all at once, so I cannot say whether and which one of these mayhaps be doing something in the background to cause this?!?) They were:
   • l10n_update 7.x-1.0-beta3
     l10n_client 7.x-1.1
   • file_entity_link 7.x-1.0-alpha2
     file_entity 7.x-2.0-unstable7
   • node_gallery 7.x-1.0-beta1
     node_gallery_api 7.x-1.0-beta1
   • various l10n_update's
4. When the message gets displayed:
   • Working with Content types:
     (default Article/Basic Page same as custom types):
     • Manage fields:
       - after adding and setting up a new field / an existing field
     • manage display:
       - storing field settings
       - adding and removing custom display settings
     • comment fields:
       - changing field settings
     • no problems on any comment display changes
   • Taxonomy Terms:
     • problems only on Manage fields
       - same as with content types
     • manage display: no problems

HTH!

P.S.!!!!

Um.
I went into the code to patch up as suggested in #51 and #60, and saw that this actually may be a VERY simple thing to fix?!

In the display case for example, there's an if() statement just before the problem line of code which handles exactly the case of there not being a $formatter_type.
However, the problem line of code gets applied in any case, and I'm guessing that we get these notices for empty indexes exactly in cases when the if() actually validated to true (the system will never find the missing index "module" if the variable doesn't exist in the first place).

Hence, the simple logical fix would be to add the complementary else() to the if(), making the second case hidden to instances where if() was true (same actually as the NULL solution, just simple and - unequivocally unmysterious).

Thus the fix could simply go:

//$display['module'] = $formatter_type['module'];
	else $display['module'] = $formatter_type['module'];

and

//$widget['module'] = $widget_type['module'];
	else $widget['module'] = $widget_type['module'];

So, ... duh?!
While it would be more than cool if it really only took an idiot to fix an idiot error....
this still doesn't explain why the problem appeared out of the blue in my case (and I'm guessing in others too), so I fear this won't close this issue just yet....

soo....handing it back to the pro's ;)

I thought I would reference this for information. My opinion is core will not change the field_info. inc, its been 2 years now, and that all issues listed above are module related and should be referred to the offending module, I could be wrong but I've spent a lot of hours looking into this. The problem is finding the module that is miss-behaving.
#1728488: Notice: Undefined index: module в _field_info_prepare_instance_widget()

http://drupal.org/node/1728488#comment-6763564

@thedosman
Thanks for your pointer, upon which I have gone back and looked at my setup again and was able to identify the "miss-behaving module"; in my case it's Node Gallery API.
[ Note to other novice drupallers:
there's a nifty "currently enabled field and input widget modules" list on the Fields help page (/admin/help/field) that, combined with log data of modules newly installed when the problem arose, can help identify which it is.]

I now understand the problem like this:

1. there are two logical if/else errors in the fields.info.inc because the else statement has been left, by omission of else, to be executed in any case.
2. This causes problems when modules are installed that do not explicitly set $widget_type or $formatter_type, leading to those ugly undefined-index notices.

So is what you're saying that, seeing that the very basic (as far as I can see from my admittedly naive standpoint) error causing all this is not getting fixed in Field, we should tell the developers of all the individual modules that generate these notices to explicitly define these variables?

Isn't that a kind of roundabout way of going about though, seeing that there is only ONE actually very easy-to-fix integrity issue with the Field code causing all this?!
On the one hand, of course it is certainly a good practice to define one's variables, but OTOH shouldn't the Field code handle cases correctly where others rely on default settings too?

Sure, I can also create an issue on Node Gallery API for this (edit: done - and everyone else henceforth running into the same problem with other modules), but ---
sheez, why can't we just nip the problem in the bud and get it over with?
What am I missing?!

Cheers!

@calliandra
After over 2 years I can't foresee movement in core on this. So maybe the maintainers have to concede on this. I admit it is a simple fix at face value but I've also noticed a number of isset omitting issues with several contribs over the years I've worked with Drupal and if core relents on this perhaps it will open a Pandora's box on all those other issets. Modules written to work with core should in fact work with core, even if some steps seem a little redundant. After all, isn't redundant steps at the core of programming? I haven't looked into the cascade of issues this particular fix would perpetuate, if any, but maybe core has.?
Anyways, most maintainers will , in their own time, fix verified conflicts with core.

The maintainer of Node Gallery has just now circumvented the problem in a way that I cannot (with my utter ignorance of how all the pieces of Drupal fit together) follow.
His workaround is based on avoiding any calls to entity_get_info(), but I have noo idea where that function is, what it does, and how it plays into Fields, and what actually happens when it is avoided.

Due to this, I spent some more time staring at the code passages that end up throwing those notices and discovered that I cannot actually be certain the if-else interpretation of the problem is actually correct.

Using the formatter case to illustrate my doubts (the same being true by analogy in the widget case):

function _field_info_prepare_instance_display($field, $display) {
  $field_type = field_info_field_types($field['type']);

  // Fill in default values.
  $display += array(
    'label' => 'above',
    'type' => $field_type['default_formatter'],
    'settings' => array(),
    'weight' => 0,
  );
  if ($display['type'] != 'hidden') {
    $formatter_type = field_info_formatter_types($display['type']);

    // Fallback to default formatter if formatter type is not available.
    if (!$formatter_type) {
      $display['type'] = $field_type['default_formatter'];
      $formatter_type = field_info_formatter_types($display['type']);
    }

    $display['module'] = $formatter_type['module'];
		
    // Fill in default settings for the formatter.
    $display['settings'] += field_info_formatter_settings($display['type']);

  }

  return $display;
}

The if-else interpretation is based on the assumption that the presence of $formatter_type['module'] in the statement after the if means there are specific settings being made by a module (as opposed to the module not specifying anything and thus being attributed the defaults within the if statement).
Then, yes, if-else would be the way to go.
And the fact that all seems to be well whenever the corresponding fix is applied does seem to support it.

But...
Is there, possibly, something going wrong within the if statement itself instead?
Is the line in there:
$formatter_type = field_info_formatter_types($display['type']);
actually supposed to be making $formatter_type['module'] available for an unconditional setting up of $display['module'], but is failing to do so for some reason - making that the actual source of the generated notice?
In this case, we should be looking at that function and making sure it actually makes $formatter_type['module'] available instead.

I have spent the better part of the morning trying to follow the code up the line, but the longer I look at this, the more questions arise, and I feel I am getting badly lost.
So, who has enough grasp on the code to be able to actually answer them?
Many thanks in advance!

@calliandra
Thanks for your thorough investigation of this issue!

BTW
If you mark your code as PHP it will even be syntax highlighted ;-)

So, just to be clear - there's no bug in core. This is another case of some contrib module exposing wrong data, triggering errors in the system that consumes this data (Field API formatter code here).

I see two cases that could trigger this bug :

1) Somehow, the formatter info array for some formatter has no 'module' entry.
This info is collected in _field_info_collate_types(), which does the following:
- collect formatters info from hook_field_formatter_info(),
- add the 'module' property in each definition
- run drupal_alter()

So it means that the only case where the 'module' entry would be missing is wrong stuff done by a module in hook_field_formatter_info_alter(), either:
- by explicitly removing the 'module' entry - which would be a stupid thing to do.
- or by *adding* a new formatter definition, which then doesn't get the 'module' property automatically populated (would not be doable anyway, there's no way to know who altered what). That is an invalid use case of alter : alter is made to modify entries exposed in the original hook, not adding new entries. Adding new entries should be done in hook_field_formatter_info(), not alter.

A formatter without a 'module' entry is completely useless anyway, we can't know what callbacks to call when we want to actually use the formatter.
So the right fix for this would to add another step in _field_info_collate_types() after running drupal_alter() : ditch entries that don't have a 'module' property, because those formatters are as good as just not being there.

2) A field type whose 'default_formatter' does not exist (or is disabled). Each field type needs a 'default_formatter' that is always available whenever the field type itself is available.
When _field_info_prepare_instance_display() finds an $instance definition using a formatter that is unknown in the current runtime environment (e.g. because the formatter has been disabled since the $instance was stored), it falls back to the 'default formatter'. If that default formatter itself doesn't exist, the error occurs.

The core policy is "don't babysit broken code" - i.e don't burden code and runtime CPU with checks for wrong code in external modules.
The problem, however, is that in cases like this one, the error messages do not point at the actual source of the error, but point at the consuming system instead, and result in convoluted and almost impossible to sort out issues like this one.

Core could provide a safeguard for case 1) at minimal cost - attached patch does that.
I can't do anything for case 2). Every field type needs a default formatter and widget, that's expected to always exist if the field type exists (i.e it needs to be provided by the field type module)

before you unset, could the module names be written to watchdog?

As a site builder, not a developer per se, this would help tremendously.

Well, I precisely can't write the module name in watchdog, that's the exact piece of information I don't have :-)

JFTR
I get the same notices after uninstalling Meta tags (quick).

EDIT
The patch from #74 applies ok but doesn't seem to solve the issue in my case. Will have to take a closer look. Thanks for all the useful hints!

I'm having this same problem with 7.20 with a field from the relation_endpoint module (relation project)?
The patch in #74 did not work, patch #57 appears to do the trick but the author misspelled 'isset', so attached is the corrected patch.

Just to confirm. Updated from 7.19 to 7.21 and now getting the following in my log:

Notice: Undefined index: module in _field_info_prepare_instance_display() (line 355 of /var/www/vhosts/example.com/httpdocs/modules/field/field.info.inc).

Getting the same warnings in 7.21. Patch #78 fixes it.

The patch in #78 no longer applies, but see also the explanation in #74...

Patch in #78 also makes this error go away for me but does not fix the underlying cause - I too see relation_endpoint show up as previously mentioned. It is passing in null widget settings with no module set, or type. This causes the rest of the code (that patch #78 works around) to throw the error.

edit: Note patch #78 now goes in the method prepareInstanceWidget().

@yched: Thanks for a detailed explanation. I really appreciate it.

I had this issue when using Features. A field instance got stuck in my feature for some reason, even though I had deleted the field from a relation in the ui (relation module).

For those using the Features module, review your field instances and make sure that there is nothing there that shouldn´t be. Also, check the field_config_instance table in your DB and make sure the field was deleted when reverting your feature (drush fr myfeature). Actually, I´m not sure it get´s deleted even though you revert a feature that has had the field instance removed from the code.

Anyway, In my case, it wasn´t deleted from the DB. I had to manually delete the records.

Cheers.
Nonni

Just realized that the issue wasn´t resolved. It was a bug in the relation module but has been fixed in latest dev.

:)

What's up with this issue?

I am getting this error in 7.31, specifically this set of errors related to field.info.class.inc:

• Notice: Undefined index: module in FieldInfo->prepareInstanceWidget() (line 575 of C:\inetpub\wwwroot\naccas\modules\field\field.info.class.inc).
• Notice: Undefined index: module in FieldInfo->prepareInstanceDisplay() (line 610 of C:\inetpub\wwwroot\naccas\modules\field\field.info.class.inc).
• Notice: Undefined index: module in FieldInfo->prepareInstanceDisplay() (line 610 of C:\inetpub\wwwroot\naccas\modules\field\field.info.class.inc).
• Notice: Undefined index: module in FieldInfo->prepareInstanceDisplay() (line 610 of C:\inetpub\wwwroot\naccas\modules\field\field.info.class.inc).

This happened to me when I created a link field with the link module and then deleted the link module from the site without disabling it. The problem went away when I restored the link module files. User error, in my case, but perhaps this will help others.

In theory should the link module in it's uninstall procedure (hook_uninstall()) remove field formatters and widgets. If it fail doing this on uninstall should these findings be posted to the module issue queue. Pls. make sure you always run uninstall and not only disable the module before you remove the module.

Hello,

after having make the upgrade to 7.34 version (7.32 > 7.34), I get this notice in my multisite installation

Notice : Undefined index: module dans FieldInfo->prepareInstanceWidget() (ligne 591 dans /srv/data/web/vhosts/www.mysite.com/htdocs/modules/field/field.info.class.inc)

Can i debug this notice ?

Thanks.

#9 worked for me. Thanks mcfilms!