Eine zum jeweils aktuellen Chart passende Map liegt im selben Verzeichnis wie die Grafik und hat den Namen top-10-map.txt. Dies Datei für Revierphone kann man ganz normal aufrufen und hineinsehen. Es steht ein Imagemap drin. Wichtig ist dabei der Mapname, hier z.B. ‘gcmap-27′, mit dem die Map von der Grafik referenziert wird.

Revierphone-Map mit Wordpress Shortcode

Seit Wordperess Version 2.5 gibt es die Shortcodes mit denen man spezielle Funktionen direkt in den Inhalt einer Seite oder eines Artikels einbinden kann. Ein Beispiel ist der seitdem existierende gallery-Shortcode, mit dem man die Bilder zu einem Beitrag als kleine Galerie im Artikel anzeigen kann.

Aber auch für eigene Erweiterungen ist die Shorcode-API wunderbar und vorallem einfach einsetzbar. Für das Einlesen der Revierphone-Image-Map sind nur wenige Zeilen PHP-Code in der functions.php-Datei des Themes erforderlich:

function plw_get_chart_map( $atts, $content = null ) {
	extract( shortcode_atts( array(
		'name' => null,
	), $atts ) );

	if( is_null( $name ) )
		return '';

	$url = "http://chart.hbgf.de/$name/top-10-map.txt";
	$response = wp_remote_get( $url );
	if( is_wp_error( $response ) )
		return '';
	if( 200 != $response['response']['code'] )
		return '';

	return $response['body'];
}
add_shortcode( 'chartmap', 'plw_get_chart_map');

Der Shortcode erwartet den Namen der Map als Parameter name. In diesem Fall ist es ‘revierphone’, alles klein geschrieben. Falls kein Name übergeben wurde, wird ein Leerstring zurück gegeben.

Dann wird die URL zusammengesetzt und die Map mit der Wordpress-Funktion wp_remote_get eingelesen. Die Funktion gibt es erst seit Wordpress 2.7, deshalb funktioniert meine Funktion erst ab dieser Wordpress-Version. Man vermeidet durch Nutzung das Jonglieren mit den diversen Netzwerkfunktionen wie cURL, Streams und fsockopen. Wenn die Konfiguration stimmt, funktioniert das auch sehr gut, schließlich verwendet Wordpress die Funktion selbst für alle HTTP-Requests. :-)

Nach ein wenig gegebenenfalls erforderlicher Fehlerbehandlung wird vom Shortcode-Handler die eingelesene Map zurück gegeben.

Revierphone-Chart mit klickbaren URLs

Um die Image-Map im Wordpress-Artikel zu verwenden, muß an der gewünschen Stelle einfach der Shortcode mit dem map-Parameter eingegegen werden. Am besten dirket vor der Revierphone-Chart-Grafik selbst:

[chartmap name='revierphone']
<img src="http://chart.hbgf.de/revierphone/top-10.png" alt="reVierphone Top-10" usemap="#gcmap-27"/>

Wichtig ist, damit es überhaupt funktioniert, beim img-Tag das Attribut usemap. Hier ist der Name der Map so wie im map-Tag angegeben mit einem vorangestellten Doppelkreuz einzutragen, also usemap=”#gcmap-27″.

Und so sieht das dann aus:

Viel Spaß :-)

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

Ein 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. :-)

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…

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!

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

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 imm noch da, wird der Maintenance-Modus beendet und der Admin erhält im Backend einen entsprechneden Hinweis angezeigt.

Um Wordpress direkt in den Wartungsmodus zu versetzen, reicht es also, eine Datei mit folgendem Imhalt 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 Standarmeldung 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.

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)

In Wordpress ab Version 2.5 wurde die Attachment-Verwaltung erheblich erweitert und verbessert. Sie firmiert nun unter dem Schlagwort Mediathek. Eine wesentliche Erleichterung ist meiner Meinung nach die Möglichkeit, mehrere Dateien (z.B. Bilder) auswählen und in einem Rutsch hochladen zu können. Ein weiteres Highlight sind die sogenannten Shortcodes, kleine Textbausteine, die bei der Ausgabe in viele schöne Sachen verwandelt werden können. Die Shortcodes sin aber eher etwas für Plugin-Entwickler, der normale Nutzer hat erstmal nichts davon.
Einen solchen Shortcode liefert Wordpress aber bereits mit, es ist eine einfache Bilder-Galerie.

Die Worpress-Bildergalerie

Aus Anwendersicht ist das mit den Shortcodes ganz einfach, man fügt das gewünschte Kürzel, gegebenfalls mit Parametern, einfach in eckigen Klammern an der Stelle im Text ein, wo die Ausgabe erfolgen soll. Für die WP-Bildergalerie sieht das z.B. so aus:

[gallery columns='2']

Bei der Anzeige das Artikels wird dann dieser Shortcode z.B. durch eine Bildergalerie ersetzt:

So könnte es aussehen. Die Ausgabe läßt sich durch ein paar Parameter steuern, so legt der Parameter ‘columns’ z.B. fest, wieviele Spalten die Galerie verwenden soll (Standardwert ist 3). Im Beispiel habe ich 2 Spalten eingestellt.
Alle Parameter und die Verwendung des Gallery-Shortcodes sind im WP-Codex beschrieben.

Erweiterung – Der Link

Eine wie ich meine wichtige Sache haben die Entwickler aber vergessen. In der Standard-Galerie wird vom Vorschaubild immer auf die Bilderseite (Beispiel Bild 1) verlinkt, nicht auf das Bild selbst. Das ist so im PHP-Quelltext fest “verdrahtet”. Dabei wäre es kein großes Sache gewesen auch dafür einen Parameter vorzusehen. Aber was nicht ist, kann man glücklicherweise mit einem Plugin nachrüsten. So habe ich einfach die originale gallery_shortcode-Funktion genommen und um den Parameter attlink erweitert. Das Plugin selbst und eine Kurze Beschreibung findet man auf meiner Plugin-Seite “123 Extended Gallery“.

Und noch etwas habe ich verändert. Im Originalcode wird der CSS-Teil zur Formatierung der Galerie direkt in den Artikel geschrieben. Das ist alles andere als HTML-konform. So habe ich den CSS-Teil rausgezogen und in den Header verlegt, dahin wo soetwas hingehört. Einziger kleiner Nachteil, die CSS-Sachen werden immer im Header ausgegeben, auch wenn später im Artikel gar keine Galerie vorhanden ist. Aber damit kann ich leben.

Das Nachladen von PHP-Modulen ist noch relativ einfach, sofern sich die Dateien im selben Verzeichnis wie das Hauptmodul befinden. Da reicht ein einfaches

include( 'modul-2.php');

und man muß sich keine Gedanken über Pfade und Verzeichnisse machen.

Anders ist es bei Grafik-, CSS- oder Javascript-Dateien. Hier wird eine gültige URL benötigt, also muß man das Verzeichnis wissen, in dem sich das Plugin befindet. Und zwar nicht den absoluten Pfad auf dem Server, sondern den Pfad bezogen auf die Webseiten-Adresse. Häufig sieht man dann so etwas:

$css = get_option( 'siteurl' ).'/wp-content/plugins/my-plugin/my-style.css';

Es wird also einfach davon ausgegangen, daß Plugins immer im Verzeichnis ‘wp-content/plugins’ liegen. Das müssen sie aber nicht, denn in Wordpress ist dafür extra die Konstante PLUGINDIR vorgesehen.

Diese wird in der wp-settings.php wie folgt definiert:

if ( !defined('PLUGINDIR') )
	define('PLUGINDIR', 'wp-content/plugins'); // no leading slash, no trailing slash

Das if ( !defined(‘PLUGINDIR’) ) läßt erahnen, daß es durchaus vorgesehen ist, hier auch vorab ein anderes Verzeichnis zu definieren. Ganau davon mache ich Gebrauch, indem ich ein abweichendes Plugin-Verzeichnis in der wp-config.php definieren. Das ist eine einfache Möglichkeit, sich ein wenig vor Angriffen auf Schwachstellen in Plugins zu schützen. Denn auch die meisten Angreifer gehen davon aus, daß sie Plugins in Verzeichnis ‘wp-content/plugins’ liegen, sofern sie überhaupt so intelligent sind.

Wenn nun ein Plugin selbst einfach ‘wp-content/plugins’ anstelle von PLUGINDIR verwendet, sind Schwierigkeiten vorprogrammiert. Deshalb, liebe Plugin-Programmierer, verwendet bitte immer PLUGINDIR, um Pfade zusammenzusetzen. Für das obige Beispiel könnte das etwa so aussehen:

$css = get_option( 'siteurl' ).'/'. PLUGINDIR.'/my-plugin/my-style.css';

Ich verwende z.B. folgende Funktion, damit ich auch unabhängig davon bin, in welchem Unterverzeichnis innerhalb des Pluginverzeichnisses die Dateien liegen:

// ermittelt das Pluginverzeichnis
function plw123_plugin_basedir( $file ) {
	$file = str_replace('\\','/',$file); // Windows Verzeichnistrenner "umkippen"
	$file = preg_replace('|/+|','/', $file); // doppelte Schrägstriche entfernen
	$file = preg_replace('|^.*/' . PLUGINDIR . '/|','',$file); // relativen Pfad zum Plugin-Dir ermitteln
	return '/'.PLUGINDIR."/$file/";
}

...

$pluginPath = plw123_plugin_basedir( dirname(__FILE__) );
$css = get_option( 'siteurl' ).$pluginPath.'my-style.css';

Bei Wordpress ab Version 2.1 wurde das dann auch geändert, hier wird dieses GROUP BY mit der ID nur noch dann eingefügt, wenn es tatsächlich benötigt wird, nämlich wenn man die Abfrage auf bestimmte Kategorien oder Tags einschränken will. Das könnte z.B. etwa so aussehen:

<?php  query_posts( $query_string.'&cat=1,2,3' ); ?>

Hier will man zum Beispiel nur Artikel anzeigen, die in Kategorie 1, 2 oder 3 enthalten sind. Wenn nun ein Artikel mehreren Kategorien zugeordnet ist, würde das dazu führen, daß dieser Artikel auch mehrmals in der Liste steht und das will man ja nicht. Genau hier bewirkt das GROUP BY id, daß jeder Artikel nur einmal auftaucht. Man hätte das zwar ebenso mit DISTINCT erreicht, aber WP macht es halt mit GROUP BY. Letztendlich ergibt sich daraus ein Problem, welches aber einer fehlerhaften Implementierung von MySQL 5.0.51 zuzuschreiben ist.

Da ich bei mir nicht mit Kategorien oder Tags in den Abfragen arbeite, war mir das bisher auch nicht klar. Erst ein Beitrag im wordpress.org Forum hat mir die Augen geöffnet (Dank an Otto42 für die erhellenden Worte :-).

Was bedeutet das nun für die Praxis? Ganz klar, das Problem kann nur durch ein Update von MySQL behoben werden, da ist dann der Webhoster in der Pflicht. Nun ist es aber nicht ganz einfach, goße Hoster wie Strato dazu zu bewegen, zumal es MySQL 5.0.53 wohl auch noch nicht gibt.
In der Zwischenzeit kann erstmal mein Plugin helfen, welches das GROUP BY id in ein GROUP BY post_date “verbiegt”. Einen kleinen Nachteil hat das aber. Wenn es zwei oder mehrere Artikel mit auf die Sekunde übereinstimmendem Veröffentlichungszeitpunkt gibt, wird nur einer von diesen dargestellt.

Es ist ja lobenswert, daß Strato relativ schnell die MySQL-Versionen aktualisiert, vor ein paar Tagen von 5.0.45 auf 5.0.51. Man sollte auch denken, daß es dadurch mit Applikationen keine Probleme geben dürfte. Nich so diesmal, denn plötzlich stimmte bei so manchen Wordpressinstalltionen die Sortierreihenfolge der Beiträge nicht mehr, wie mehrere Nutzer im WP-Deutschlanforum beklagten. Aber nicht nur Strato war davon betroffen, auch bei 1&1 und anderen Hostern gab es Probleme.

Normalerweise kommen ja die neuesten Artikel zuerst, es wird also absteigen nach Datum sortiert. Nun waren aber plötzlich die ältesten Beiträge ganz oben, als scheinbar eine umgekehrte, also aufsteigende Sortierung. Und niemand hatte bewußt etwas verändert, also keine Plugins installiert oder die Themedateien bzw. die Konfiguration angepaßt. Also konnte es nur am Hoster liegen. Da ich hier bei Schnurpsel diesen Effekt nicht beobachten konnte, dachte ich zunächst doch an irgendein Plugin, bis ich mal spaßeshalber mein Wordpress-2.0.x-Testbolg aufgrufen hatte. Und siehe da, auch hier waren die Beiträge plötzlich nicht mehr in der gewünschten Reihenfolge. Da ich dort aber wirklich seit Monaten nichts verändert hatte und nur ein paar eigene Plugins verwende, mußte es doch irgendeine andere Ursache haben. Zumindest hatte ich jetzt die Chance, der Sache auf den Grund zu gehen.

Hintergrund

Meine erster Schritt war, mir mal die von WP generierte SQL-Abfrage anzusehen. Meine Vermutung war zunächst, daß irgendwo die Sortierung (ORDER BY post_date) verloren geht. So sieht die SQL-Abfrage aus:

SELECT DISTINCT *
 FROM wp20_posts
 WHERE 1 =1
 AND post_date_gmt <= '2008-01-11 22:03:59'
 AND (
  post_status = 'publish'
  OR post_author =1
  AND post_status != 'draft'
  AND post_status != 'static'
 )
 AND post_status != 'attachment'
 GROUP BY wp20_posts.ID
 ORDER BY post_date DESC
 LIMIT 0 , 10

Vom komischen WHERE 1=1 mal abgesehen gab es zumindest keine Auffälligkeiten, die Sortierung ist auch drin aber was soll bitte das GROUP BY wp20_posts.ID? Das Feld ID ist ein Autoinkrement-Feld, also immer eindeutig (UNIQUE) und somit kann es da nie zwei- oder mehrmals den selben Wert geben, also kann auch nichts gruppiert werden. Mit GROUP BY feldname werden normalerweise Datensätze zusammengefaßt, die in dem oder den angegebenen Feldern die selben Werte enthalten. Ein Blick in den Quelltext gibt dann Aufschluß, dieses GROUP BY ist beim Zusammensetzen des SQL-Strings fest codiert und muß daher immer belegt werden, damit die Abfrage syntaktisch richtig ist:

"SELECT $distinct * FROM $wpdb->posts $join WHERE 1=1" . $where . " GROUP BY " . $groupby . " ORDER BY " . $orderby . " $limits";

Wenn keine echte Gruppierung verwendet wird, wird dafür einfach als Dummy-Wert das Feld ID eingesetzt. Normalerweise kein Probem, weil ja eben dadurch nichts gruppiert wird. Und genau deshalb wird sowas auch vom SQL-Server letztendlich wegoptimiert, daß heißt, es steht zwar da, kommt aber nicht zur Anwendung. Außerdem bewirkt ein GROUP BY auch implizit eine Sortierung nach den dort angegebenen Feldern. Und genau hier liegt das Problem.

Wurde bei MySQL vor Version 5.0.51 mit dem GROUP BY für eindeutige Felder auch die implizite Sortierung wegoptimiert, ist das in der neuen Version nun anders. Hier bleit diese Sortierung erhalten, auch wenn keine Gruppierung stattfindet. In den Release-Notes findet man den entsprechenden Hinweis zu diesem Fehler (30596).

Lösung

Betroffen ist, sofern nicht durch Plugins Gruppierungen hinzugefügt oder verändert werden, nur Wordpress Version 2.0.x, zu WP 1.x kann ich nichts sagen. Bei Wordpress ab Version 2.1 wurde das Verhalten geändert, so daß GROUP BY nur noch dann in den SQL-String eingebaut wird, wenn wirklich eine Gruppierung verwendet werden soll.
Nachtrag: Auch in Wordpress ab Version 2.1 kann das Problem auftreten, wenn man etwas mit Kategorien oder Tags (ab 2.3) verändert, also z.B. nur bestimmte Kategorien in die Anzeige einbeziehen will:

<?php query_posts( $query_string.'&cat=1,2,3' ); ?>

Falls man keine spezielle Kategorie- oder Tagkonfiguration verwendet, ergibt sich auch direkt die erste Lösungsmöglichkeit, nämlich auf die neuste Wordpress-Version (derzeit 2.3.2) zu aktualisieren.
Falls man das aus irgendeinem Grund nicht möchte oder das Kategorie-/Tagproblem auftritt, ist die zweite Lösung ein Plugin, welches das GROUP BY auf einen nicht störenden Wert zurechtbiegt.
Als Wordpress-Plugin sehen die paar Zeilen PHP-Code dann so aus:

<?php
/*
Plugin Name: 123 No Group By ID
Plugin URI: http://schnurpsel.de/wordpress-und-die-suboptimale-mysql-optimierung-5051-74/
Description: Ändert bei WP das GROUP BY id in GROUP BY post_date (Problem ab MySQL 5.0.51).
Author: Ingo Henze
Version: 0.12
Author URI: http://putzlowitsch.de/
*/ 

	// GROUP BY auswerten
	function plw123ngb_posts_groupby( $groupby ) {
		if( preg_match( "/(|[ ,.])id(|[ ,])/i", $groupby ) ) {
			// sonst GROUP BY auf post_date setzen
			$groupby = 'post_date';
		}
		return $groupby;
	}

	add_filter( 'posts_groupby', 'plw123ngb_posts_groupby' );
?>

Mann kann den Quelltext hier einfach rauskopieren, in einer Datei speichern, auf den Server in das Pluginverzeichnis kopieren und aktivieren. Oder man nimmt das fertige Plugin als ZIP-Datei.

Download: 123 No Group By ID 0.12

Sofern in der "GROUP BY"-Felderliste das Feld ID auftaucht, wird alles durch POST_DATE ersetzt. Das ist zwar so ein bißchen eine "Holzhammermethode", sollte aber in den meisten Fällen keine Nebenwirkungen zeigen. Probleme könnten nur dann auftreten, falls ein Plugin auch irgendwelche Gruppierungen vornimmt und dabei ebenfalls das Feld ID mit einbezieht. Zudem würde für den eher unwahrscheinlichen Fall, daß es zwei oder mehrere Beiträge mit exakt dem selben Veröffentlichungszeitpunkt gibt, nur einer von diesen angezeigt werden.

Es war mir ja schon fast am Anfang meiner Strato-Zeit aufgefallen. Die Servervariable HTTP_HOST liefert immer den Hostname mit einem vorangestellten www zurück, selbst dann, wenn der Aufruf ohne www erfolgte. Eigentlich eine eigenwillige, wenn nicht gar falsche Konfiguration des Strato-Severs, denn die Variable HTTP_HOST soll eigentlich genau das enthalten, was der Browser im HTTP-Requestheader übermittelt. Wenn ich also die Seite schnurpsel.de aufrufe, dann sollte eben das da drin stehen, und nicht etwa www.schnurpsel.de. Aber genau das passiert bei Strato (PowerWeb A und S).

Problem

Bisher stellte das auch kein Problem dar, mit dem Neuen Wordpress 2.3 aber schon (deshalb war meine Seite gestern Abend auch zeitweise nicht erreichbar). Ab Wordpress 2.3 ist eine Funktion integriert, die ein sogenanntes “Canonical Redirect” ausführt. Auf das Strato-Problem bezogen bedeutet das, daß eine Weiterleitung z.B. dann stattfindet, wenn der Aufruf der Seite nicht so erfolgt, wie das in der Wordpresskonfiguration eingestellt ist.
Wenn z.B in Wordpress als Blog-Adresse (URL)

http://schnurpsel.de

eingetragen ist, jemand aber die Seite mit

http://www.schnurpsel.de

aufruft, wird er auf

http://schnurpsel.de

umgeleitet (und anders rum). An sich eine sinnvolle Sache, gerade unter SEO-Aspekten.

Was passiert nun aber bei Strato? Die funktion redirect_canonical schaut in HTTP_HOST nach, wie die Seite aufgerufen wurde, stellt fest, daß da ein www steht, aber das Blog ohne www konfiguriert ist. Also wird flux auf die Adresse ohne www weitergeleitet (diese Information bekommt der Browser zurück). Der ruft dann brav die Seite erneut ohne www auf, weil aber Strato das www wieder vorneran stellt, leitet redirect_canonical erneut um, der Browser ruft wieder brav ohne www auf usw. usw. Es ensteht also eine Weiterleitungs-Endlosschleife, die der Browser dann aber (hoffentlich) nach ein paar Versuchen mit einer Meldung beenden sollt. Beim Firefox sieht das dann so aus:

Fehler: Umleitungsfehler
Die aufgerufene Website leitet die Anfrage so um, dass sie nie beendet werden kann.

Das alles tritt aber nur beim Blog selber auf, der Adminbereich ist davon nicht betroffen.

Lösung

Aber auch hier gibt es mit einem bißchen Basteln Abhilfe. Glücklicherweise gibt es in den Servervariablen einen Eintrag, der die tatsächlich aufgerufene Adresse enthält, nämlich SCRIPT_URI. Dieser enthält die vollständigen Aufrufadresse mit http und gegebenfalls Verzeichnis und Dateiname, z.B.

http://schnurpsel.de

Hier kann man einfach den echten Hostanamen extrahieren und der Variable HTTP_HOST zuweisen. Und schon ist die Welt wieder in Ordnung :-)

Also Wordpress-Plugin sehen die paar Zeilen PHP-Code dann so aus:

<?php
/*
Plugin Name: 123 True HTTP Host
Plugin URI: http://schnurpsel.de/wordpress-23-problem-ohne-www-bei-strato-65/
Description: Setzt den wahren HTTP_HOST aus dem Request. Bei Strato wird immer www davor geschrieben.
Author: Ingo Henze
Version: 0.10
Author URI: http://putzlowitsch.de/
*/
$plw123thh = parse_url( $_SERVER['SCRIPT_URI'] );
if( isset( $plw123thh['host'] ) && ($plw123thh['host']!=$_SERVER['HTTP_HOST']) )
  $_SERVER['HTTP_HOST'] = $plw123thh['host'];
?>

Mann kann den Quelltext hier einfach rauskopieren, in einer Datei speichern,auf den Server in das Pluginverzeichnis kopieren und aktivieren. Oder man nimmt das fertige Plugin als ZIP-Datei.

Download: 123 True HTTP Host 0.10

Im Übrigen tritt das Problem mit der Weiterleitungs-Endlosschleife bei einer Konfiguration mit www nicht auf, allerdings funktioniert dann das redirect_canonical auch nicht, weil die Seiten ja scheinbar immer korrekt mit www aufgerufen werde.

Am einfachtesten ist es, sich die gewünschte Funktion aus der Datei wp-admin/include/updrade.php (früher wp-admin/upgrade-functions.php ) zu kopieren, die notwendigen Änderungen vorzunehmen und das dann in wp-content/install.php zu speichern.

Und wofür ist das nun gut?
Ich hatte ja zum Problem WP 2.3 Plugincheck geschrieben, das es bei der Neuinstallation auf Grund des Henne-Ei-Problems normalerweise nicht möglich ist, das Plagin zu aktivieren, ohne mindestens einmal die Pluginseite aufgerufen zu haben und damit bereits die Daten an wordpress.org zu senden. Das ist nun mit so einer benutzerdefinierten install.php möglich.

Download: Benutzerdefinierte install.php (als ZIP)

Diese Datei enthält nichts weiter, als die originale WP-Installationsfunktion, am Ende durch folgende Programmzeilen ergänzt:

// Automatische aktiviere von Plugins oder der my-hacks.php
// Plugins
$active_plugins = get_option( 'active_plugins' );
$active_plugins[] = 'plw123_anon_vchek.php';  // hier den Plugin-Dateiname eintragen
update_option( 'active_plugins', $active_plugins );
// my-hacks.php
// update_option( 'hack_file', 1 );

Das mit der my-hacks.php ist auskommentiert, es soll nur das Prinzip veranschaulichen.

Wie sieht nun also eine Wordpress 2.3 Neuinstallation aus:

• Wie gewohnt alle Wordpressdateien auf den Server übertragen (wp-config.php nicht vergessen)
• zusätzlich das Plugin in das Pluginverzeichnis kopieren
• zusätzlich die benutzerdefinierte install.php in das Verzeichnis wp-content kopieren
• Wordpressinstallation wie gewohnt starten

Fertig!

Viel Spaß mit dem anonymisierten, neuen Wordpress 2.3 :-)

Nachtrag: Hannes hat auch ein Plugin geschrieben, welches zusätzlich noch die Pluginliste entschlackt. Sein Plugin kann man natürlich auch mit der beschriebenen Methode gleich bei der Installation aktivieren. Dazu muß einfach nur der Name geändert werden, also an Stelle von:

$active_plugins[] = 'plw123_anon_vchek.php';  // hier den Plugin-Dateiname eintragen

entsprechend

$active_plugins[] = 'anonymous-plugin-updates.php';  // hier den Plugin-Dateiname eintragen

Und es muß auch in das Pluginverzeichnis kopiert werden, das ist ja klar.

Wenn man sein System von einer älteren Wordpress-Version updatet, ist das kein Probelm. Dann kann man das Plugin einfach vor dem Update installieren und aktivieren. Bei einer Neuinstalltion müßte man aber, bevor man irgendwas anderes macht, das Plugin direkt in der Datenbank aktivieren, was ein bißchen fummelig ist. Zudem setzt man die Filterung auch außer Kraft, wenn man z.B. mit der Funktion “Deaktivier alle Plugins” alle Plugins ausschaltet.

NEU: Auch die Pluginversion kann bei einer Neuinstallation verwendet!

Wie auch immer, hier nun das “123 Anonymer Versionscheck”-Plugin.

Download: 123 Anonymer Versionscheck 0.10

Die Funktionsweise entspricht exakt der Hack-Version. Weitere Informationen bitte dort nachlesen.

Weitere Plugins zum Thema

• Hannes ersetzt in seinem Plugin die Updatefunktion mit einer angepaßten eigenen Version und reduziert dort auch die übertragene Pluginliste auf die notwendigen Daten.
• Filosofo’s Tinfoil-Hat Plugin bringt gleich ein komplett neues Updatesystem mit, doktert also nicht nur an den Symptomen rum, sondern mach gleich “Nägel mit Köpfen”.

Diese Plugins lassen sich auch mit dieser Methode bereits bei der Neuinstallation aktivieren.

Letzteres sorgt aber bereits jetzt für Unmut in der WP-Welt, denn diese durchaus sinnvolle Funktion überträgt beim Überprüfen der Versionsinformationen auch Daten, die dafür nicht erforderlich wären, so z.B. die Adresse (URL) des Blogs. Im WP-Forum wird bereits darüber diskutiert und das eine oder ander Blog berichten darüber. Es gibt auch schon Plugins, welche die Updatebenachrichtigungsfunktionen deaktivieren, nur dann werden gar keine Updateinformationen mehr angezeigt.

NEU: Jetzt auch als Plugin.

Ich beschreibe im Folgenden eine Möglichkeit, wie man die Versionsüberprüfung beibehalten kann, ohne aber die eigene Blog-URL an wordpress.org zu übertragen. Dafür kommt mal wieder meine Lieblingskind, die my-hacks.php zum Einsatz. Falls diese Datei im Wordpress-Wurzelverzeichnis nicht existiert, legt man sie neu an. Dann kommt der folgende Code dort hinein:

<?php
// Namen der Update- und Check-Funktion
define('PLW_PLG_FUNC', 'wp_update_plugins');
define('PLW_VER_FUNC', 'wp_version_check');

// anonymisiert die URL
function plw123_anon_url() {
 return "http://example.org";
}

// "anonymisiert" aktive Plugins
function plw123_no_active_plugins() {
 return "a:0:{}";
}
// Ersetzt die originale 'wp_version_check'
function plw123_anon_version_check() {
 if( function_exists( PLW_VER_FUNC ) ) {
  add_filter( 'pre_option_home', 'plw123_anon_url', 99999 );
  call_user_func( PLW_VER_FUNC );
  remove_filter( 'pre_option_home', 'plw123_anon_url', 99999 );
 }
}

// Ersetzt die originale 'wp_update_plugins'
function plw123_anon_update_plugins() {
 if( function_exists( PLW_PLG_FUNC ) ) {
  add_filter( 'pre_option_home', 'plw123_anon_url', 99999 );
  add_filter( 'pre_option_active_plugins', 'plw123_no_active_plugins', 99999 );
  call_user_func( PLW_PLG_FUNC );
  remove_filter( 'pre_option_active_plugins', 'plw123_no_active_plugins', 99999 );
  remove_filter( 'pre_option_home', 'plw123_anon_url', 99999 );
 }
}

// Versionschek entfernen und durch eigene Funktion ersetzen
if( function_exists( PLW_VER_FUNC ) ) {
 remove_action( 'init', PLW_VER_FUNC );
 add_action( 'init', 'plw123_anon_version_check' );
}

// Plugin-Update entfernen und durch eigene Funktion ersetzen
function plw123_change_update_plugins () {
 if( function_exists( PLW_PLG_FUNC ) ) {
  remove_action( 'load-plugins.php', PLW_PLG_FUNC );
  add_action( 'load-plugins.php', 'plw123_anon_update_plugins' );
 }
}
add_action( 'admin_menu', 'plw123_change_update_plugins' );
?>

Download: my-hacks.php (als ZIP)

Der Trick besteht darin, das man während der Ausführung der wp_version_check und wp_plugin_updates Funktion ein Filter installiert, welches nicht die URL sondern einen beliebigen anderen Text zurückgibt. Diesen kann man in der Funktion plw123_anon_url festlegen, im Beispiel wird http://example.org zurückgegeben. Danach wird das Filter wieder entfernt. Um den Funktionsaufruf so “einrahmen” zu können, werden die originalen Funktionen mit remove_action entfernt und statt dessen die eigenen Funktionen mit add_action installiert.

Nachtrag (24.09.2007 15:10): Ich habe nun noch zusätzlich die “Anonymisierung” der aktiven Plugins eingebaut., das heißt, es wird keine Information mehr übertragen, welche Plugins auch tatsächlich aktiv sind.

Und dann gäbe es noch ein klassisches Henne-Ei-Problem, wenn der Code in einem Plugin verpackt wäre (was natürlich auch möglich ist). Um das Plugin zu aktvieren, muß man im Adminbereich die Pluginseite aufrufen und schwupps werden die Daten ersteinmal an Wordpress gesendet. Beim Update von einer älteren Version ist das kein Problem, da kann man das Plugin vor dem Update einspielen und aktivieren. Bei einer Neuinstallation hat man aber so keine Chance. Deshalb ist das in der my-hacks.php besser aufgehoben. Dann muß diese aber auch bei “Einstellungen” -> “Verschiedenes” aktiviert werde (vor dem Update):

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

Bei einer Neuinstallation muß man, wenn man ganz Sicher gehen will, die entsprechende my-hacks.php gleich mit kopieren und unmittelbar nach den WP-Installationsschritten vor dem ersten Aufruf zunächst direkt in der Datenbank die My-Hacks-Option aktvieren. Dazu in der Tabelle wp_options den Datensatz mit dem option_name hack_file suchen und den Wert für option_value zu 1 ändern.

Ein Problem gibt es allerdings. Sollten sich die Funktionsnamen oder der Ablauf der Versionskontrolle in zukünftigen Wordpressversionen ändern, dann funktioniert der Hack nicht mehr und muß angepaßt werden.

So gibt es nun also eine neue Version 0.11 des 123 IIS Permalink-Plugins, die auch mit Datenübergabe per POST oder GET funktioniert. Nebenbei habe ich gleich noch eine permanente Weiterleitung (301) der alten ‘/index.php/irgendwas’-Aufrufe eingebaut. So braucht man sich wegen alter Permalinks z.B. bei Google keine Sorgen zu machen.

Das muß aber nicht bei der index.php-Variante bleiben, denn das Problem ist ein ähnliches wie bei den Strato-PowerWeb-Paketen, bei denen zwar ein Apache mit mod_rewrite läuft, dieses aber vom Kunden nicht genutzt werden kann. Wenn man es doch versucht, wird das knallhart mit einem 500er Fehler bestraft. Wie man es bei Strato doch hinbekommt, habe ich hier beschrieben.

Für den IIS ist der Ansatz ganz ähnlich. Es wird ein benutzerdefiniertes Fehlerdokument für den Fehler ‘404 Not Found’ “mißbraucht” und dieses ist einfach die ‘index.php’ im Wordpress-Wurzelverzeichnis. Was anderes macht die RewriteEngine praktisch auch nicht, bis auf einen kleinen, aber wichtigen Unterschied. Beim Fehlerdokument wird der Status auf 404 gesetzt, so das der normale Nutzer im Browser zwar keinen Unterschiede sehen würde, denn er bekommt die Seite ganz normal angezeigt. Ein Suchmaschinen-Robot würde die Seite aber wie einen “Not Found”-Fehler behandeln und nicht weiter beachten. Deshalb ist das in der Beschreibung genannte Plugin erforderlich, welches den Status wieder ordentlich zurechtbiegt.

Etwas anders liegt die Sache beim IIS. Wenn eine benutzerdefinierte Fehlerseite als URL aufgerufen wird, wird vom Webserver der Status auf ‘200 OK’ gesetzte und der Fehlerseite als Parameter der Fehlerstatus und die aufgerufene Seite mitgegeben. Hier ist dann die Fehlerseite dafür zuständig, den Status entsprechend korrekt zu setzen. Eine sehr schöne Vereinfachung gegenüber den Verrenkungen, die bei der Stratolösung nötig sind.
Die einzig wirkliche Aufgabe besteht darin, aus dem übergebenen Parameter die eigenlich aufgerufene URL dem Wordpress als REQUEST_URI unterzujubeln, da daraus dann mit den Permalinkregeln die anzuzeigende Seite ermittlet wird.

Lange Rede, kurzer Sinn, genau das macht mein neues Plugin “123 IIS Permalink“. Es ermöglich also auch unter IIS die schönen Permalinks ohne dem /index.php/… Vorspann :-)

• Blogger – Beiträge, Kommentare und Benutzer aus einem Blogger-Blog
• Blogware – Beiträge Blogware-Blog
• DotClear – Kategorien, Benutzer, Beiträge, Kommentare und Links aus einem DotClear-Blog
• GreyMatter – Benutzer, Beiträge und Kommentare Greymatter-Blog
• LiveJournal – Beiträge aus einer LiveJournal-XML-Datei
• Movable Type / TypePad – Beiträge und Kommentare aus einem Movable-Type- oder Typepad-Blog
• RSS – Beiträge aus einem RSS-Feed
• Textpattern – Kategorien, Benutzer, Beiträge und Links aus einem Textpattern-Blog
• WordPress – Beiträge, Kommentare, benutzerdefinierte Felder, Seiten und Kategorien aus einer WordPress-Export-Datei

Man sieht anhand der kurzen Beschreibung den unterschiedlichen Datenumfang, den die jeweiligen Importmodule bewältigen. Je nach Typ erfolgt der Import aus einer oder mehreren Dateien, aus einer Datenbank oder mit Authorisierung direkt online. Da ich bis auf den RSS-Import keines der anderen Module bisher getestet habe, kann ich zur Qualität nichts weiter sagen. Beim RSS-Imoprt darf man natürlich keine Wunderdinge erwarten, es ist halt der kleinste gemeinsame Nenner aber man kann prinzipiell erstmal alles reinziehen, was irgendwie einen RSS-Feed ausspuckt.

Da ich meine “Hommingberger Zeitung” technisch etwas auffrischen wollte, stand ich vor dem Problem, die knapp 100 Artikel möglichst komplett und unbeschadet nach Wordpress importiert zu bekommen. Zunächst hatte ich angefangen, alle Beiträge per Copy&Paste zu übertragen, was aber doch etwas aufwändig und auch fehleranfällig geworden wäre. Und da mein altes “Redaktionssystem” frontseitig aus in PHP selbstprogrammierten Seiten und als Backend in phpMyAdmin bestand, kam erstmal nur ein RSS Export/Import in Frage. Nach dem ersten Versuch habe ich das aber auch schnell zu den Akten gelegt, da sich einige Besonderheiten meiner Zeitung (Untertitel, Quellen) nicht übernehmen ließen.

Also dachte ich, schreib ich doch einfach ein spezielles WP-Import-Modul für meine Zeitung, so schwer kann das ja nicht sein. Wie so oft helfen einem die vorhandenen Komponenten als Anschauungsbeispiel weiter, denn in der WP-Doku habe ich zur Importschnittstelle nichts gefunden. Und es ist tatsächlich nicht zu kompliziert. Vereinfachend kam noch hinzu, daß sich sowohl die alten Daten als auch die neuen Wordpress-Tabellen in der selben Datenbank befinden, so daß ich einfach die WP-Datenbankschnittstelle nutzen konnte.

Nun mußte ich mir nur noch überlegen, welche Inhalte von welchen alten in welche neuen Felder kommen. Ein Teil ließ sich 1:1 übernehmen, so z.B. Titel, Kurzbeschreibung (excerpt) und Datum. Beim Inhalt (content) mußte ein wenig zusammengebastelt werden und die in WP nicht vorhandene Felder wie Untertitel oder Quelle wurden einfach in benutzerdefinierte Felder (Metadaten) geschrieben und dann im Theme passend ausgegeben.
Außerdem mußte ich mir noch überlegen, was ich mit den Seitennamen und der Seitenstruktur mache. Gut für die Artikel habe ich die alten “Permalinks” ‘/meldung-1234′ beibehalten. Aber mein Zeitarchiv hieß bisher ‘/chronologie-2005-11-29′, was in WP dem ‘/2005/11/29′ entspricht. Hier habe ich mich kurzerhand entschlossen, den WP-Style so zu belassen und meine alten Sachen per Redirect 301 weiterzuleiten. Und ein paar Seiten sind ganz unter den Tische gefallen, aber die waren auch eher unwichtig.

So hatte ich an einem Nachmittag Arbeit alles nach Wordpress migriert und habe jetzt damit doch ein etwas komfortableres “CMS”. Gut, der Aufwand zur Programmierung des Import-Moduls für eine einmalige Aktion schein etwas unverhälnismäßig hoch zu sein, aber ich denke, wenn ich alles hätte “zu Fuß” übertragen müssen, wäre ich nicht schneller fertig gewesen.

So habe ich wieder was über die Wordpress-Innereien gelernt und wer weiß, wozu so ein spezielles Importmodul noch mal gut sein kann…

Update 07.10.2009: Als Beispiel stelle ich hier mein HZ-Importmodul zur Verfügung. Ist nicht besonders schön aber vielleicht als Anregung für eigene Entwicklungen geeignet.

Download: WP-Importmodul “Hommingberger Zeitung”