Dans Drupal 7, je pouvais éditer manuellement le {system}
table dans la base de données pour désactiver un module stubbon. Dans mon site Drupal 8, ce tableau a disparu.
Comment puis-je désactiver manuellement un module dans Drupal 8?
Les données de la table Drupal 7 system
sont désormais stockées dans la table config
dans Drupal 8 contre la core.extension
paramètre.
Solution 1: Mettre à jour la configuration
Vous pouvez exécuter le code suivant à l'aide de drush eval
ou peut utiliser la disposition du module Devel pour Execute PHP Code
.
// Read the configuration.
$module_data = \Drupal::config('core.extension')->get('module');
// Unset the modules you do not need.
unset($module_data['MODULE_NAME']);
// Write the configuration.
\Drupal::configFactory()->getEditable('core.extension')->set('module', $module_data)->save();
Vous pouvez tout faire dans une ligne rapide avec drush
.
drush eval "\$module_data = \Drupal::config('core.extension')->get('module'); unset(\$module_data['MODULE_NAME']); \Drupal::configFactory()->getEditable('core.extension')->set('module', \$module_data)->save();"
Solution 2: Modifier la table de configuration si vous ne pouvez pas exécuter PHP
Si le site est en panne à cause du module problématique et que vous ne pouvez même pas exécuter PHP, alors vous pouvez peut-être modifier directement la table config
.
Dans la ligne de la table config
où name = "core.extension"
et modifiez la colonne BLOB data
. Le data
est un tableau sérialisé PHP où vous devez supprimer le module dont vous voulez vous débarrasser de la clé module
de la configuration.
Solution 3: Solution rapide et sale
cache_config
Cependant, cette solution peut entraîner des messages indiquant que le module n'existe pas dans le système de fichiers, ce qui signifie que quelque chose ne va pas. Mais au moins le module cassé est désactivé et vous pouvez accéder à votre site dans la plupart des cas.
Vider le cache
Parfois, vous devrez peut-être vider le cache après avoir suivi les étapes ci-dessus. Lisez cette pratique documentation sur la façon de vider le cache .
config
où name = 'core.extension'
et retirez le module du blob de données qui est un tableau sérialisé.(...s:6:"module";a:HERE;{...)
cache_config
table de phpmyadmin ou en utilisant la ligne de commande.Faites ceci:
rm -rf modules/your_stubborn_module
rm -rf sites/default/files/php
Dans Drupal 8, essayez de supprimer le module de votre dossier de modules et exécutez rebuild.php.
Essayez drush pm-uninstall module-name
ainsi que.
Si vous devez mettre à jour tout ce qui concerne la configuration Drupal, dans ce cas core.extension
, utilisez Drush:
[Drush 8.x dans cet exemple]
drush cedit core.extension
Pensez à utiliser Drush. Drupal 8 définit toujours ce que doit être "la désactivation des modules". Il y a discussion en cours s'il doit y avoir cette option ou si elle doit être supprimée.
J'ai essayé toutes les autres réponses mais j'ai continué à recevoir un message d'erreur drupal. Pour le résoudre, j'ai dû supprimer une ligne de la table key_value (recherchez le nom du module dans la colonne nom))
Il y a un module pour ça. Ce module a été publié en août 2013 sur drupal.org. Au cas où quelqu'un en aurait besoin.
Comme indiqué sur la page de ce module,
Drupal 8 a supprimé la possibilité de désactiver les modules pour de nombreuses raisons. Voir # 1199946: Les modules désactivés sont cassés au-delà de toute réparation, donc la fonctionnalité "désactiver" doit être supprimée et de nombreux autres problèmes dans la file d'attente des divers modules de base et contribués.
Ce module ramène la possibilité de désactiver (temporairement) des modules de l'interface utilisateur ou avec Drush. Notez qu'il n'y a aucune garantie pour votre contenu, votre configuration ou même votre site après avoir désactivé un module.
Voici comment, j'ai supprimé manuellement un module nommé "better_messages" de mon Drupal 8. Dès que j'ai installé le module "better_messages", le site est tombé en panne. Il n'y avait donc aucun moyen de désinstaller le module de l'interface utilisateur. Je n'ai pas installé Drush. J'ai fait de nombreux paramètres donnés dans les forums, mais c'est comme ça que ça a finalement fonctionné pour moi.
1 Renommé le module en old_better_messages dans le dossier modules.
Grâce à l'URL, a exécuté http: // IP: port/nom de dossier/rebuild.php . Cela a assuré que le site est de retour, mais uniquement en mode lecture seule. Je ne pouvais pas faire les activités d'administration ou modifier les articles.
Utilisé la commande suivante pour supprimer l'entrée de la base de données
DELETE FROM key_value WHERE collection = 'system.schema' AND name = 'better_messages';
Dans mon cas, il n'y avait aucune entrée dans la base de données. Je pense qu'il a peut-être été supprimé à cause des divers cascades que j'ai faites plus tôt.
Cela a résolu le problème. Ceci est basé sur mon interprétation de https://www.drupal.org/node/2487215
Réponse de Jigarius ci-dessus, en quelque sorte travaillé ...
Je devais: // Lire la configuration.
$module_data = \Drupal::config('core.extension')->get()['module'];
Ce qui devrait faire la même chose. Je ne sais pas pourquoi cela n'a pas fonctionné comme Jigarius l'a écrit ...