Oxid Module deaktivieren ohne Zugriff auf den Admin-Bereich

Im Zuge eines Server-Umzugs hatte ich heute das Vergnügen keinen Zugriff auf Backend und Frontend in Oxid zu haben. Der Server wies meine Anfrage mit einem 502 Error ab. ich fand im Error-Log der Node vermehrt folgenden Eintrag:

[core:notice] AH00052: child pid 10603 exit signal Segmentation fault (11)

Nach einigen weiteren Tests, und der traurigen Gewissheit einer defekten Modulkette, blieb es mir leider nicht erspart die die installierten Module im Shop zu deaktivieren.

Mmmmh…wie war das doch gleich?

mks

Ansatz A – the bad way

  • Alle Module aus dem Ordner source/modules/ in bspw. source/modules_{temporärerName}/ temporär kopieren/umbenennen
  • /tmp leeren
  • myshop.de/admin öffnen
  • Erweiterungen > Module

Zurück im Admin wird uns Oxid nun über fehlerhafte Module informieren und fragen, ob wir diese zurücksetzen wollen. Wenn wir das wirklich wollen, dann sind somit alle Modul-Einstellungen flöten gegangen. Bei einem Test-Shop mit 3 Modulen ist das ärgerlich, aber nicht wirklich wild. In der Realität tümmeln sich in den großen Oxid Installationen auch gerne mal 20-30 Module und mehr … Na dann Prost-Mahlzeit! Die wollen jetzt alle wieder installiert und konfiguriert werden.

Ansatz B – Alle Module per SQL deaktivieren

Solange Du Zugriff auf die Shop-Datenbank hast, können alle Module mit dem folgenden SQL-Befehl deaktiviert werden.

delete from oxconfig where oxvarname in ('aModulesHistory','aModuleVersions','sUtilModule','aDisabledModules','aLegacyModules','aModuleFiles','aModulePaths','aModules','aModuleTemplates');

Tmp Ordner leeren … et voliá … Der Zugriff auf das Backend ist wieder möglich, und die Module können wieder aktiviert werden.

Weitere Ansätze

Es gibt bereits diverse gute Ansätze zum Thema Oxid Debugging und Fehlerbehebung, die sich allerdings in der technischen Umsetzung stark unterscheiden. Für den technisch nicht so versierten Anwender reicht da eventuell ein kleines „Notfall-Skript“, daß einfach per FTP hochgeladen werden kann, um ein akutes Problem zu lösen.

Im täglichen Umgang mit Oxid hat sicherlich jeder seine eigenen kleinen „Helferlein“, ganz abhängig von Architektur und Komplexität der Anwendung. Es gibt aber diverse, immer wiederkehrende Prozesse und Aufgaben, die gut über ein „Tool-Set“ abzubilden wären.

Leider hat da jeder sein eigenes Süppchen gekocht, und Oxid stellt kein eigenes Tool bereit. Das mag daran liegen daß solche Tools aus der Not heraus entwickelt werden um schnell ein Problem zu lösen, oder weil man sich ärgert mit Dingen Zeit zu verlieren die einfach zu automatisieren gewesen wäre. Das Thema Entwickler-Tools für Oxid in aller Ausführlichkeit aufzuführen, würde an dieser stelle den Rahmen sprengen und ist sicherlich einen eigenen Beitrag wert.

Zwei weitere Varianten zur Lösung des Kernproblems, Module zu deaktivieren ohne Admin Zugriff, möchte ich hier kurz aufführen:

oxrun – CLI Toolset für Oxid

Oxrun ist ein sehr spannendes und hilfreiches Command-Line-Interface Toolset für Oxid basierend auf Symfony und Composer.

So können z.B. Module per Kommandozeile aktiviert, deaktiviert und repariert werden. Die Installation ist simpel und gut dokumentiert.

Ich setze das oft bei der lokalen Entwicklung ein. Wer viel für Oxid entwickelt, und sich eh gerne in der Kommandozeile rumtreibt, sollte hier unbedingt einen Blick drauf werfen.

Das Original-Projekt ist kompatibel bis Oxid 4.10.x und liegt auf Github.

https://github.com/marcharding/oxrun

Code-Beispiel

oxrun module:activate mymodule 
oxrun module:deactivate mymodule 
oxrun module:fix mymodule 
oxrun module:list

Stefan Moises hat in seinem Fork das Projekt bereits auf Oxid 6 portiert und um weitere Kommandos ergänzt.

https://github.com/smxsm/oxrun

Script zum Deaktivieren / Bearbeiten und Reparieren von Moduleinträgen

Hebsacker hat dazu im Oxid Blog ein kleines Script veröffentlicht. Voraussetzung ist allerdings ein funktionierendes Shop-Frontend, in dem man sich als Admin einloggen kann. Für Module-Updates die „nur“ den Admin zerschossen haben, mag das eine gute Möglichkeit sein schnell einen Fehler zu beheben, habe ich aber noch nicht getestet.

Wenn durch einen falschen / fehlerhaften Moduleintrag das Backend nicht mehr zugänglich ist, oder ein Modul einen Fehler verursacht, dann kann man durch dieses Script diese Einträge via Frontend bearbeiten und rückgängig machen.

Hebsacker – Oxid Forum

Moduleinträge via Frontend bearbeiten / reparieren / deaktivieren



Replies

  1. Sollte geändert werden in:

    Ansatz A – the bad way

    • Alle Module aus dem Ordner source/modules/ in bspw. source/modules_{temporärerName}/ temporär kopieren/umbenennen
    • /tmp leeren
    • myshop.de/admin öffnen
    • Erweiterungen > Module

    Hintergrund:

    Es besteht die Gefahr, dass Anwender die Dateien von bspw.
    source/modules/vendor/moduleid/
    in
    source/modules/vendor_/moduleid/
    oder
    source/modules/vendor/moduleid_/
    umbenennen.
    Bei der Rückbenennung kann der Shop (ich glaube in der aktuellen Version ist das behoben) die geänderten Pfade mit den Id’s nicht mehr korrekt verarbeiten.

  2. Ist geändert. Danke für den Hinweis.

  3. Immer alle Module wieder zu aktivieren, ist nervig. Meist tritt der Fehler ja auf, wenn man ein Modul erstellt, bearbeitet etc.pp. Hebsackers Skript kann man “ein wenig” anpassen :


    Wer’s braucht: Rubberpack

Continue the discussion at --> OXID forums

Participants