3 Wege WordPress zu deaktivieren

Gestern habe ich mir mal ein bisschen angeschaut, welche meiner Beiträge eigentlich am beliebtesten sind und festgestellt, das unter den Topbeiträgen meine „Deaktiviere dies“-, „Deaktiviere das“-Beiträge sind.

Daraus entstanden diese Tweetserie

https://twitter.com/websupporter/status/838113060791402498

Ich ging erst mal Schlafen und als ich heute morgen aufwachte, dachte ich mir, vielleicht adressiere ich ja die falsche Crowd und gehe einfach zu destruktiv mit WordPress um. Ich sollte vielleicht einfach mehr über „Wie Du X aktivierst“ oder „Wie Du Y anwendest“ schreiben und hatte mir sogar schon ein Thema zurecht gelegt, bis ich dann in meine Timeline guckte und sah, dass Robert, Thorsten und Heiko schon Vorschläge hatten, wie WordPress am besten deaktiviert wird. Nie um einen kleinen Clickbait verlegen lege ich also meine guten Vorsätze beiseite und geb der Crowd, was die Crowd verlangt.

„How to deactivate WordPress“ – Ein nicht ganz ernst gemeinter Beitrag zur Debatte.

Vorbemerk: Etliche Vorschläge in diesem Beitrag führen dazu, dass Dein WordPress nicht mehr zu erreichen ist. Das ist sozusagen das Ziel. Wenn Du weißt, was Du tust, probiere es gerne aus, aber beschwere Dich später nicht „David hat mein WordPress kaputt gemacht“; das warst Du. Wenn Du willst, dass ich es fixe: Ich berechne 80 Euro + Umsatzsteuer für jede angebrochene Stunde.

Heiko schlägt im Wesentlichen vor, einfach den Linux Server herunterzufahren.

Meiner Meinung nach ist das ganz schön brutal und passt nicht ganz in mein Clickbait-Schema. Aber vielleicht ja mal ein Artikel „Wie ich meinen Linuxserver gegen die Wand fuhr“? Außerdem Heiko: Was passiert denn, wenn auf dem Server noch ne Drupal-Installation läuft. Derartige Kollateralschäden würde ich gerne vermeiden. Die Leut drüben bei Drupal sollten wir da nicht mit rein ziehen.

Bleiben die zwei Vorschläge von Thorsten und Robert. Robert schlägt vor, einfach die globale $wpdb in der init-Aktion auf null zu setzen. Traut sich aber nicht mal im Tweet, das zu aktivieren (Hashtag: Hashtag).

Thorsten geht das nicht weit genug; er radiert einfach gleich sämtliche globalen Variablen aus. Die mag der einfach nicht.

Ich hab mir beide Vorschläge mal angeschaut und bin damit nicht so glücklich. Erstens ist WordPress nicht deaktiviert, sondern läuft ja einfach weiter und Zweitens krieg ich auch noch jede Menge PHP Notices und Errors. Das ist doch keine saubere Enterprise-Lösung für unser kleines, dreckiges Problem.

Evaluieren wir also noch einmal, welche Möglichkeiten uns zur Verfügung stehen:

Ein erster Weg WordPress zu deaktivieren. Der Maintenance mode

WordPress verfügt über einen eingebauten „Maintenance mode“, den wir für unsere Zwecke missbrauchen könnten. Relativ am Anfang der wp-settings.php wird die Funktion wp_maintenance() aufgerufen, welche prüft, ob im Root-Verzeichnis von WordPress eine .maintenance-Datei rumliegt. Setzt diese auch noch die Variable $upgraded auf einen Timestamp der nicht älter als zehn Minuten ist, verabschiedet sich WordPress. Was mir an diesem Ansatz gefällt ist, dass er sehr früh im System ausgeführt wird und also WordPress relativ früh deaktiviert. Was mir weniger gefällt ist, dass wir uns dazu via FTP auf dem Server einloggen müssen, um die Datei hochzuladen. Das ist einfach keine gute UX 😞. Aber trotzdem, eine solche Datei würde ihren Dienst tun:

WordPress deaktivieren mit der .htaccess

Wir könnten argumentieren, dass WordPress gar nicht richtig deaktiviert ist, weil das System ja immer bis zu einem bestimmten Punkt durchläuft, während hingegen ein deaktiviertes Plugin überhaupt nicht mehr ausgeführt wird. Auf der anderen Seite gibt es ja einen Unterschied zwischen Deaktivieren und Löschen. „Logge dich mit FTP ein, lösche alle WP-Dateien aber achte darauf, nicht den wp-content/-Ordner, oder zumindest den uploads/-Ordner zu löschen“ ist somit ein anderes Thema. Aber: Wir könnten über die .htaccess gehen. Hier gibt es verschiedene Strategien. Ich habe mich dazu entschieden, statt auf die index.php auf eine index.html umzuleiten. (Ich setze hier einmal voraus, dass in diesem Ordner und den Unterordnern nur WordPress läuft und nicht noch irgendwo Drupal 😂) Das ganze sähe dann in etwa so aus:

WordPress mit Hilfe eines Plugins deaktivieren

Aber auch für diese Lösung müssen wir auf FTP zurückgreifen und irgendwie ist das nicht so richtig WordPressy. Nein, Thorsten und Robert haben Recht, es sollte doch ein Plugin sein, aber dann doch bitte eines, welches so früh wie möglich einsteigt. Das ist das schöne an Thorstens all-Filter. Ich hatte an die plugins_loaded gedacht, doch allem Anschein nach hat sich das Thorsten auch gedacht und dann kurz nachgeschaut und festgestellt, dass all vor dem spezifischen plugins_loaded ausgeführt wird. Für ein Plugin ist all der Hook der Wahl. Man könnte natürlich auch einfach ohne Hooks arbeiten, aber bitte mal: Das ist dreckig.

Was mir nicht in den Kopf geht: Warum schlagen Beide danach vor, globale Variablen zu löschen? Gut, ich verstehe die Antipathie ihnen gegenüber, aber sich dafür solche Notices einzufangen. Nein, lieber nicht. Ich gehe lieber mit wp_die(). Man könnte auch die() oder exit; nehmen, um noch weniger WP-Code auszuführen, aber hey:

Fazit

Mit gefällt die Plugin-Lösung am Besten. Das Plugin könnte noch ein wenig Liebe vertragen, so dass man WordPress auch wieder aktivieren könnte, ohne das Plugin vom Server zu löschen. Aber für einen ersten groben Entwurf denke ich, langt es. Wie würdest Du WordPress am „geschicktesten“ deaktivieren? Musstest Du WordPress schon einmal deaktivieren und wenn ja, warum?