Module deaktivieren für Upgrade mit phpmyadmin
Eingetragen von bernadotte (45)am 29.12.2009 - 17:38 Uhr in
Das Deaktivieren und Wiederaktivieren von nicht-Core Modulen gehört ja zum Standardprozedere für einen Versionswechsel, blos scheint sich bisher niemand auf Drupal.org tiefere Gedanken gemacht zu haben, wie man diesen nervigen und sehr zeitraubenden Prozess beschleunigen kann (bzw. diesen Prozess einmal zu dokumentieren).
Das Deaktivieren bzw. Reaktivieren über das Webinterface ist bei einer gewissen Menge an Modulen ja nicht ernsthaft der Königsweg.
Jaja, jetzt kommt bestimmt gleich wieder der "Drush" daher, aber nicht jeder Anfänger, der ja seine Seite schließlich auch sauber halten soll, kommt damit zurecht bzw. hat überhaupt die Möglichkeit des Einsatzes (technisch und wissenstechnisch).
Man kann, wie auch auf drupal.org beschrieben, Module per phpmyadmin deaktivieren (siehe http://drupal.org/node/157632)
Nur ist dort lediglich der Prozess zum Deaktivieren eines bestimmten Modules beschrieben, für den Upgrade sollen aber alle zusätzlichen Module stillgelegt werden.
SELECT name,status FROM system WHERE type='module';
UPDATE system SET status='0' WHERE name='module_name';Problem hier:
- man muss sich erst mal die Liste der Module kopieren oder ausdrucken, um die Namen richtig eingeben zu können.
- man muss für jedes Modul den Prozess einzeln abarbeiten
- zum Aktivieren nach dem Upgrade das Ganze dann nochmal.
Bestimmt ist das schneller als übers Webinterface, aber trotzdem noch ziemlich gaga.
So, langer Rede kurzer Sinn:
Ich habe vor langer Zeit mal einen Blogschnipsel mit sql-Syntax irgendwo aufgeschnappt, der das ganze Deaktivieren und Aktivieren lächerlich einfach und schnell gemacht hat. Nur finde ich das nicht mehr.
Da meine sql-Kenntnisse ziemlich rudimentär sind, deshalb nun Versuch mit ein paar Willigen einen schönen Standard-SQL-Satz zu entwicklen, der sich dann auch in einem Handbuch wiederfinden könnte.
Das Aktivieren/Deaktivieren der Module erfolgt über den Eintrag in "status" als 1 und 0.
Alles was ich bisher gelesen hatte, ging darum, die 1 in die 0 umzuwandeln.
Wenn man diesen Prozess auf alle Module anwendet, sind auch alle deaktiviert, also auch die core-Module, was ja nicht erwünscht ist.
Die core-Module befinden sich, im Gegensatz zu den contributed im Verzeichnis /modules z.b.
modules/node/node.module
Die zusätzlichem Module befinden sich dagegen z.B. in
sites/all/modules/fivestar/fivestar.module
Also muss man eigentlich nur diejenigen Module filtern, die sich nicht im Verzeichnis "modules" befinden.
So, damit hätte man auf einen Rutsch alle nicht-Core-Module deaktiviert und kann fröhlich seinen Upgradeprozess fortführen.
Doch wie bekommt man die Ausgangslage wiederhergestellt? Doch nen Liste drucken?
Der Schreiber des nicht mehr auffindbaren Blogs hatte da eine "geniale" Idee:
Statt auf 0 hat er den Status auf -1 gesetzt.
Denn offensichtlich wird beim Modulstatus nicht darauf geachtet ob er 0 ist, sondern ob er 1 ist.
Mit dem Setzen der zuvor auf 1 stehenden Module auf -1 kann also das Modul deaktiviert werden, und zugleich ein Marker gesetzt werden, welche der vielen Module überhaupt aktiviert war, denn die zuvor inaktiven bleiben schließlich 0!
Um den Prozess dann wieder umzukehren, müssen schließlich in einem zweiten sql-Satz alle Module mit dem Status -1 wieder auf 1 gesetzt werden, und fertig ist das.
So, wer hat jetzt Lust mir und uns mal schnell die zwei SQL-Zeilen nach meinem Geschwurbel aufzusetzen?
Gruß
Bernd
- Anmelden oder Registrieren um Kommentare zu schreiben
so, wie üblich antworte ich
am 29.12.2009 - 23:41 Uhr
so, wie üblich antworte ich mir selber.
Habe mich dann doch mal an das sql gewagt.
Mein obiger Ansatz funktioniert nur zum Teil, weil ich was Wichtiges vergessen hatte:
Der Autor dem ich nacheifere hatte nicht den status-Wert als Marker benutzt (-1 als Modulstatus hat keinen Effekt und das Modul bleibt aktiv), sondern er hatte (wenn ich mich jetzt recht erinnere) den throttle-Wert dafür benutzt.
Dies funktioniert natürlich nur, wenn man seine Module nicht drosselt (was bei den meisten Kleinseitenbetreibern wohl auch nicht viel bringen würde)
Also, Voraussetzung für das wieselflinke Ab- und Anschalten aller Zusatzmodule per phpmyadmin, um den Upgrade-Prozess von einer Drupalversion z.B. 6.14 zu 6.15 erheblich zu beschleunigen geht nur, wenn man keine Zusatzmodule gedrosselt hat.
Aber ich denke es ist einfacher ein paar throttle-Haken neu zu setzen, als sich auf das langwierige Modulaktiviergeklicke einzulassen.
Aber dann könnte es so funktionieren:
/*SQL-Skript zum Deaktivieren aller Nicht-Core-Module in Drupal, z.B. für das Upgrade zu einer neueren Version*/UPDATE system SET status='0' , throttle='1' WHERE type='module' AND filename NOT LIKE 'modules%' AND status ='1'
Diejenigen Einträge in der Tabelle "system", die den Typ "modul" haben, die nicht im Verzeichnis "modules" für die Core-Module sind, und die aktiv sind, werden per status='0' deaktiviert.
Als Markierung für das zuvor aktive Modul wird der throttle-Wert auf 1 gesetzt.
Nach dem erfolgreichen Update des Core kann man nun ebenso leicht die vorher aktiven Module wieder anschalten:
/*SQL-Skript zum Reaktivieren aller zuvor deaktivierten Nicht-Core-Module*/UPDATE system SET status='1' , throttle='0' WHERE throttle='1'
Die Module, bei denen zuvor der throttle-Wert auf 1 gesetzt wurde erhalten wieder status='1' und der throttle-Wert wird auf 0 zurückgesetzt.
Vielen Dank fürs Lauschen meiner Selbstgespräche und einen guten Abend.
ts ts ts, hat wieder keiner
am 30.12.2009 - 18:45 Uhr
ts ts ts, hat wieder keiner aufgepasst ;)
Natürlich habe ich im letzen Post total Schrott verzapft, und keiner merkts, weil hier eh niemand was liest.
Huhu, jemand da?
Naja, ich bin ja noch da ... mein Schatz ... golummm ...
Habe heute mal eine sehr vernachlässigte Testseite auf 6.15 gebracht, und wollte mein sql-Skript zur Anwendung bringen.
Da ich schon etwas aus der Übung bin, hab ich natürlich nicht gemerkt, dass ich mit meinem Skript zwar schon alle Module deaktiviere, dummerweise aber auch den eigentlichen Kern ... und das kann wohl nicht funktionieren.
Aber man weiß Rat und ergänze das Skript eben um eine Aussnahme für die Kern-Module.
Und das sieht dann so aus:
/*SQL-Skript zum Deaktivieren aller Nicht-Core-Module in Drupal, z.B. für das Upgrade zu einer neueren Version*/UPDATE system SET status='0', throttle='1' WHERE type='module' AND filename NOT LIKE 'modules/block%'
AND filename NOT LIKE 'modules/filter%'
AND filename NOT LIKE 'modules/node%'
AND filename NOT LIKE 'modules/system%'
AND filename NOT LIKE 'modules/user%'
AND status ='1'
Dies hat zuverlässig alle optionalen und Fremdmodule deaktiviert
Am Reaktivierungaufruf hat sich nichts geändert:
/*SQL-Skript zum Reaktivieren aller zuvor deaktivierten Module*/UPDATE system SET status='1' , throttle='0' WHERE throttle='1'
Also, ich bin damit zufrieden.
Mich würde aber trotzdem interessieren wie denn der 08-15-Drupaler von der Strasse seine Upgrades bewältigt.
Habe ich irgendein Supertool übersehen, oder klickt Ihr Euch alle bis zur Verblödung durch die Modulseite?
bernadotte schrieb Also,
am 30.12.2009 - 18:54 Uhr
Also, ich bin damit zufrieden.
Mich würde aber trotzdem interessieren wie denn der 08-15-Drupaler von der Strasse seine Upgrades bewältigt.
Habe ich irgendein Supertool übersehen, oder klickt Ihr Euch alle bis zur Verblödung durch die Modulseite?
Hallo.
Diese Moduldeaktivierung und Reaktivierung brauche ich doch nur bei einem Upgrade (z.B. von 5.x auf 6.x) von daher stellt sich das Problem eher selten. (Siehe z.B. auch: http://drupal.org/upgrade/tutorial-introduction#comment-1819492 und der folgende Comment).
Jedenfalls habe ich bei den Updates (Update != Upgrade) noch keine Module deaktiviert.
Gruß
JThan
_____
Meine private Seite: http://durstich.de
--> http://is.gd/C9Pb - Drupal Themes Showroom <--
Alle Angaben in meinen Beiträgen sind stets ohne Gewähr und auf eigenes Risiko für bare Münze zu nehmen.
Mhm, also ich halte mich an
am 31.12.2009 - 01:57 Uhr
Mhm, also ich halte mich an den Upgrade.txt, und da gibt es keine wirkliche Unterscheidung zwischen "Updates" und "Upgrades" und im Tutorial das zu deinem Link gehört wird von major und minor releases gesprochen und keine Unterscheidung im Bezug auf das deaktivieren der Module gemacht.
Im weiteren sollen bei major releases aber die Module gleich ganz entfernt werden.
Da es für mich keine offizielle Unterscheidung gibt, und somit alles Upgrades sind, sollte man sich dann doch eigentlich auch an die einzige verfügbare Anweisung, den Upgrade.txt halten.
Kann ja gut sein das es in den meisten Fällen nichts ausmacht, wenn man die Module nicht deaktiviert hat, oder wie beim letzten Upgrade, bestimmte Module nur im aktivierten Zustand durch die update.php laufen, dennoch verstehe ich nicht wie man aus den verfügbaren Quellen eine Nichtbefolgung des Upgrade.txt ableiten kann.
Ich bin vielleicht etwas paranoid was das angeht, aber ich habe einfach keinen Bock was zu zerschiessen und es erst zu merken wenns zu spät ist und ich es eh nicht mehr fixen kann. Dafür ist mir die ganze Angelegenheit zu komplex.
Ja im Artikel oben wird das
am 31.12.2009 - 10:21 Uhr
Ja im Artikel oben wird das wohl so beschrieben. Bevans Kommentar würde ich aber genau so sehen.
Wenn du sicher gehen willst, dann machst du eh eine Testinstallation deiner Seite, spielst dort die Updates ein und testest ausführlich ob sich Probleme ergeben bevor du die LiveInstallation erneuerst.
Gruß
JThan
_____
Meine private Seite: http://durstich.de
--> http://is.gd/C9Pb - Drupal Themes Showroom <--
Alle Angaben in meinen Beiträgen sind stets ohne Gewähr und auf eigenes Risiko für bare Münze zu nehmen.
ist ja witzig. ich aktiviere
am 31.12.2009 - 10:24 Uhr
ist ja witzig. ich aktiviere und deaktiviere auch immer wie verrückt...laut der .txt in den Files eben.
das kann ich mir also sparen? auf 6.15 habe ich "upgedated" ohne auf ein CoreTheme zurückzusetzen...ist dann wohl
genauso überflüssig - hat nämlich gut funktioniert....
Aber nicht mich beschuldigen
am 31.12.2009 - 10:35 Uhr
Aber nicht mich beschuldigen wenn es mal nicht funktioniert!
Wie gesagt: Am besten erst in einer Testinstallation prüfen, ob das funktionert. Aus meiner Erfahrung heraus hat es bisher für mich bei meinen Installationen immer geklappt, dass ich ohne Deaktivierung der Module updaten konnte.
Gerade wurde hierzu auch ein neuer Thread eröffnet: http://www.drupalcenter.de/node/23988
Über die Suche lässt sich dazu bestimmt auch einiges finden.
Gruß
JThan
_____
Meine private Seite: http://durstich.de
--> http://is.gd/C9Pb - Drupal Themes Showroom <--
Alle Angaben in meinen Beiträgen sind stets ohne Gewähr und auf eigenes Risiko für bare Münze zu nehmen.