14

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?

2
  • 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, 2016 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. Jan 7, 2019 at 9:48

9 Answers 9

27

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.

6
  • 3
    Good explanation. This one worked together with a restart of my webserver to clear the APC cache.
    – berliner
    May 8, 2017 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. Nov 11, 2017 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, 2019 at 8:41
  • 2
    This commands works for me, but I needed to restart apache and add $settings['class_loader_auto_detect'] = FALSE to my settings.php Dec 18, 2019 at 15:26
  • 1
    Another way is implementing hook_update_N or hook_post_update_NAME with empty function body, and running either drush updb or /update.php in browser. This will also flush_all_caches without full Drupal bootstrap. Jan 9 at 13:05
10

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/

2
  • 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, 2019 at 21:31
  • 1
    @Mrweiner drush php-eval "apcu_clear_cache();" did not work, calling it from the browser did. See drupal.stackexchange.com/a/302585/104586.
    – Raman
    May 27, 2021 at 21:12
7

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?

5
  • 2
    This worked for me, except I had to also explicitly clear the APC file cache as well.
    – Brian
    Mar 30, 2017 at 14:18
  • This does not work if I move module from modules/custom folder to profile.
    – milkovsky
    Mar 23, 2018 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, 2018 at 20:02
  • We had to clear opcache as well php.net/manual/en/function.opcache-reset.php
    – milkovsky
    Mar 27, 2018 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. Jun 21, 2018 at 19:13
7

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.
 */
6

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

1

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.

1
  • cache_container is the one.
    – mortona42
    Aug 13 at 18:14
1

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.

1

Paths are more a matter of registry than cache.

Thus, I would recommend to rebuild the registry with the Devel Devel or with Drush. In Drupal 7 what I did when I couldn't run them was to truncate the registry database tables with PHPMyAdmin.

-2

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
  • 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.) Dec 6, 2018 at 16:21

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