Last updated January 15, 2017. Created on May 12, 2015.
Edited by donquixote, mradcliffe, David_Rothstein, brankoc. Log in to edit this page.

If you see a PHP warning such as "The following module is missing from the file system..." (or similar) on your site, this page explains how to fix it.

The warning was introduced in Drupal 7.50 and is displayed when Drupal is attempting to find a module or theme in the file system, but either cannot find it or does not find it in the expected place. Usually this indicates a problem with your site. It is not a major problem, but one which should ideally be fixed if possible. (See the change record for more information on why this warning was added, and these instructions for how to ensure that warning messages like this one are never displayed to your site's end users, but rather only recorded in the administrative logs.)

Note that the problem or inconsistency on your site, which is now causing this warning, might have been existing for a long time already, without any visible symptoms. The introduction of the warning message in Drupal 7.50 does make it visible.

There are a few possible causes and corresponding solutions.

You removed a module from the file system without disabling and uninstalling it

Possible solutions:

  • Restore the module and actually disable and uninstall it (recommended if possible): First, restore the module to its original location in the file system. Then either go to the Modules page and disable/uninstall it from there, or use Drush (drush dis module_name && drush pm-uninstall module_name, where module_name should be replaced with the name of the module).
  • Manually remove all traces of the module in the database. This is not the recommended solution because many modules do important cleanup tasks during the disable/uninstall process, and this solution will result in those being skipped. In many cases it will mean that the module will be broken if an attempt is ever made to use it again on this site. However if you decide to use this solution (e.g. for obsolete modules that do not even exist anymore and that can never be added back), it can be done in several ways. Here are some examples:
    • Drupal 7
      1. Use the administrative interface provided by the "Module Missing Message Fixer" module

        See https://www.drupal.org/project/module_missing_message_fixer.

      2. Use Drush

        For example, run a command similar to the following:

        drush sql-query "DELETE from system where name = 'old_module1' AND type = 'module';"

        When done, clear the site's caches (e.g. drush cc all).

      3. Write an update hook in a custom module

        You can use code similar to the example below, which will remove the missing modules when update.php is run:

        /**
         * Delete {system} records for long-lost modules.
         */
        function MYMODULE_update_7100() {
          $modules = array(
            'old_module1',
            'old_module2',
            'old_module3',
          );
          db_delete('system')
            ->condition('name', $modules, 'IN')
            ->condition('type', 'module')
            ->execute();
        }
        
    • Drupal 8
      drush sql-query "DELETE FROM key_value WHERE collection='system.schema' AND name='module_name';"
      When done, clear the site's caches (e.g. drush cr).
      Also make sure that the CMI folder is cleansed of the broken uninstalled module. There may be some yml files left over and / or some system config. (this is all not the best way to do things as a FYI. However with Drupal 8 being so young, things don't go as planned always).

You moved the module inside your Drupal installation

Possible solutions:

  • Clear the site's caches so the new location of the module is registered. Or,
  • Move the module back to its original location in the file system.

Leftover fields or other configuration entries

There could be a leftover field or other configuration entry that depends on the missing module, and was not properly deleted or cleaned up when the module was disabled or uninstalled.

See e.g. #2820939: field_read_fields() does not check whether a module is disabled or missing.

To find out more, you need to get a stack trace, and find out from where the code that triggered the error was called.

You can then open an issue on in the respective project's issue queue, or post a comment on this page, to help document such cases, improve error reporting, and finally fix them for good.

Sometimes leftover items can be cleaned up with cron or cache clearing, but this really depends.

Formally, an unsuccessful uninstall does qualify as a bug - so also read the section below.

Obsolete modules existed from a previous Drupal version

A Drupal site that was upgraded from Drupal 6 to Drupal 7 may also display warnings about modules that were active in Drupal 6 but were disabled before the upgrade. These can only be cleaned up by one of the systems table solutions above.

Example: modules such as imagecache_ui, imageapi, filefield, optionwidgets, and imagefield which were made obsolete by Drupal 7 versions may still exist in the system table.

There is a bug in a module installed on your site

The final possibility is that there is code on your site which is accidentally telling Drupal to search for a file that doesn't exist. This could be because of a typo in the code (where it is searching for an incorrect module name), or because the code is deliberately checking for a nonexistent file but did not update in response to this change record.

If this appears to be the issue, try to figure out what code is causing the problem (it will usually be code that calls module_load_include(), drupal_get_path(), drupal_get_filename(), or similar functions. If the offending code is in Drupal core or a contributed module, file a bug report in the appropriate issue queue on Drupal.org.

Try to produce a stack trace to find out where the problem originates.

Problems with hook_system_info_alter() calling other hooks

Some (contrib) modules use hook_system_info_alter() to change the data scanned from modules' *.info files. At the time that this hook is invoked, the module info data is being rebuilt, but an old, possibly outdated and inaccurate, version of this data is still in the database.

Some of these implementations of hook_system_info_alter() directly or indirectly invoke other hooks, which uses the old module info data still in the database. This can cause a warning "The following module has moved within the file system", or possibly "The following module is missing from the file system".

Most of the time this does not cause any real problems. But the warnings can be confusing and annoying.

As said above, this should be discussed in the issue queue of the respective module.

Looking for support? Visit the Drupal.org forums, or join #drupal-support in IRC.

Comments

videodoll’s picture

It's the theme bootstrap barrio. I disabled it and I am using regular boot strap now... The error went away when I disabled that theme.

Thanks for replying.

scothar’s picture

When D7.50 was released with this new functionality I immediately dealt with the message problem by installing the missing_module_message module. It took care of everything... until today.

Today I get this multiple times in my logs (basically a full page of warnings in each updated site): "The following module is missing from the file system: several_different_D7_core_modules. For information about how to fix this, see the documentation page (link is external). in _drupal_trigger_error_with_delayed_logging()". All the warnings are about D7 core modules, all of which are activated and have been working perfectly well.

The change: I updated to D7.51 yesterday.

All the error messages were propagated during my database updates before leaving maintenance mode and none of the warnings has reappeared since that moment.

As for the comments above re: install/uninstall - There are still a lot of modules out there that do not offer this functionality in themselves. Nor is the function available in D7 core. The only way to dump them is to rip them out manually and manually do whatever neurosurgery is necessary on the afflicted database. But what do we do when the warnings are about active core modules?

geraldvillorente’s picture

I checked the system table and there is no traces of the module in question however in Drush there are bunch of warning about this missing modules. Any possible reason? Or is there any location aside from system table that could trigger Drush to produce this warning?

Just another Drupal novice from the other side of the planet.

osopolar’s picture

I have the same problem, for example with the following modules: addressfield, commerce_line_item, commerce_price, commerce_customer, commerce_product_reference. I downloaded the modules addressfield and commerce and uninstalled all the mentioned modules, cleared cache multiple times but the warnings are not going away. I had two more custom modules which I removed with Module Missing Message Fixer. I also used drush registry-rebuild (from Registry Rebuild module), without any luck. Calling "drush updb" for example still shows these missing module warnings for the uninstalled modules. Am I missing something?

donquixote’s picture

Get a stack trace then we see.

PMorris’s picture

This is truly awful. The main problem is that non of the solutions suggested here are working. I think there should have been an option included with Drupal to clean out the broken records in the database.

PapaGrande’s picture

I was getting this message for a misspelled module name in a hook_menu() entry. The link was working fine without error so I had never noticed the mistake until I started seeing the messages. Hope this helps someone else in tracking down the source of the messages.

capfive’s picture

This is VERY annoying, ir seems every single one of our drupal sites (all 60 of them) are now riddling the error logs with these messages.

The modules are in the correct location.

Has anyone come across a fix as of late?

EDIT: I would just like to say, There are no missing modules in my sites that this message is coming up in, they are to do with modules that are installed and active... is anyone else getting this problem?

Drupal sites by Neubreed Design

botris’s picture

This "fix" assumes missing modules is a problem. The problem is though when you switch git branches a lot, you get constant warnings.
Suppose you are working on a new feature that has 8 new modules. You need to switch to a hotfix branch to debug something, now you either got to accept a long list of errors and broken drush or you have to export all your settings, disable and uninstall all your new modules. That is total overkill if you just want to work in another branch for say 1/2 hour.

Why not make this a notification a variable so you can choose if it should show up or not?

sander-martijn’s picture

I'm glad there's an easy solution, but this was a very very bad idea. Drupal really needs some UI specialists on the team to say NO DON'T DO THAT!!!

travisc’s picture

More of UX then a UI issue, but the real issue is that the "FIX" didn't bother to include a solution to the problem. We need to fix this so missing modules are never an issue!

travisc’s picture

There should be warning message that informs you that you have missing modules, and asks you if you "would you like to uninstall the following x module", with a link to a page that allows you to uninstall each module individually including a message that informs you "if you uninstall the following module data will be irreparably lost", and a button to uninstall the module. I also think the idea set a variable to ignore the missing module is a good one.

sander-martijn’s picture

The modules that come up because of this are already missing - i.e. have been uninstalled. Ergo they shouldn't come up as an error at all.

travisc’s picture

they haven't been uninstalled the code is just missing.

joseph.olstad’s picture

Most computer systems will just crash when you delete their files. Whereas drupal is very modular so it just disabled the missing module(s) without uninstalling them (it cannot make that decision for you, especially when the uninstall information is missing)

The fix was to add a warning message, this is something acceptable.

As for the other API changes, there was an unrelated change who's bug or symptom manifests as a missing module when in fact it isn't , these bugs are few and far between and most modules have been udpated since those api changes were made.

Smile, be happy!

crystaldawn’s picture

Well then Josesph, if we used that logic for everything, there would be no need to ever fix anything properly ;) Excuses based on what others can/cant do is not a good excuse to continue with mediocrity IMO. Besides, when you boot Winblows, it doesnt warn you about missing files every time you open a completely unrelated application. You have to check the "Event Viewer" to see them all. This is essentially what Drupal is currently doing. Everytime you "open a new window" if you want to compare it to an OS (IE: every time you drush CC all, these retarded warnings spam the screen...... BUZZZZZZ thats not the correct implementation), it warns you about completely unrelated issues to whatever you are doing. The proper place for these warnings would be, just like WinBlows event viewer, is in the status page just like ever other module's "warnings" about bad things.

There is NO excuse for mediocrity no matter what you say :) There are a zillion complaints about how this feature is implemented, not complaints that it shouldnt be there. It's the implementation of a necessary feature that is utter garbage, not the feature itself.

Smile and be happy?! Humbug! haha. Complain and push for improvements lol. Anyway, Idk what you were replying to but thats how I feel about this garbage implementation. Feature idea... sound. Implementation... utter crap.

joseph.olstad’s picture

@crystaldawn , I hear you, it would be pretty easy to add a helpful message in the warning to an admin function that does what the missingmodulefixer does or what my cleanup_tool module does for drush.
This functionality could be added to core for sure,
I suggest writing a patch and submitting it.

BTW, I've been donating a lot of time to contrib land lately, took over maintainership of several modules in the past 4 months , now the community (happy people) can just download the latest releases of these modules and have their functionality working easy like pie. No patches required, I got tired of seeing a few of these modules in a lackluster state of patch patch patch, took matters into my own hands. Luckily my clients are paying for some of it, and will rejoice in the fruits of this work having awesome functionality working without having to maintain a whole bunch of patches.

Put your code where your foot is.

joseph.olstad’s picture

Yes, blame me for the missing module warning, I was one of the most vocal for this. And yes, I guess I didn't think much about usability because to me it seemed like an admin type of thing that admins should be aware of the files that are missing in their system.

But yes I do agree @crystaldawn that this functionality could and probably should be improved , you've raised some good ideas and feedback.

Lets just make a patch and push that forward, maybe in version 7.54 or 7.55 this could be much easier for admins that have enough on their plate already , we should be making things easy as possible, I agree! So yes, great feedback, now lets make it happen.

donquixote’s picture

A thing I did as a local hack for one Drupal site I work on:
I modified the error behavior to have a look at the stack trace, to find the first function that explicitly mentions the machine name of the missing module. This very often, or perhaps always, identifies the cause. E.g. it identifies if the warning is coming from fields, or from hook_system_info_alter(), or if a module is really missing.
Of course this is currently very hacky, and not suitable at all to commit to Drupal core. But the idea could be followed.

Another useful thing could be to add entries to the "status report" page for missing modules and orphan fields. In general, more report pages for orphan and broken stuff could be nice.

For the hook_system_info_alter() as e.g. in feeds module, I don't really know a good solution. Maybe we could set a flag during module list rebuild, so that the warning message can say "The module list is currently being rebuilt".

I think one main problem is that often the cause of the problem is years ago, and nobody remembers it.

(See also my latest edits to this page)

donquixote’s picture

"have a look at the stack trace"

The idea is to not overwhelm the user (site builder / admin) with the entire stack trace, but show the one function name that is actually relevant. It is a fragile heuristic, though.

travisc’s picture

Plus 1 let's get this patched.

Amani Joseph’s picture

Hi everybody. I come to solicit your help because I need it.
I work on Drupal 7 that I installed locally on Acqui dev desktop and for a few days I have a problem with the display of my nodes. Titles are displayed without the content.
Indeed I wanted to customize the display of my different pages and articles so I installed the Display Suite module that did not work because when I apply the settings nothing appears except the titles. So I had to disable and even uninstall the Display Suite module but the problem still exists. Nothing is still displayed except the titles and even the User Login Fill form is not displayed as well except the title that appears USER ACCOUNT and the form does not appear. But with regards to the administration page such as :( Dashboard Content Structure Appearance People Module Configuration Reports Help) is displayed without problem.
So I need someone to help me solve this problem that has tired me for days. Thank you

JakeRogers’s picture

Amani, Sounds like your problem belongs in another topic post...regardless, I recommend you try "Views" module. It is very intuitive, time tested and powerful in displaying exactly what you need. Good luck.

Jake

Amani Joseph’s picture

Thanks JakeRogers but the problem here is that the content or the body of the nodes does not display it is only the title that appears and the body does not appear. If the body of the different nodes was displayed in this case we could organize it with the view module.

sander-martijn’s picture

he's right that this is not the right place for this. But a suggestion anyway - you should remove ALL non-core modules and themes (just move them out of the way temporarily and then you should be able to log in and clear the cache. If that doesn't work you may have to go into the database and empty (not drop) all tables starting with cache_ - if that still doesn't work you're looking at invasive surgery or starting over ;)

Amani Joseph’s picture

ok THank you very much i'll try.

sander-martijn’s picture

oh and if it does work add things back in one at a time to find the real culprit. If you've already disabled and uninstalled ds it's unlikely it's the culprit of your problems. But if you are still having problems, please start a new topic in an appropriate place, let's not continue this conversation here which is about an entirely different subject.

hstrindb’s picture

Have you checked the Manage Display page. There you decide what will be displayed and what will be hidden.
/admin/structure/types/manage/page/display

karenruth73’s picture

I got this warning the last time I tried to update the core. The modules it was listing are still in use and are up to date. The warnings popped up when I went to the update.php page. I went ahead with the update on my dev site, ignoring the warnings, and the site seems to be behaving itself, but I worry that there is an underlying issue. Any thoughts? Should I be worried?

Pages