Das Putzlowitsch Test- und SEO-Blog

Metaphysik und Müllabfuhr in WordPress 2.9.x

Meta-stase

Durch diese kurze Meldung zu WPMU habe ich erst mitbekommen, daß es in WordPress seit Version 2.9 eine neue Tabelle ‚wp_commentmeta‘ gibt. Für User und Posts gibt es ja schon länger die dazugehörigen Metadaten in wp_usermeta und wp_postmeta. Nun war ich natürlich neugierig, wofür diese neuen Kommentar-Metadaten in WordPress verwendet werden.

Müllabfuhr

MülltonnenEin wichtiger Punkt ist der seit WP 2.9 eingeführte Papierkorb (Trash). Hier werden Artikel, Seiten und auch Kommentare nicht sofort gelöscht, sondern landen zunächst im Papierkorb.

Genau dafür sind diese Metadaten wichtig. Der Trash-Status wird zwar direkt in den Tabellen wp_posts im Feld post_status als ‚trash‘ und wp_comments im Feld comment_approved als ‚trash‘ bzw. ‚post-trashed‘ vermerkt, zusätzlich aber auch in den Metadaten. Neben dem Status wird auch der Zeitpunkt des „Wegwerfens“ in den Mülleimer festgehalten, und dafür gibt es keine Felder in den Post- und Kommentartabellen, dafür werden die Meta-Tabellen auf jeden Fall benötigt. Deshalb gibt es nun eine Tabelle für Comment-Metadaten.

Aber wen interessiert es, wann die Sachen in den Müll gewandert sind? Die WordPress-Müllabfuhr. Die kommt einmal am Tag vorbei und nimmt alles mit, was schon länger als 30 Tage in der Tonne liegt. Man kann ihr aber auch sagen, das sie den Müll schon früher entsorgen soll oder bitte länger liegen läßt. Ein Eintrag in der wp-config.php genügt:

define( 'EMPTY_TRASH_DAYS', 30 );

Die 30 durch die gewünschte Anzahl an Müllvorhaltetage ersetzen.

Metaphorisch

Aber das ist natürlich nicht alles, was man mit den neuen Kommentar-Metadaten machen kann. Genau wie durch die Post-Metadaten bei Artikeln und Seiten ist es nun möglich, nahezu beliebige Daten zu einem Kommentar zu speichern. Der Phantasie sind da kaum Grenzen gesetzt. Denkbar wäre, hier die beliebte Sternchen-Wertung zu einem Kommentar abzuspeichern. Oder ein…, naja, mir fällt im Moment erstmal nichts weiter ein.

Die Funktionen für die Kommentar-Metadaten gibt es genauso wie für Post-Metadaten. Also z.B. update_post_meta -> update_comment_meta, get_post_meta -> get_comment_meta usw. Die Parameter sind praktisch dieselben, außer das dann natürlich nicht die Post-ID, sondern die Comment-ID übergeben wird.

Meta-don

Für Theme- und Pluginentwickler bieten die neuen Comment-Metadaten sicher berauschende Möglichkeiten für ganz neue, tolle und bisher ungeahnte Funktionen mit den WordPress-Kommentaren. :-)

Keine Kommentare »

Was gibt’s Neues? – 123 Tweets

Schnurpsel 123 Tweets
So sieht gerade mein Twitter-Status (Putzlowitsch) aus, also insgesamt habe ich bisher 123 Tweets abgesetzt. Bei „123 Tweets“ sind mir spontan meine WordPress-Plugins eingefallen, die ich auch immer „123 Irgendwas“ nenne. Da müßte ich jetzt also mal ein Twitter-Plugin entwickeln, daß ich dann „123 Tweets“ nennen kann.

Ich weiß zwar noch nicht genau, was das Plugin machen wird, aber eine Idee habe ich schon. Da ich Twitter bisher im wesentlichen als Linkschleuder für meine Blogartikel verwende, könnte ich das doch gleich automatisieren. Wenn ich einen neuen Artikel publiziere, wird wird gleich ein entsprechender Tweet abgesetzt. Na mal sehen…

Ein Kommentar »

BornToBeASeo – ein Plugintest

borntobeaseo

Eigentlich will ich für diese Anfrage nur testen, ob das 123 Moderate Comment Notification-Plugin auch unter WordPress 2.8.x funktioniert. Da mir kein sinnvolles Thema eingefallen ist, muß nun wieder einmal borntobeaseo für den Test herhalten.

123 Moderate Comment Notification

Mit diesem Plugin kann man festlegen, wer alles eine E-Mail erhält, falls ein Kommentar z.B. zu borntobeaseo freigeschaltet werden muß. Normalerweise bekommt nur der Admin eine solche E-Mail. In Multiautorenblogs kann es aber sinnvoll sein, das auch die Autoren selbst Kommentare (sofern sie berechtigt sind) zu ihren eigenen Beiträgen moderieren, damit der Admin entlastet wird.

borntobeaseo – bitte jetzt kommentieren :-)

Damit ich nun sehe, ob tatsächlich auch Babsi eine E-Mail bekommt, muß hier jetzt bitte jemand einen Kommentar zu borntobeaseo hinterlassen. Danke!

Keine Kommentare »

Das Ende der WordPress-Hacker

Wordpress 2.8 - Einstellungen > VerschiedenesFällt Euch bei dem Bild hier links (anklicken zum Vergrößern) etwas auf? Es zeigt die Einstellungs-Seite für „Verschiedenes“ der neuen WordPress-Version 2.8. Diese kann man sich vorab schon herunterladen und testen. Darauf gestoßen bin ich beim WordPress-Deutschland Blog im Artikel „WordPress 2.8 Feature Freeze„. Und da dachte ich mir so, schau ich mir die neue Vorabversion von WordPress 2.8 doch schon mal an. Auf den ersten Blick und nach dem Durchklicken aller Menüpunkte im Adminbereich (Backend) habe ich so auf die Schnelle keine wesentlichen Änderungen entdecken können.

Nur gaaaanz unten, auf der letzten Einstellungsseite „Verschiedenes“ traf mich fast der Schock. Die Option

[x] Die veraltete my-hacks.php-Datei unterstützen

ist verschwunde. Ein schwerer Schlag ins Kontor, für mich als bekennenden Fan der my-hacks.php-Datei.
Nachtrag: Hier findet man, warum es dazu kam.

Gut, wenn man die Option nicht mehr im Backend einstellen kann heißt das ja noch nicht unbedingt, daß sie nicht mehr vorhanden ist. Und tatsächlich, die Option ‚hack_file‘ gibt es noch immer und die my-hacks.php wird in wp-settings.php auch noch geladen, sofern die Option aktiv ist. Allerdings ist die von mir getestete Version von WordPress 2.8 eine noch recht frühe Version, also nicht Beta oder gar RC. Wenn alles schief läuft, fliegt die Unterstützung für die my-hacks.php doch noch ganz raus, was ich sehr bedauern würde.

Vielleicht überlebt sie aber doch noch im Hintergrund und für diesen Fall habe ich schnell ein kleines Plugin geschrieben, welches die Option wieder auf der Einstellungsseite „Verschiedenes“ zum Leben erweckt läßt :-)

Download: Plugin 123 Hackfile Option 0.12

Weitere Artikel mit Bezug zu diesem:
2 Kommentare »

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 »