Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.In recent versions of Drupal 7, the following warning message was introduced:
- "The following module is missing from the file system: [..]"
- "The following module has moved within the file system: [..]"
So far I identified 3 possible reasons for this:
1. The most obvious: A module that is enabled in the system table is missing or has moved.
2. field_schema() tries to build the schema for a leftover field with a field type that depends on a missing module.
3. A hook_system_info_alter() implementation calls module_hook() or something else that triggers drupal_get_filename().
feeds is one of the modules that implement hook_system_info_alter().
Steps to reproduce (on a site with feeds enabled):
- Disable + uninstall a module.
- Move the module in the filesystem.
- Re-enable the module.
Explanation:
The "system info" tells us, among other things, which module lives where.
hook_system_info_alter() is called when rebuilding the "system info".
drupal_get_filename() needs the "system info".
So we get a chicken-and-egg problem.
Luckily, most of the hook_system_info_alter() implementations that create such problems do not really want to alter the "which module lives where in the filesystem". This means the information of what lives where is already available before the hook has completed.
Possible solution:
- Use hook_module_implements_alter() to let feeds_system_info_alter() run after most of the other implementations.
- Instead of module_hook() and drupal_get_filename(), use the module paths in the info array.
Caveat: I have not thought this through to the very end. Maybe there is a problem if a module was previously included from its old filesystem location, and you then include the copy of the file in a different filesystem location.
Maybe this should be discussed in the core issue queue?
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | feeds-moved-module-2828605-7.patch | 537 bytes | David_Rothstein |
Comments
Comment #2
megachrizFeeds' implementation of
hook_system_info_alter()is inspired by the implementation of the core Field module, which also usesmodule_hook()to check if a module implements a certain hook. Would the same problem occur when you uninstall a module that provides a field type, move that around and enable the module again? If so, then it is probably a core issue.Comment #3
donquixote commentedYes, I suppose you can reproduce the same warning with core field module.
So far in my quick experiments it was triggered by system_list('module_enabled') -> drupal_get_filename(), and somehow not by hook_system_info_alter(). I think it needs some more experiments.
Comment #4
megachrizI noticed a small difference between the Field and Feeds module. For Feeds,
hook_feeds_plugins()may live in $module.feeds.inc, and that seems to require amodule_load_include()if such file isn't loaded yet. For the Field module, allhook_field_info()implementations need to be in the .module file.We could have Feeds have their own version of
module_hook(), wheremodule_load_include()is replaced with a method in including a file with the warning message suppressed. But for me, it sounds like a bit silly thing to do.Comment #5
twistor commentedThis won't help. We're using ctools as well, which calls all sorts of hook invocations.
This should help. We'd maybe want to move checking for the feeds module to the top, to avoid triggering it on itself.
Comment #6
megachriz@twistor
You commented on the same text twice ;). What exactly won't help and what does help?
Comment #7
David_Rothstein commentedAgreed there is a core issue buried somewhere in here (mostly I think it's #1948702: module_hook is broken for disabled modules and included hooks).
But can this be fixed in Feeds just by bailing out early if the module isn't enabled yet (see the attached patch)? Per the above issue that is what module_hook() should be doing anyway.
I am not sure if there's a scenario where this would cause a problem compared to the current behavior. I guess perhaps if the module is in the process of being enabled (but not enabled yet) and other modules are somehow already using the module's plugins, this could make it skip labeling the module as required... But even in that case, it should fix itself the next time the hook is called (for example, the next time someone visits the Modules page).
By the way, note that a simpler way to reproduce this (see #2773959: "The following [module/theme] has moved within the file system:" error after downloading new module or theme), which I've run into myself is, with Feeds module enabled:
Comment #9
megachrizI think it's okay to skip the requirement check if the module isn't enabled yet (or in the process of being enabled). The case where a module is enabled and disabled during the same request sounds very rare to me.
For background information: the requirement was added in #2379407: Make module required if plugins are in use. as a result of the following reported issue: #2379223: Disable gave white screen!
Thanks for providing an easy way to reproduce the issue! I tried to download a module and flush the caches before and after applying the patch and I can confirm that the patch fixes the issue.
Committed #7.