web-dev-qa-db-fra.com

Comment déplacer les 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 'filename'.

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

7installing
34
Logi

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

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

Cependant, 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 le registry_rebuild commande pour drush:

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

J'ai restauré une sauvegarde de la production localement et j'ai essayé de déplacer les choses 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 a du sens pour moi car certains modules peuvent utiliser des inclusions ou quoi que ce soit dans leur hook_init (), ou vous pouvez avoir un chemin de routeur de menu défini qui dépend d'un module ou inclure cela Drupal ne peut pas trouver sur bootstrap. En fin de compte, c'est ce que j'ai fait (vos chemins peuvent être différents):

Étape 1: Remplacez 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 les modules d'espaces 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éplacer les modules de développement vers les sites/tous/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: effacer les caches pour que les choses soient bootstrap 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 comme LoginToboggan pour gérer 403 (accès refusé) et que vous vous êtes déconnecté pendant ce processus, vous devrez peut-être mettre à jour le include_file colonne dans le menu_roter table pour utiliser le nouveau chemin du fichier include. 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 ces requêtes exécutées - ce qui ne prendra qu'une fraction de seconde - appuyez sur admin/config/development/performance et videz le cache afin que les chemins de menu soient reconstruits.

10
Charlie Schliesser

Essayez l'outil cool de Mark Sonnabaum: Drush Rebuild Project Paths . Il automatise le processus; a très bien fonctionné pour moi. Utilise Drush , bien sûr.

Je soutiendrai la suggestion d'essayer cela sur une copie de la base de données de votre site.

9
greg_1_anderson

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.

7
jonhattan

Tout d'abord, toujours sauvegardez votre base de données, si simple à faire, vous vous couperez les pieds si quelque chose ne va pas et que vous n'avez pas sauvegardé.

Je ne sais pas si cela importe si vous désactivez les modules ou non; vous voudrez peut-être le faire, au cas où. Ensuite, faites ceci:

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

Terminé! Drupal recherchera tous les modules installés.

5
John Laine

Pourquoi n'essayez-vous pas le module Registry Rebuild . Cela a fonctionné à chaque fois pour moi.

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

Il y a des moments dans Drupal 7 lorsque le registre est irrémédiablement arrosé et vous devez reconstruire le registre (une liste de PHP et les fichiers avec lesquels ils vont)) Parfois, cependant, vous ne pouvez pas effectuer cette activité régulière de suppression de cache car une classe est requise lorsque le système tente de démarrer.

4
drupalastic

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

Fondamentalement, vous procédez comme suit:

  1. Déplacez vos modules vers un autre répertoire et
  2. La reconstruction du registre reconstruira ensuite la table système pour placer les modules au bon endroit.

Je l'ai d'abord appris/découvert via DrupalEasy Podcast # 1 , ce qui explique davantage comment ce module/drush cmd peut être utilisé.

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

3
Pierre.Vriens

J'ai eu quelques problèmes avec drush dl ne fonctionne pas en raison des problèmes de répertoire du module. En général, j'aime les réponses de pile que je peux simplement coller pour que les choses fonctionnent. Vous trouverez ici quelques lignes qui installeront Drush Rebuild Registry et l'exécuteront sur votre site si vous êtes 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
2
kqw

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 modules personnalisés vers un autre dossier de modules personnalisés lors du transfert FTP vers le serveur. Ils travaillaient tous les deux. Drupal semblait l'avoir reconnu comme un module séparé même s'il était dans le dossier d'un autre module. Je n'ai pas eu à désactiver le module.

** Ce module que j'ai déplacé n'avait PAS de fichier .install donc je ne sais pas si cela compte.

2
Exziled

Visitez/admin/build/modules, il reconstruira les chemins dans la table système. Parfois drupal ne peut plus bootstrap plus 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 ajouter la nouvelle commande drush avant de casser bootstrap cependant. Pour ajouter la nouvelle commande, consultez le readme ' s Section COMMANDES

2
Zatox

Il est recommandé de déplacer vos modules dans les sous-dossiers contrib/dev/patched/custom. Il n'y a cependant aucun gain de performance, cela se 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 en ligne. Vous devez ensuite vider les caches. Si vous n'utilisez pas drush et constatez que vous ne pouvez plus accéder à la page d'effacement du cache, vous devrez visiter /update.php ou tronquer manuellement les tables de cache. Je n'ai jamais eu à faire 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 comme l'API d'entité peut nécessiter la reconstruction du registre. Consultez la page registry_rebuild .

1
gbyte.co

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

La désactivation du module n'est pas simple non plus si vous devez déplacer quelque chose comme l'API d'entité qui est requise par des tonnes d'autres modules dans Panopoly.

Pour résoudre ce problème, pour l'API d'entité, 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
1
ergophobe

Drupal 7

Essayez d'abord 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 le tableau qui contient toujours les anciennes informations sur le chemin par:

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 effacer les caches dans Drupal?

Vous pouvez également 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");
1
kenorb