Moving module location [duplicate]

Question

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?

Answer 1

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.

Answer 2

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/

Answer 3

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?

Answer 4

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

Answer 5

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

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.