Comment déplacer des modules installés de / sites / all / modules / * vers / sites / all / contrib / modules / *

J'ai cherché les réponses à cette question sans aucune chance. D'après ce que j'observe dans la structure de la base de données, l'emplacement des modules est spécifié dans la table 'système'. La seule solution que j'ai est d'écrire une requête SQL pour mettre à jour la colonne 'nom de fichier'.

Existe-t-il une solution meilleure / plus propre pour résoudre ce problème, par exemple un module contrib?

Il vous suffit de déplacer vos modules vers votre nouvel emplacement et de reconstruire le registre. Lorsque le registre reconstruit, le chemin d'accès aux modules sera mis à jour. Vérifiez registry_rebuild().

Réanalyse tout le code dans les modules ou inclut les répertoires, stockant l'emplacement de chaque interface ou classe dans la base de données.

Bien que, je vous recommande de sauvegarder votre base de données avant de tester cela.

Si vous utilisez drush, vous pouvez également reconstruire le registre à l'aide de la commande suivante:

drush cc registry

Vous pouvez également installer la registry_rebuildcommande pour drush:

// install registry_rebuild
drush dl registry_rebuild
// rebuild the registry
drush rr

J'ai restauré une sauvegarde de la production localement et j'ai essayé de déplacer des éléments et d'appuyer sur admin / modules ou d'exécuter registry_rebuild (), mais cela n'a pas empêché la génération d'erreurs fatales. Cela me semble logique car certains modules peuvent utiliser includes ou quoi que ce soit dans leur hook_init (), ou vous pouvez avoir un chemin de routeur de menu qui dépend d'un module ou d'une inclusion que Drupal ne trouve pas au démarrage. En fin de compte, voici ce que j’ai fait (vos chemins peuvent être différents):

Étape 1: Remplacer les sites / all / modules par sites / all / modules / contrib

UPDATE system SET filename = REPLACE(filename, 'sites/all/modules', 'sites/all/modules/contrib');
UPDATE registry SET filename = REPLACE(filename, 'sites/all/modules', 'sites/all/modules/contrib');
UPDATE registry_file SET filename = REPLACE(filename, 'sites/all/modules', 'sites/all/modules/contrib');

Étape 2: remplacez sites / all / modules / contrib par sites / all / modules / custom pour des modules d'espacement de noms personnalisés

UPDATE system SET filename = REPLACE(filename, 'sites/all/modules/contrib', 'sites/all/modules/custom') WHERE name LIKE 'my_custom_namespace_%';
UPDATE registry SET filename = REPLACE(filename, 'sites/all/modules/contrib', 'sites/all/modules/custom') WHERE name LIKE 'my_custom_namespace_%';
UPDATE registry_file SET filename = REPLACE(filename, 'sites/all/modules/contrib', 'sites/all/modules/custom') WHERE filename LIKE '%my_custom_namespace_%';

Étape 3: Déplacez les modules de développement vers des sites / all / modules / dev.

UPDATE system SET filename = REPLACE(filename, 'sites/all/modules/contrib', 'sites/all/modules/dev') WHERE name LIKE 'devel%';
UPDATE registry SET filename = REPLACE(filename, 'sites/all/modules/contrib', 'sites/all/modules/dev') WHERE name LIKE 'devel%';
UPDATE registry_file SET filename = REPLACE(filename, 'sites/all/modules/contrib', 'sites/all/modules/dev') WHERE filename LIKE '%devel%';

Étape 4: Vider les caches pour que les choses démarrent correctement

TRUNCATE TABLE cache
TRUNCATE TABLE cache_bootstrap
TRUNCATE TABLE cache_menu
TRUNCATE TABLE cache_page
TRUNCATE TABLE cache_path

Remarque: Si vous utilisez un module personnalisé ou une contribution telle que LoginToboggan pour gérer 403 (accès refusé) et que vous vous êtes déconnecté au cours de ce processus, vous devrez peut-être mettre à jour la include_filecolonne de la menu_rotertable pour utiliser le nouveau chemin du fichier à inclure. . C'est probablement un événement rare.

UPDATE menu_router SET include_file = 'sites/all/modules/custom/my_custom_namespace/includes/foo.inc' WHERE path = 'access-denied'

Une fois que ces requêtes ont été exécutées (ce qui ne prendra que quelques secondes), lancez admin / config / development / performance et effacez le cache afin que les chemins de menus soient reconstruits.

Essayez l’outil génial de Mark Sonnabaum: Drush Rebuild Project Paths . Il automatise le processus. a bien fonctionné pour moi. Utilise Drush , bien sûr.

J'appuierai cependant l'idée que vous essayez ceci sur une copie de la base de données de votre site.

Pour mémoire, il existe une excellente commande drush pour reconstruire le registre: http://drupal.org/project/registry_rebuild

Il y a beaucoup d'informations dans la page du projet.

Tout d’abord, sauvegardez toujours votre base de données, si simple à faire que vous vous ferez bien cogner si quelque chose ne va pas et que vous ne sauvegardez pas.

Je ne sais pas si le fait de désactiver les modules ou non importe peu; vous voudrez peut-être le faire, juste au cas où. Alors fais ceci:

1. Mettez votre site en mode maintenance à l'adresse (nom du site) / admin / config / development / maintenance
2. Déplacez physiquement vos modules dans le système de fichiers.
3. Effacez vos caches sur (nom du site) / admin / config / development / performance ou réenregistrez simplement la page de vos modules.

Terminé! Drupal effectuera une nouvelle recherche pour tous les modules installés.

Pourquoi n'essayez-vous pas le module de reconstruction du registre . Cela a fonctionné chaque fois pour moi.

Voici une citation à ce sujet (à partir de la page de projet du module):

Dans Drupal 7, il arrive que le registre soit irrémédiablement isolé et qu'il soit nécessaire de le reconstruire (liste des classes PHP et des fichiers associés). Parfois, cependant, vous ne pouvez pas effectuer cette activité de nettoyage du cache régulière car une classe est requise lorsque le système tente de démarrer.

Vous pouvez utiliser le module Registry Rebuild , qui s'intègre à Drush via la Drush RRcommande.

En gros, vous procédez comme suit:

1. Déplacez vos modules dans un autre répertoire et
2. Registry Rebuild reconstruira ensuite la table système pour placer les modules au bon endroit.

J'ai d'abord appris / découvert via DrupalEasy Podcast # 133 , qui explique plus en détail comment utiliser ce module / drush cmd.

PS: Bien sûr, effectuez d'abord une sauvegarde de votre site ...

Visit / admin / build / modules, il reconstruira les chemins dans la table système. Parfois, drupal ne peut plus démarrer, donc cette solution ne fonctionne pas dans ce cas. Si cela ne fonctionne pas, vous pouvez utiliser Drush Rebuild Project Paths comme indiqué dans une réponse précédente. Vous devez cependant ajouter la nouvelle commande drush avant de casser bootstrap. Pour ajouter la nouvelle commande, consultez la section COMMANDS du fichier Lisez -moi.

J'ai eu du mal à drush dlne pas travailler à cause des problèmes de répertoire du module. En général, j'aime les réponses en pile que je peux simplement coller pour que les choses fonctionnent. Vous trouverez ici quelques lignes qui permettront d’installer Drush Rebuild Registry et de l’exécuter sur votre site si vous vous trouvez déjà dans le répertoire de site approprié.

pushd ~  # good if drush on your site is broken because of moved modules
drush dl -y registry_rebuild
popd 
drush rr

Je ne suis pas sûr à 100% d'une vraie réponse drupal-esk mais d'après mon expérience:

J'ai accidentellement déplacé l'un de mes dossiers de module personnalisé vers un autre dossier de module personnalisé lors de l'envoi FTP au serveur. Ils travaillaient toujours tous les deux. Drupal semblait l'avoir reconnu comme un module séparé alors même qu'il se trouvait dans le dossier d'un autre module. Je n'ai pas eu à désactiver le module.

** Ce module que j'ai déplacé N'A PAS de fichier .install, je ne suis donc pas sûr que cela compte.

Les distributions Drupal ne gèrent pas bien cela, donc récemment, après avoir accidentellement fini avec une copie de l' API Entity danssites/all/ sur un site Panopoly, rien de tout cela travaillé. La reconstruction du registre, le chargement de la page des modules et tout le reste ont provoqué une erreur fatale.

Désactiver le module n'est pas simple non plus si vous devez déplacer quelque chose comme l'API d'entité, requis par des tonnes d'autres modules de Panopoly.

Pour résoudre ceci, pour Entity API, vous feriez quelque chose comme ceci:

1. Mettez à jour le chemin dans la table système:

   UPDATE `system` 
     SET `filename` = REPLACE(
       `filename`, 
       'sites/all/modules/entity', 
       'profiles/panopoly/modules/contrib/entity'
     );

2. Reconstruisez ensuite le registre:

   drush rr

Drupal 7

Tout d'abord essayer drush rr.

Si cela ne fonctionne pas, après avoir déplacé les fichiers, essayez les commandes Drush suivantes dans votre répertoire racine Drupal:

drush sqlq "TRUNCATE cache; TRUNCATE cache_bootstrap;"
php -r "define('DRUPAL_ROOT', getcwd()); require_once DRUPAL_ROOT . '/includes/bootstrap.inc'; drupal_bootstrap(DRUPAL_BOOTSTRAP_SESSION); registry_rebuild(); registry_update(); cache_clear_all();"
drush -y cc all

Si ci-dessus ne fonctionne pas, trouvez la table qui contient toujours les anciennes informations sur le chemin en:

drush --ordered-dump sql-dump | grep "sites/all/modules" # Change the path to the old one.

Si aucun n'est trouvé, cela signifie que c'est votre cache externe.

Si oui, n'oubliez pas de les redémarrer, par exemple:

killall -HUP memcached
drush eval "function_exists('xcache_clear_cache') && xcache_clear_cache();"

Voir plus: Quelle méthode est utilisée pour vider les caches dans Drupal?

Sinon, vous pouvez essayer les requêtes MySQL suivantes après avoir déplacé les fichiers:

UPDATE system SET filename = REPLACE(filename, "sites/all/modules", "sites/newplace/modules") WHERE
       filename LIKE "sites/all/modules/%" AND type = "module"
       AND name IN ("my", "module", "whose", "path", "changed");

UPDATE registry SET filename = REPLACE(filename, "sites/all/modules", "sites/newplace/modules") WHERE
       filename LIKE "sites/all/modules/%"
       AND module IN  ("my", "module", "whose", "path", "changed");

Il est recommandé de déplacer vos modules dans les sous-dossiers contrib / dev / patched / custom. Il n'y a aucun gain de performance, cependant, cela est fait pour des raisons pratiques et esthétiques. Cela facilitera la vie des futurs développeurs.

Vous pouvez déplacer la plupart des modules contrib vers des sous-dossiers sans problème sur un site actif. Vous devriez vider les caches après. Si vous n'utilisez pas drush et trouvez que vous ne pouvez plus accéder à la page d'effacement du cache, vous devrez visiter /update.php ou tronquer manuellement les tables du cache. Je n'ai jamais eu à faire que le dernier bit lors du déplacement du module API d'entité.

Le déplacement des modules de base est techniquement possible, mais je ne le recommanderais pas et je ne vois aucune raison valable de le faire.

Mise à jour: le déplacement de modules tels que l'entité API peut nécessiter une reconstruction du registre. Consultez la page registry_rebuild .

Vous pouvez simplement ajouter un lien sym dans le répertoire sites / all / modules pointant vers sites / all / contrib. Je ne sais pas si cela résoudra votre problème. Il existe également d'autres solutions, notamment le profil d'installation ou un fichier drush make. Je ne sais pas assez pour fournir des détails sur eux, mais au moins c'est une direction que vous pouvez regarder.