Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
_field_info_prepare_instance_widget() was throwing errors in RC1 and continues to do so in RC1. If I clear the cache I get:
Notice: Undefined index: module in _field_info_prepare_instance_widget() (line 385 of /home/everlast/public_html/take5/modules/field/field.info.inc).
This is not a D6 to D7 upgrade. It is a site built on drupal 7.0-beta2 and upgraded twice.
Comment | File | Size | Author |
---|---|---|---|
#78 | field-undefined-index-module-1001060-78.patch | 630 bytes | relaxnow |
#74 | prepare_display_notices-1001060-74.patch | 2.35 KB | yched |
#66 | Status_report.pdf | 38.16 KB | calliandra |
#66 | modules.txt | 787 bytes | calliandra |
#57 | field-undefined-index-module-1001060-57.patch | 630 bytes | emorency |
Comments
Comment #1
droplet CreditAttribution: droplet commentedhmm.. what am i overlook.. $field_type is never used in this function
we can remove
Comment #2
mcfilms CreditAttribution: mcfilms commentedWhen I update to the latest (Dec. 15?) dev version of Drupal and the latest DEV version of Views, this error disappeared. I'm not saying that section is not junk, I'm just sharing that this issue is gone.
Comment #3
David_Rothstein CreditAttribution: David_Rothstein commentedIt doesn't look to me like $field_type is unused. Here is the full snippet:
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?
Comment #4
droplet CreditAttribution: droplet commentedhaha. I'm think into wrong way, stupid enough.
ok. the problem is it haven't check $widget array keys.
we could see lots code inside Drupal missing this step, eg
http://drupal.org/node/1002380
Comment #5
mcfilms CreditAttribution: mcfilms commentedWell I'll count my blessings and close it. Someone else can re-open it if it is still percieved to be an issue.
Comment #6
tinny CreditAttribution: tinny commentedI 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.
Comment #7
cdesautels CreditAttribution: cdesautels commentedI'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.
Comment #8
BrightBold@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.
Comment #9
mcfilms CreditAttribution: mcfilms commentedMy best guess is that the early releases of D7 allowed you to install Views without the CTools and Entities modules. I believe these modules have since become required. I think updating all of that helped my issue.
However, if you are running just the core D7 I guess this isn't the issue.
Comment #10
BrightBold@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.
Comment #11
mcfilms CreditAttribution: mcfilms commented@BrightBold,
If I recall, the advice was to uninstall all three modules. (After this I may have run update.php and cleared the cache for good measure.) Then I download the very latest CTools and Entities as well as the Dev version of Views. I upload all three of them and enabled all three together. Then ran update.php.
I guess it goes without saying to work on a back-up first. I'm a little hazy about how this error got cleared.
Good Luck!
Comment #12
cdesautels CreditAttribution: cdesautels commentedI'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.
Comment #13
TripX CreditAttribution: TripX commentedSame 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.
Comment #14
yched CreditAttribution: yched commentedThis 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) :
Comment #15
BrightBoldDoes 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.
Comment #16
BrightBoldUpdate - got it! Cleared the cache. Debug info is attached for yched and here for anyone else who's interested:
Looks like it's mad at OG, which I have installed but not enabled.
Comment #17
yched CreditAttribution: yched commented@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.
Comment #18
BrightBoldWell, 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.
Comment #19
BrightBoldI 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:
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.
Comment #20
kclarkson CreditAttribution: kclarkson commentedI 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.
Comment #21
aidanlis CreditAttribution: aidanlis commentedComment #22
TripX CreditAttribution: TripX commentedbtw. Deleting and readding views fields solved it some weeks ago.
Comment #23
yched CreditAttribution: yched commentedI 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 ?
Comment #24
steinmb CreditAttribution: steinmb commentedHi
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?
Comment #25
steinmb CreditAttribution: steinmb commentedyched, any tips how we should move this forward, and/or work around it?
Best regards
Steinmb
Comment #26
yched CreditAttribution: yched commentedThe 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.
Comment #27
steinmb CreditAttribution: steinmb commentedThanks, I'll hop in, and join the discussion. I'll hope feedback related to this issues could be posted in to that issue also.
Comment #28
thebuckst0p CreditAttribution: thebuckst0p commentedSubscribe.
Comment #29
Tor Arne Thune CreditAttribution: Tor Arne Thune commentedSubscribing, as I have the same issue with these notices:
Comment #30
AndrzejG CreditAttribution: AndrzejG commentedI 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)
Comment #31
yched CreditAttribution: yched commentedThis 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".
Comment #32
thomsol CreditAttribution: thomsol commentedThanks 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.
Comment #33
lauraleigh CreditAttribution: lauraleigh commentedI'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.
Comment #34
lauraleigh CreditAttribution: lauraleigh commentedComment #35
lauraleigh CreditAttribution: lauraleigh commentedn/a
Comment #36
muayguy CreditAttribution: muayguy commentedjust 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
message some people talked about before but now they're gone... the body field is still gone though
Comment #37
Daniel Lobo CreditAttribution: Daniel Lobo commented+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
Comment #38
steinmb CreditAttribution: steinmb commentedPls. read #31, give it a run and report back your findings.
Comment #39
Frank Ralf CreditAttribution: Frank Ralf commentedI applied the patch from #31 and this is what I got:
hth
EDIT:
Temporarily activating the Taxonomy module seems to have solved the issue.
Comment #40
dubitoph CreditAttribution: dubitoph commentedNotice : 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).
Comment #41
yched CreditAttribution: yched commentedShould 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.
Comment #43
renat CreditAttribution: renat commentedHave 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.
Comment #44
adam_b CreditAttribution: adam_b commentedAfraid I'm getting it also, with D7.8.
Comment #45
renat CreditAttribution: renat commentedAdam, 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?
Comment #46
adam_b CreditAttribution: adam_b commentedThanks for the feedback, Renat. I am using those two modules, so it does appear to be related.
Comment #47
30equals CreditAttribution: 30equals commentedgot it as well, and posted some debugging info in the field_collection issue queue
http://drupal.org/node/1292090#comment-5107786
Comment #48
colanI'm not using Field collection, and still run into these. We should therefore keep that as a separate issue.
Comment #49
markspall CreditAttribution: markspall commentedHad 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.
Comment #50
pandaPowder CreditAttribution: pandaPowder commentedI saw this same problem in d7 and updated entity reference to 7.x-1.0-rc1 and it went away.
Comment #51
HumanTex CreditAttribution: HumanTex commentedWhile 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
Comment #52
thedosmann CreditAttribution: thedosmann commentedJust went from 7.14 to 7.15 and got the same message. Followed #51 and error seemed to go away.
Comment #53
lsolesen CreditAttribution: lsolesen commented@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.
After going through the install process the error is present both in the installation, and when you view a node afterwards.
Comment #54
lsolesen CreditAttribution: lsolesen commentedComment #55
Aurochs CreditAttribution: Aurochs commented@HumanTex - thanks that helped me. I dont seem to have other issues connected with that. The stupid mssge disappered once for all.
:beer:
Comment #56
deanflory CreditAttribution: deanflory commentedThe 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
Comment #57
emorency CreditAttribution: emorency commentedI've created a patch following #51 comment.
Comment #58
Frank Ralf CreditAttribution: Frank Ralf commentedJust setting this to "Needs review".
Comment #60
likes_drupal CreditAttribution: likes_drupal commented@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)
in function _field_info_prepare_instance_widget($field, $widget)
Comment #61
HumanTex CreditAttribution: HumanTex commented@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:
@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.
Comment #62
plonk CreditAttribution: plonk commented#57: field-undefined-index-module-1001060-57.patch queued for re-testing.
Comment #64
deanflory CreditAttribution: deanflory commentedJust found this was still an issue after updating to Drupal 7.16. Wow, almost 2 years old.
Comment #65
duckzland CreditAttribution: duckzland commentedSame 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.
Comment #66
calliandra CreditAttribution: calliandra commentedI 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:
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.
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_client 7.x-1.1
file_entity 7.x-2.0-unstable7
node_gallery_api 7.x-1.0-beta1
(default Article/Basic Page same as custom types):
- after adding and setting up a new field / an existing field
- storing field settings
- adding and removing custom display settings
- changing field settings
- same as with content types
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 theif()
, making the second case hidden to instances whereif()
was true (same actually as the NULL solution, just simple and - unequivocally unmysterious).Thus the fix could simply go:
and
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 ;)
Comment #67
thedosmann CreditAttribution: thedosmann commentedI 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
Comment #68
calliandra CreditAttribution: calliandra commented@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:
if/else
errors in the fields.info.inc because the else statement has been left, by omission ofelse
, to be executed in any case.$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!
Comment #69
mcfilms CreditAttribution: mcfilms commented@calliandra -- Great sleuthing!
Can you produce a patch against fields.info.inc? If you're confident that this change addressed the original issue, I'll be happy to test it and cheerlead it along.
I'd like to see this get into 7.18
Comment #70
thedosmann CreditAttribution: thedosmann commented@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.
Comment #71
mcfilms CreditAttribution: mcfilms commentedI disagree! Core is updated all the time precisely to fix issues such as these.
This is a flaw in the core and should be fixed. The fact that it resolves issues in many use cases is just a wonderful bonus.
Comment #72
calliandra CreditAttribution: calliandra commentedThe 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):
The if-else interpretation is based on the assumption that the presence of
$formatter_type['module']
in the statement after theif
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 theif
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!
Comment #73
Frank Ralf CreditAttribution: Frank Ralf commented@calliandra
Thanks for your thorough investigation of this issue!
BTW
If you mark your code as PHP it will even be syntax highlighted ;-)
Comment #74
yched CreditAttribution: yched commentedSo, 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)
Comment #75
SocialNicheGuru CreditAttribution: SocialNicheGuru commentedbefore you unset, could the module names be written to watchdog?
As a site builder, not a developer per se, this would help tremendously.
Comment #76
yched CreditAttribution: yched commentedWell, I precisely can't write the module name in watchdog, that's the exact piece of information I don't have :-)
Comment #77
Frank Ralf CreditAttribution: Frank Ralf commentedJFTR
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!
Comment #78
relaxnow CreditAttribution: relaxnow commentedI'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.
Comment #79
brewthis CreditAttribution: brewthis commentedJust 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).
Comment #80
lakshminp CreditAttribution: lakshminp commentedGetting the same warnings in 7.21. Patch #78 fixes it.
Comment #81
David_Rothstein CreditAttribution: David_Rothstein commentedThe patch in #78 no longer applies, but see also the explanation in #74...
Comment #82
kevinquillen CreditAttribution: kevinquillen commentedPatch 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().
Comment #83
busla CreditAttribution: busla commented@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
Comment #84
busla CreditAttribution: busla commentedJust realized that the issue wasn´t resolved. It was a bug in the relation module but has been fixed in latest dev.
:)
Comment #85
deanflory CreditAttribution: deanflory commentedWhat's up with this issue?
Comment #86
OpsTao CreditAttribution: OpsTao commentedI 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).
Comment #87
steinmb CreditAttribution: steinmb commentedComment #88
arnoldbird CreditAttribution: arnoldbird commentedThis 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.
Comment #89
steinmb CreditAttribution: steinmb commentedIn 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.
Comment #90
kumkum29 CreditAttribution: kumkum29 commentedHello,
after having make the upgrade to 7.34 version (7.32 > 7.34), I get this notice in my multisite installation
Can i debug this notice ?
Thanks.
Comment #91
alfonsobarreiro CreditAttribution: alfonsobarreiro commented#9 worked for me. Thanks mcfilms!