[gelöst] Module über Datenbank deaktivieren

Da es sich primär um Konfiguration handelt, die auch gecacht wird, sind wahrscheinlich mindestens zwei Tabellen betroffen. Aber das Module auch Tabellen anlegen und verändern können beim Installieren sowie weitere Konfiguration importieren können und auch abhängige Module dazu installiert haben können, kann ein Task das manuell nachzuvollziehen in der Datenbank sehr kompliziert sein und sehr viel Wissen über den betroffenen Code benötigen. Das heißt für mich klingt der Task viel komplizierter, als mal eben Drush zum Laufen zu bringen und das damit zu erledigen. Das heißt gerade Anfänger würde ich erst recht abarten, die Datenbank direkt anzufassen. Das System via Git zu pflegen, mit Klonen zu testen etc. ist dazu auch generell noch anzuraten.
Da Composer hier noch in Böhmen verirrt ist, würde ich auch darauf tippen, daß Libraries, die das Modul wahrscheinlich benötigt auch nicht mit installiert wurden. Evtl. reicht auch ein Drush allein nicht aus, um sich aus dieser Situation wieder sauer heraus zu winden.

Ich bin mir dessen bewusst, dass dies wahrscheinlich keine "schöne" Lösung ist. Es ist aber die einzige, die ich mir mit meinem begrenzten Know How zutraue. Ich bin aber absolut offen für Alternativen, wenn mich da jemand an die Hand nehmen könnte.
Es spricht auch nichts dagegen das Modul einfach richtig zum laufen zu bringen, was das Problem ja ebenfalls lösen würde. Mir fehlen da nur leider die Ansätze. Um in Böhmen zu bleiben: Vielleicht sehe ich auch einfach den Wald vor lauter Bäumen nicht.... ;)

Was heißt keine "schöne Lösung". Das Risiko, die Situation massiv zu verschlimmern ist meiner Ansicht nach riesig.

Es gibt ja den Begriff "gefährliches Halbwissen". Das unterstellt aber noch 50% Wissen. Hier würde ich eher von 5% sprechen auch bei denjenigen, die zu dieser Vorgehensweise raten. Wenn das ein sinnvoller Weg wäre (vor allem noch für Drupal 10), würde es dazu eine offizielle Anleitung geben.

Nachdem wir nun festgestellt haben, dass meine Kompetenz nicht die höchste ist, würde ich mich freuen, wenn jemand einen konkreten Lösungsansatz hat. Deswegen schreibe ich ja hier im Anfängerforum..... ;)

Wie Carsten bereits geschrieben hatte, birgt ein Eingriff über die Datenbank gewisse Risiken. Ich würde zuvor auf jeden Fall die Datenbank sichern und dabei auch sicherstellen, dass das Backup funktionsfähig ist (durch Test).

Dein Modul deaktivierst du über die Datenbank folgendermaßen:

1) Informationen zu aktivierten Modulen sind in der Tabelle key_value im Feld collection mit dem Wert system.schema gespeichert.
2) Werte löschen: Finde den Eintrag für das "Barcodes"-Modul in der key_value-Tabelle. Hier löschst du die komplette Zeile.
3) Cache-Tabellen leeren. Der Cache muss geleert werden, damit modulspezifische Einträge in den Cache-Tabellen entfernt werden. Nachdem die Seite unbenutzbar ist und drush nicht zur Verfügung steht, bleibt nur das händische Leeren aller Cache-Tabellen (alle Tabellen, die im Namen mit "cache_" beginnen). Achtung: Nicht löschen, sondern nur leeren!
4) Manchmal speichern Module ihre Konfiguration in den config-Tabellen, wie config und config_snapshot. Obwohl das Deaktivieren des Moduls in der key_value-Tabelle normalerweise ausreichend sein sollte, können sich Reste von Modulkonfigurationen in diesen Tabellen finden. Also ggf. auch hier händisch Einträge entfernen.

Das Problem kann sein, daß diese Versuche den Anschein erwecken können, man hat erfolgreich ein problem gelöst hat. D.h. es könnten versteckte Fehler zurück bleiben, die erst später wieder auftauchen können. Trotz Einsatz von Composer und Drush bin ich früher schon in folgenden Falle geraten:
Nach erfolgreichen Tests in "Klonen" hatte ich auf einem Produktiv-System ein Modul aktiviert auch mit Drush (ohne Fehlermeldung). Nachdem es dann doch Probleme gab, hatte ich den Code wieder in vorherigen Stand gebracht und dann die Datenbank aus dem vorherigen Backup wieder eingespielt. Alles funktioniert dann super, aber nachdem ich auf besagten Klon-Test-Systemen die anderen Probleme mit dem Modul gelöst hatte, und alles komplett reibungslos funktioniert hatte, stand dann ein neuer Rollout an. Bei dem versuch das Modul dann zu aktivieren gab es einen Datenbankfehler.
Passiert war folgendes: Bei der ersten Modul.Installation wurden Tabellen angelegt. Im Backup-SQL File existierten diese nicht. Und weil ich vor dem Einspielen des Backups nicht die Datenbank zuvor gelöscht hatte, bleiben diese Tabellen erhalten beim Wiedereinspielen des Backups. Die Drupal Installations-Routinen überprüfen leider nicht auf solche schon existierenden Tabellen und damit bricht der Installationsvorgang ab. Folglich muss man wieder abrechen, Backup wieder herstellen (das nun buggy Tabellen enthält) und einen Reparatur-Prozess vorberieten, der sich aber nur auf das manuelle Löschen der überflüssigen Tabellen konzentriert.
Wie schon erwähnt halte ich die Strategie des manuellen Anpassens für komplizierter, als sich dem Problem mit Composer und Drush zu nähern, auch wenn man das erst lernen muss.

Erst einmal vielen Dank für eure Hilfe und Geduld.
Ich konnte das Problem anderweitig lösen. In einem Beitrag auf Drupal.org gab es folgenden Hinweis:

Genau das habe ich ausprobiert und siehe da, ich kam wieder auf meine Seite und konnte das Modul deinstallieren.

Vielen Dank und ein schönes Wochenende an alle.

Du hast die Datei "barcodes.module" umbenannt und dann den Deinstallations-Prozess auslösen können? Damit kannst Du Glück gehabt haben, je nachdem wie sauber der Deinstallations-Prozess dann noch laufen konnte. Wenn Du aber nur das Modul aus Deiner Code-Base raus genommen hast, dann schlummert da auf jeden Fall noch ein Problem in der Datenbank.

Genauso war es. Die Deinstallation lief sauber durch und bisher sind auch keine weiteren Probleme erkennbar. Nochmals vielen Dank für die Hilfe.

Ich war der Meinung ich konnte früher als Themenersteller das Thema als gelöst markieren. Geht das nicht mehr oder übersehe ich da etwas?

Prima, freut mich für dich. Als gelöst markieren kannst du deinen Beitrag indem du den Betreff deines Ursprungsposts bearbeitest und beispielsweise ein [gelöst] voranstellst.