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

34

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?

Logi
la source

Réponses:

27

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
Cyclonecode
la source
Si je le comprends bien, vous pouvez également tronquer votre registry_filetable, ce qui forcera drupal à analyser à nouveau tous les fichiers et à reconstruire la table.
Cyclonecode
3
Tronquer la table semble être une mauvaise idée et entraînera probablement un site totalement endommagé.
Berdir
@Berdir - Convenez que cela semble être une mauvaise idée. Mais, juste essayé et semble fonctionner. J'ai d'abord fait une sauvegarde et tronqué la table entière en utilisant DELETE FROM registry_file;et ajouté un appel à rebuild_registry()mon page.tpl.php.
Cyclonecode
C'est trop compliqué, faites ce que John Laine a dit, ça a toujours fonctionné pour moi.
Jim Kirkpatrick
1
@JimKirkpatrick - Vous avez raison, il n'est pas nécessaire de désactiver les modules.
Cyclonecode
10

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.

Charlie Schliesser
la source
Merci pour cela! J'ai essayé les étapes mentionnées dans les réponses principales, mais cela n'a pas aidé dans mon cas. Je suppose que tout le monde sur un site hébergé par Pantheon doit effectuer ces déclarations sous forme de base de données dans votre réponse, puis effectuer les opérations "drush registry-reconstruire" et "drush cc registry"
Anne Bonham le
Oh, et sur Pantheon, je ne pouvais pas obtenir un site avec le module Redis ailleurs que dans sites / all / modules - alors j’ai abandonné et laissé ce module dans le dossier des modules racine. Ah bien - au moins mes autres modules sont bien organisés.
Anne Bonham
Pour ceux qui utilisent LoginToboggan, voici les 3 commandes MySQL dont vous aurez besoin:update menu_router set include_file = 'sites/all/modules/contrib/logintoboggan/logintoboggan.admin.inc' WHERE path = 'admin/config/system/logintoboggan'; update menu_router set include_file = 'sites/all/modules/contrib/logintoboggan/logintoboggan.validation.inc' WHERE path = 'toboggan/revalidate/%'; update menu_router set include_file = 'sites/all/modules/contrib/logintoboggan/logintoboggan.validation.inc' WHERE path = 'user/validate/%/%/%';
tyler.frankenstein
9

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.

greg_1_anderson
la source
7

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.

jonhattan
la source
C’est ma méthode préférée de déplacement des modules. Certains modules activés sites/all/modulesdevaient être déplacés vers un contribsous-répertoire. Tout ce que je devais faire étaitdrush dl registry_rebuild; mv OLD_PATH/module NEW_PATH/module; drush rr
Sumeet Pareek
Cela a fonctionné pour moi. J'ai d'abord déplacé tous mes modules puis j'ai fait le registry_rebuild
gerl
Fait intéressant, drush rr --fire-bazookaconduit à des erreurs, mais drush rrc'est bien.
Alex Skrypnyk
5

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.

John Laine
la source
+1 pour le mode de maintenance, toujours agréable de le faire avant quelque chose comme cela
Cyclonecode
1
Cela provoque des erreurs fatales 100% du temps pour moi. Peut-être que cela fonctionne si vous déplacez des modules qui n'ont pas de dépendances ou quelque chose.
ergophobe
4

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.

drupalastique
la source
Bien que cela puisse théoriquement répondre à la question, il serait préférable d’inclure ici les parties essentielles de la réponse et de fournir le lien à titre de référence. S'il existe une procédure de déplacement de modules incluant l'utilisation du module que vous avez lié, veuillez la décrire.
Mołot
Aucune théorie ... ça marche. Suivez les instructions sur la page. J'ai utilisé la méthode drush et cela a juste fonctionné.
Illin
3

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

Pierre.Vriens
la source
3
Je seconde ceci. Site de sauvegarde. Déplacez tous les modules dans de nouveaux dossiers. Exécutez la reconstruction du registre dans drush ou suivez simplement les instructions et naviguez jusqu'au fichier php inclus pour l'exécuter. Simple.
Collins
2

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.

Zatox
la source
2

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
fifi finance
la source
2

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.

Expulsé
la source
Le fichier d'installation ne concerne que les procédures appelées lors de l'installation du module et n'est pas obligatoire. Cela a fonctionné parce que vous pouvez avoir n'importe quelle structure de dossiers sous / sites / all / modules, drupal recherchera les fichiers .info de manière récursive.
gbyte.co
@ gbyte.co merci pour la clarification à ce sujet! Je connaissais le fichier d'installation, mais je ne connaissais pas le processus récursif de drupal consistant à rechercher des fichiers .info. J'ai pensé que le sous-dossier dans lequel ils se trouvaient n'avait pas d'importance, mais il est bon d'avoir une réponse solide!
Exziled
1

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
ergophobe
la source
1

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");
Kenorb
la source
1

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 .

gbyte.co
la source
-4

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.

lexicant
la source
5
C'est un casse-tête d'entretien à long terme
AgA
ceci est un hack et fait le tour de la solution ... pas une bonne solution.
Illin
Eh bien, il vaut mieux utiliser drush registry_rebuild maintenant qu'il est disponible.
lexicant