Statt eine Joomla!-Installation von der Version 1.5 auf die Version 2.5 zu migrieren kann es für kleine Websites auch eine Überlegung wert sein, eine Migration auf WordPress durchzuführen.
Wordpress ist zwar eigentlich als Blog-System gedacht, lässt sich aber ohne große Umstände als CMS “missbrauchen”.
Obwohl WordPress vielfältige Möglichkeiten bietet, mittels RSS-Feeds auf die Inhalte eines Blogs zuzugreifen, ist in der Grundinstallation keine Möglichkeit vorgesehen, einen individuellen Feed anhand eines (oder mehrerer) benuzerdefinierter Felder zu erstellen.
Ein solcher Feed kann allerdings mit nur wenigen Zeilen Programmcode in der Datei “functions.php” des aktuell gewählten Themes ergänzt werden. Die Zeile
add_action('init', 'mycustomfeed_add_feed');
fügt der WordPress-Initialisierung die eigene Funktion “mycustomfeed_add_feed” hinzu, welche die Einrichtung der benötigten Funktionalität übernimmt.
function mycustomfeed_add_feed() {
global $wp_rewrite;
add_feed('mycustomfeed','mycustomfeed_feed');
add_action('generate_rewrite_rules', 'mycustomfeed_rewrite_rules');
$wp_rewrite->flush_rules();
}
Die Funktion besteht aus dem Hinzufügen des eigenen Feeds mittels der Funktion add_feed, sowie dem Hinzufügen einer Rewrite-Regel mit Hilfe der Funktion add_action, bevor durch den Aufruf von flush_rules die soeben geänderten Regeln neu eingelesen werden.
function mycustomfeed_rewrite_rules($wp_rewrite) {
$my_rules = array(
'feed/(.+)' => 'index.php?feed=' . $wp_rewrite->preg_index(1)
);
$wp_rewrite->rules = $my_rules + $wp_rewrite->rules;
}
Die hinzugefügte Regel bewirkt das Umschreiben aller aufgerufenen URLs nach dem Schema “/feed/irgendwas” in die Form “?feed=irgendwas”, so daß zum Zugriff auf den neuen Feed auch die erste Schreibweise verwendet werden kann, ohne daß Änderungen an der “.htaccess” vorgenommen werden müssen.
function mycustomfeed_feed() {
query_posts('meta_key=mycustomfeed&meta_value=1');
include('wp-includes/feed-rss2.php');
}
Als letztes ändert die eigene Feed-Funktion die Auswahl der auszuliefernden Daten mit Hilfe der Funktion query_posts, bevor durch Aufruf des originalen WordPress-Feedmechanismus die Ausgabe generiert wird.
Im obigen Beispiel werden nur die Beiträge ausgeliefert, die ein benutzerdefiniertes Feld mit Namen “mycustomfeed” und dem Wert “1” enthalten.
Beim Versuch, mittels offiziellen WordPress-Android-Client auf ein Blog zuzugreifen erscheint bei abgeschaltetem XML-RPC nur die Fehlermeldung
XMLRPC Fault: XML-RPC-Dienste sind auf diesem Blog deaktiviert.
Ein Administrator kann sie hier aktivieren: http://<blog-url>/wp-admin/options-writing.php [code 405]
Wie aus der Fehlermeldung indirekt zu entnehmen vertsteckt sich der Schalter “XML-RPC” im Untermenü “Schreiben” der “Einstellungen”.
Wie heute auf wordpress.org veröffentlicht, wurden in den vergangenen Tagen verdächtige Änderungen an einigen populären Plugins bemerkt. Auch das hier im Testbetrieb eingesetzte WPtouch ist davon betroffen, es wurde wohl versucht, die Plugins mit gut versteckten Hintertüren zu versehen.
Während die Untersuchungen zum wie und wann der Modifikationen noch am Laufen sind, wurden bereinigte Versionen der Plugins bereitgestellt - leider aber keinerlei Checksummen zum Überprüfen der eigenen Plugin-Installation auf Unversehrtheit.
Um jegliche Gefährdung von Blog und Besuchern auszuschließen, wurde dieses Blog aus einer sauberen Sicherung ohne WPtouch neu aufgesetzt.
Um besser gegen Browserabstürze und Verbindungsabbrüche gewappnet zu sein, verfügt WordPress seit Version 2.6 über eine automatische Speicherfunktion sowie ein automatisches Revisionsmanagement.
Wie der WordPress Codex erklärt, wurden zwar entsprechende Optionen zum an- bzw. ausschalten des Revisionsmanagements integriert und es existieren auch API-Funktionen zum Aufräumen, diese wurden jedoch nicht in die Oberfläche integriert.
Im normalen Betrieb macht sich das Revisionsmanagement besonders durch eine stetig und schnell wachsende Datenbank bemerkbar - alleine vom Artikel “My Book Essential – virtuelles CD-Rom loswerden” finden sich nach Veröffentlichung ingesamt neun Revisionen.
Wer das Revisionsmanagement nicht benötigt, kann dieses - am besten noch vor Erstellen des ersten Artikels - mittels der Option ‘WP_POST_REVISIONS’ in der Datei ‘wp-config.php’ abschalten:
define('WP_POST_REVISIONS', false);
Wer bereits mit eingeschaltetem Revisionsmanagement gearbeitet hat, sollte nach dem Abschalten die Datenbank aufäumen.
Die Revisionen sind - genau wie die “richtigen” Artikel in der Tabelle ‘wp_posts’ abgelegt und durch den post_status = ‘inherit’ sowie post_type = ‘revision’ gekennzeichnet. Einen Überblick über deren Anzahl verschafft das SQL-Statement
SELECT COUNT(*) FROM wp_posts WHERE post_status='inherit' AND post_type = 'revision';
Bevor es an das Löschen der Revisionen geht, sollte allerdings noch ein Blick auf die Tabellen ‘wp_postmeta’ sowie ‘wp_term_relationships’ geworfen werden, um hier keine Karteileichen zurückzulassen.
SELECT COUNT(*) FROM wp_posts, wp_postmeta
WHERE ID=post_id AND post_status='inherit' AND post_type = 'revision';
SELECT COUNT(*) FROM wp_posts, wp_term_relationships
WHERE ID=object_id AND post_status='inherit' AND post_type = 'revision';
Anschließend können - nach einer eventuellen Bereinigung der oben genannten Tabellen - die vorhandenen Revisionen entsorgt werden:
DELETE FROM wp_posts WHERE post_status='inherit' AND post_type = 'revision';