Das Putzlowitsch Test- und SEO-Blog

WordPress 2.7 – Wartungsmodus ohne Plugin

Seit WordPress 2.7.x gibt es die Möglichkeit, WordPress selbst aus dem Backend (Admin-Bereich) heraus zu aktualisieren. Damit während des Aktualisierungsprozesses, der je nach Umfang länger dauern kann und möglicherweise eine Datenbankaktualisierung erforderlich macht, auf Grund inkonsistenter Zustände keine Fehler auftreten, versetzt WP sich selbst in einen Wartungsmodus. Der Nutzer, der das Blog aufruft, bekommt einen kurzen Hinweis angezeigt, daß gerade eine Wartung läuft und die Seite bald wieder verfügbar ist.

Diesen Maintenance-Modus kann man ganz ohne WP-Coreupdate auch manuell aktivieren. Vielleicht sind ja irgendwelche Abeiten an der Datenbank erforderlich oder man möchte das Blog aus anderen Gründen vorübergehend vom Netz nehmen.

So funktionierts

WordPress legt beim Start des Aktualisierungsprozesses einfach im WP-Wurzelverzeichnis eine Datei .maintenance an. In der Datei steht nur eine Zeile PHP-Code drin, in welchem die Variable $upgrading mit der Funtion time() den Startzeitpunktes fest zugewiesen bekommt. Nach erfolgreichem Update wird diese Datei einfach wieder gelöscht. Sollte was schief laufen und die Datei ist nach 10 Minuten ab Start immer noch da, wird der Maintenance-Modus beendet und der Admin erhält im Backend einen entsprechenden Hinweis angezeigt.

Um WordPress direkt in den Wartungsmodus zu versetzen, reicht es also, eine Datei mit folgendem Inhalt in das WordPress-Wurzelverzeichnis zu kopieren:

<?php $upgrading = time(); ?>

Am einfachsten ist es, diese maintenance.txt-Datei per FTP in das WordPress-Wurzelverzeichnis zu kopieren und dort in .maintenance umzubenennen.
Das war es schon, ab sofort gibt die Seite nur noch diese Meldung aus:

Die Seite ist ganz kurz nicht erreichbar. In einer Minute sollte wieder alles klappen.

Auch das Backend ist nicht erreichbar, man kann sich also nicht anmelden noch sonst etwas im Adminbereich machen.
Um den Wartungsmodus zu beenden, muß man einfach die Datei .maintenance löschen oder z.B. wieder in maintenance.txt umbenennen.

Wartungsmodus mit Adminzugriff

Nun möchte man aber vielleicht trotz Wartungsmodus auf den Adminbereich zugreifen. Dafür muß man die .maintenance-Datei dahingehend erweitern, daß überprüft wird, ob Seiten aus dem Adminberich oder die wp-login.php aufgerufen wurden. Ich habe das wie folgte realisiert:

<?php
$url_parts = parse_url( $_SERVER['REQUEST_URI'] );
$path_parts = pathinfo( $url_parts['path'] );
$dir_parts = explode( "/", $path_parts['dirname'] );
$dirname = end($dir_parts);
$filename = $path_parts['basename'];

$is_admin =	'wp-admin'==$dirname || 'wp-admin'==$filename;
$is_login =	'wp-login.php'==$filename;

if( $is_admin || $is_login )
	unset( $upgrading );
else
	$upgrading = time();
?>

Download: maintenance admin

Auch hier einfach die ZIP-Datei entpacken, die enthaltene Datei maintenance_admin.txt per FTP in das WP-Wurzelverzeichnis kopieren und in .maintenance umbenennen.

Nun wird beim Aufruf des Blogs der Wartungshinweis angezeigt, man kann sich aber im Backend anmelden und dort alles machen, was sich innerhalb des Admin-Breiches abspielt. Demzufolge funktionieren z.B. aber die Artikelvorschau und die Themevorschau nicht.

Es ist natürlich möglich, weitere Bedingungen zu prüfen und die Zugriffsmöglichkeiten zu erweitern. Man muß aber beachten, das innerhalb der .maintenance-Datei kein Zugriff auf irgendwelche WordPress-Funktionen besteht und man weitestgehend mit dem auskommen muß, was PHP zur Verfügung stellt. So kann man nicht etwa die Anmeldung mit den Nutzerdaten überprüfen, wohl aber das vorhandensein des Anmelde-Cookies.

Wartungsmeldung anpassen

Wem die schlichte Meldung nicht gefällt, die WordPress im Wartungsmodus ausgibt, kann auch hier selbst Hand anlegen. Dazu prüft WordPress, ob es im wp-content-Verzeichnis eine Datei maintenance.php gibt und wenn ja, wird diese anstelle der Standardmeldung geladen und ausgeführt.

Als Beispiel habe ich den Code aus der wp-settings.php genommen und leicht angepaßt:

<?php
	$retry = 120;
	$protocol = $_SERVER["SERVER_PROTOCOL"];
	if ( 'HTTP/1.1' != $protocol && 'HTTP/1.0' != $protocol )
		$protocol = 'HTTP/1.0';
	header( "$protocol 503 Service Unavailable", true, 503 );
	header( 'Content-Type: text/html; charset=utf-8' );
	header( "Retry-After: $retry" );
?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
	<title>Wartungsarbeiten</title>
</head>
<body>
	<h1>Wartungsarbeiten</h1>
	<p>Die Seite ist für kurze Zeit nicht erreichbar. In ein paar Minute sollte wieder alles klappen.</p>
</body>
</html>

Download: maintenance.zip
Die ZIP-Datei entpacken, die enthaltene Datei maintenance.php gegebenfalls nach eigenen Wünschen anpassen und per FTP in das wp-content-Verzeichnis kopieren.

Wichtig ist das korrekte Setzen vom HTTP-Status im Antwort-Header. Für Wartungsarbeiten oder sonstige, zeitweilige Ausfälle sieht HTTP den Status 503 vor. Zudem sollte auch ein Wert für Retry-After gesetzt werden. Ich habe da jetzt 120 Sekunden genommen, es kann aber auch ein konkreter Zeitpunkt eingetragen werde, zu dem das Blog voraussichtlich wieder verfügbar ist.

Nach dem PHP-Block kann man seiner Phantasie HTML-technisch freien Lauf lassen. Aber auch hier gilt, man hat keinen Zugriff auf irgendwelche WordPress-Funktionen.

Fazit

Seit WordPress 2.7 ist es mit einfachen Hausmitteln ohne Plugin möglich, das Blog in einen Wartungsmodus zu versetzen, um Zugriffe während Arbeiten am System oder der Datenbank zu unterbinden. Optional kann auch der Zugriff auf das Backend (wp-admin) gewähleistet werden.

Vorteil dieser einfachen Lösung ist es, daß sie bereits greift, bevor WP selbst geladen wird und auch bevor irgendwelche Zugriffe auf die Datenbank erfolgen. Kleiner Nachteil ist, daß innerhalb der .maintenance-Datei und der optionalen Meldungsseite maintenance.php kein Zugriff auf WordPressfunktionen besteht.

7 Kommentare »

Das neue WordPress 2.7

Ja, ich habe es getan. Ich habe hier auf WordPress 2.7 upgedated. Wenn es schief gegangen wäre, und es ist auch erstmal schief gegangen, wäre es nicht so schlimm gewesen. Das hier ist ja nur das „WordPress bei Strato Testblog“, also zum Testen. Gut, es haben sich in der Zeit seit dem ersten Artikel (der noch nicht mal von mir ist) im Juni 2007 doch einige Beiträge angesammelt, es sind auch durchaus nützliche Plugins enstanden, aber wenn es schief gegangen wäre, hätte ich das verkraften können.

Ja, ich habe auch vorher die Datenbank mit phpMyAdmin gesichert, die neuen WordPress-Dateien per FTP in ein neues Verzeichnis auf dem Server hochgeladen, mit meinem xcopy-Skript alle relevanten Daten der laufenden WP-Installtion (2.5.1) in das neue Verzeichnis übertragen. So hatte ich mein komplettes, altes WordPress sowohl auf Datei- als auch Datenbankeben als Sicherungskopie noch in der Hinterhand, dachte ich zumindest.

Das schöne an dem Kopier-Update-Verfahren ist, man kann einfach durch Umbenennen des Serververzeichnisses auf die neue Version umschalten, und im Fehlerfall auch wieder zurück.
Aber nach dem erforderlichen Datenbank-Update sah alles prima aus. Die neue Adminoberfläche im Backend gefällt mir ausgesprochen gut. Da wollte ich natürlich gleich einen Artikel schreiben, gesagt getan. Doch plötzlich, wie aus heiterem Himmel kommt ein Fehler 500 (schwerer Serverfehler), der schlimmste Fehler, den man sich im Web so vorstellen kann.
Als leidgeprüfter Strato-Nutzer ist man aber auch durch einen 500er nicht wirklich zu erschrecken, den gab es früher oft, wenn man als WP-Neueinsteiger ganz unbeschwert die Permalinks aktiviert hatte. Das war ohne funktionierendes mod_rewrite keine gute Idee. Aber auch das ist nun bei Strato kein Thema mehr.

Weiter lesen (2. Teil)

Keine Kommentare »

Neue WordPressversion 2.5

Der eine oder andere wird es schon bemerkt haben, ich habe von WordPress 2.3.3 auf Worpress 2.5 upgedated. Da bin ich auch relativ unbeschwert rangegangen, da das hier sowieso mehr ein Testblog ist, welches zudem mit den Unzulänglichkeiten des Strato-Webhostings kämpfen muß. Dabei sind es schon erheblich weniger Schwierigkeiten geworden, was Strato und WordPress anbelangt.

So konnte ich hier erstmal testen, ob meine eigenen Plugins funktionieren. Ja, das tun sie. Wobei ich das eine oder andere an die neuen Möglichkeiten von WordPress 2.5 anpassen werde oder schon angepaßt habe. Zudem ist mir grad ein nettes Feature aufgefallen, wenn man Tags (Stichwörter) eingeben will. Dann klappt nach Eingabe von mindestens zwei Zeichen eine Auswahlliste auf, aus der man dann einfach ein passendes, schon vorhandenes Stichwort auswählen kann. Fein Sache, das.

Keine Kommentare »

Neue WordPressversion 2.3.2

Seit vorgestern gibt es die neue deutsche Version 2.3.2 für WordPress der 2.3er Reihe. Es ist im wesenlichen ein Bugfix- und Security-Release, als wurden im wesentlichen Fehler beseitigt und Sicherheitslöcher gestopft. Neue Funktionen wird es wohl erst ab Version 2.4 wieder geben. Benutzern von WordPress 2.3 oder 2.3.1 wird geraten, auf die neue Version upzudaten.
Ähmmm, das betrifft mich hier ja auch, also dann mal ran und frisch upgedated. Bis gleich *wink*

Nachtrag (14:37 Uhr):
Update hat problemlos funktioniert. Bin also wieder up-to-date

Keine Kommentare »

Neue WordPressversion 2.3.1

Seit gestern gibt es die neue deutsche Version 2.3.1 für WordPress der 2.3er Reihe. Es ist im wesenlichen ein Bugfix- und Security-Release, als wurden im wesentlichen Fehler beseitigt und Sicherheitslöcher gestopft. Neue Funktionen wird es wohl erst ab Version 2.4 wieder geben. Benutzern von WordPress 2.3 wird geraten, auf die neue Version upzudaten.
Ähmmm, da ich ja kürzlich, nachdem noch so einige stratospezifische und andere Probleme behoben werden mußte, auf Version 2.3 umgestiegen war, betrifft mich das hier ja auch, also dann mal ran und frisch upgedated. Bis gleich *wink*

Nachtrag (11:13 Uhr):
Update hat problemlos funktioniert. Bin also wieder up-to-date

Keine Kommentare »