I have a test module located under site/all/modules/custom. First, I did uninstalled the module, cleared cache. then , I did moved the test module to modules/custom folder which is a new location to put Drupal 8 module.

After that, I have enabled the test module, then Clear All Caches. Now, Drupal 8 keeps says can not find the test module under old location (site/all/modules/custom).

I thought Drupal 8 probably stored path in a DB table, but i am unable to find the table. Can any one tell a solution about How to fix above problem?

  • Did you uninstalled the module? Before moving module, you have to uninstall it, so that any entry related to it in db get removed. After that you should move it to other location – Dev Jan 7 '16 at 4:18
  • Late but for anyone else coming here: There is no DB table for enabled modules, it's all in the config files. – Adaddinsane Jan 7 '19 at 9:48

You can do this without uninstalling, but it takes some fiddling:

  1. Move the module in filesystem
  2. invoke drush ev "drupal_flush_all_caches();"
  3. invoke drush cr

The crucial setting is the entry system.module.files in key_value database table. If you move the module(s), the try to run drush cr directly, it may fail because drush tries a full bootstrap and fails to locate the required files.

drush ev does an error-free bootstrap using drush_bootstrap_max(), and drupal_flush_all_caches rebuilds system.module.files config without trying (and failing) to load the moved files. Whereas drush cr does a full-site bootstrap, which causes drush to halt on any errors.

  • 3
    Good explanation. This one worked together with a restart of my webserver to clear the APC cache. – berliner May 8 '17 at 14:29
  • I tried this after the other suggestion here to create a file to clear the APC cache. This method didn't work for me. Drupal 8.4.2. I think the comment from berliner worked because rebooting the server cleared the APC cache. – millionleaves Nov 11 '17 at 19:35
  • Nothing is working: drupal_flush_all_caches(); drush cr; sudo service apache2 restart; pc_clear_cache(); $settings['class_loader_auto_detect'] = FALSE;... in any order. When I try to move the views_bootstrap module from contrib to sites/mydomain/modules i got In DiscoveryTrait.php line 53:The "views_bootstrap_grid" plugin does not exist. – Baud Mar 19 '19 at 8:41
  • 1
    This commands works for me, but I needed to restart apache and add $settings['class_loader_auto_detect'] = FALSE to my settings.php – Christophe CARON Dec 18 '19 at 15:26

You don't need to re-install, a cache clear after moving a module should be enough. If not, then you might not actually have cleared the caches?

  • 2
    This worked for me, except I had to also explicitly clear the APC file cache as well. – Brian Mar 30 '17 at 14:18
  • This does not work if I move module from modules/custom folder to profile. – milkovsky Mar 23 '18 at 17:33
  • That should work if that profile rally is active. Certainly done that. I suggest you create a new question and explain what exactly isn't working, if you have an error or so – Berdir Mar 23 '18 at 20:02
  • We had to clear opcache as well php.net/manual/en/function.opcache-reset.php – milkovsky Mar 27 '18 at 9:00
  • 1
    When trying to clean cache from UI Drupal (Configuration >> Performance), right after moving the module folder, I got an internal server error (500). But by running >> drush cr from command line, everything went fine and no errors occurred. – Marcos Buarque Jun 21 '18 at 19:13

I had the same problem promoting a module from custom to contrib. The key for me was clearing the (APC) autoloader cache in combination with the Drupal cache.

I think I ended up with uninstalling the module, drush cr, and then forcing an autoloader cache invalidation (by sticking this file in the webroot and pointing the browser to it):

<?php apc_clear_cache();

following by another drush cr for good measure, and then finally reenabling the module.

Here's some background from Pantheon about the APC: https://pantheon.io/docs/alternative-php-cache/

  • Note that you might need to use apcu_clear_cache(); instead. You should be able to simply drush php-eval "apcu_clear_cache();" No need to uninstall/reinstall. – Mrweiner Oct 2 '19 at 21:31

this added to local.settings.php did the trick for me:

 * Class Loader.
 * If the APC extension is detected, the Symfony APC class loader is used for
 * performance reasons. Detection can be prevented by setting
 * class_loader_auto_detect to false, as in the example below.
$settings['class_loader_auto_detect'] = FALSE;

i guess restart the server or empty apc cache would have done the trick too


You can add To your settings.local.php

$settings['deployment_identifier'] = 'ANY CUSTOM STRING';

this is used by acquia/blt to clear the container cache. According to the blt documentation in code:

 * Deployment identifier.
 * Drupal's dependency injection container will be automatically invalidated and
 * rebuilt when the Drupal core version changes. When updating contributed or
 * custom code that changes the container, changing this identifier will also
 * allow the container to be invalidated as soon as code is deployed.

Paths are more a matter of Registry than a matter of Cache; In Operation systems and other systems, the Registry (like the Windows registry) is the the path registry similar to a "Civil registry" of a certain city or country.

Thus, I would recommend to rebuilding the registry with the module Devel, or with Drush.

In Drupal 7 what I did when I couldn't run devel or drush from technical reasons of the moment was to truncate the registry tables in the site's database in phpmyadmin.


Tried the above and nothing seemed to work for me. In the end I went into the database for my D8 site and truncated all the tables starting with 'cache_' and that did the trick - perhaps this will help someone else.


ahebrank's answer of creating a php file in the root of your Drupal instance to clear the APC cache is the least invasive method I've found to achieve this since it only affects that Drupal instance.

Another option is to restart Apache followed by drush cr, which has the same result but obviously has an impact on any other sites on the same server.

In my case, I needed to move all of the contrib modules in my Drupal instance from modules/ into modules/contrib/. This resulted in a 500 error on my site. I don't know which module caused the 500 error, but it wasn't practical to uninstall and reinstall all of my modules.


I would try uninstalling the module before moving it.

Just put the module back in it's original location and uninstall it with "drush pm-uninstall" or by using the "Uninstall" tab on the "Extend" page in the admin UI. You should be able to move it after these steps.

  • Option 2:

Too lazy to look it up on the workstation, if D8 is like D7 you will have a system table in the database with an entry for your module, you can just delete the entry where name="yourModuleName" and re-install your module.

  • 1
    D8 doesn't have the system table, so that trick which worked in D7 doesn't work in D8. Per aaronbauman, above, modules are in the key_value table now. (But I didn't have a system.module.files entry, nor could I find anyplace that showed the location of those modules, just that they're installed on the site.) – Kelley Curry Dec 6 '18 at 16:21

Not the answer you're looking for? Browse other questions tagged or ask your own question.