How to fix "The following module is missing from the file system..." warning messages

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 point-and-click, administrative interface provided by drupal.org contrib modules.
       Option #1 - Module Missing Message Fixer
       Option #2 - Missing Module
    2. Use Drush

       For example, run a command similar to the following:

       drush sql-query "DELETE from system where type = 'module' AND name IN ('old_module1','old_module2');"
       

       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/9/10
    1. Enable devel module and on the administrative interface go to /devel/config, edit core.extension delete missing module entry.
    2. Use the point-and-click, administrative interface provided by drupal.org contrib modules.
       Option #1 - Module Missing Message Fixer
    3. Use Drush

       drush sql-query "DELETE FROM key_value WHERE collection='system.schema' AND name='module_name';"

       drush config:delete core.extension module.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).

    4. 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:

       /**
        * Fix long lost modules are missing from the filesystem.
        */
       function MYMODULE_update_8100(&$sandbox) {
         $modules = [
           'old_module1',
           'old_module2',
           'old_module3',
         ];
         \Drupal::database()->delete('key_value')
           ->condition('collection', 'system.schema')
           ->condition('name', $modules, 'IN')
           ->execute();
       }
       

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,
• Restart the server, since Apache may cache paths. Or,
• Move the module back to its original location in the file system.

Since Apache APC caches paths, Drupal may still try to find the module at the old location, even after clearing caches. If you don't have control over Apache on shared hosting, try uncommenting the $settings['class_loader_auto_detect'] = FALSE; string in settings.php, which disables APC cache detection, and clear caches. See also #3540339: Rebuild all caches, including APCu, when clicking "Clear all caches".

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.

Your installation profile driven site has a "missing" module that won't go away? Check the info file.

If you've removed a module from an installation profile's codebase, and you've removed the entries from the system table with a missing module solution, but you still have modules showing up, check the profile's info file. Make sure that the "missing" module has been removed from your installation profile's .info file (usually as a dependency).

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.

When a path is being mistaken for a module look for cases where the path might be given as a module. For example:

/**
 * Implements hook_views_api().
 */
function example_views_api() {
  return array(
    'api'  => 3,
    'path' => drupal_get_path('module', 'example/views'),
  );
}

when it should be

/**
 * Implements hook_views_api().
 */
function example_views_api() {
  return array(
    'api'  => 3,
    'path' => drupal_get_path('module', 'example') . '/views',
  );
}

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.