Das Putzlowitsch Test- und SEO-Blog

WordPress 2.3 – Anonym up-to-date bleiben

Heute kommt, so der Terminplan eingehalten wird, die neue WordPressversion 2.3 raus. Neben einigen eher für Plugin-Programmierer interessanten Änderungen der Datenbankstruktur dürfte sich der WordPressnutzer mehr für die neuen Funktionen intessieren. Was es so an Neuerungen gibt, kann man im WP-Deutschland-Blog nachlesen, da wären z.B. Tags nebst Tagwolke, SEO-Verbesserungen und Updatebenachrichtigung.

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.

14 Kommentare »

Der Haken am Trick

Vor einiger Zeit hatte ich das 123 IIS Permalink-Plugin vorgestellt. Durch Kommentare zum 123 No Rewrite Permalink-Plugin wurde ich auf ein Problem aufmerksam gemacht, welches sich auch beim IIS auswirkt. Erfreulicherweise kann man das beim IIS im Unterschied zum Apache-Server wieder ausbügeln, da hier die POST-Daten nicht verloren gehen.

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.

Keine Kommentare »

Exoten

Es scheint doch tatsächlich Leute zu geben, die ernsthaft WordPress auf einem IIS (was ist das?) laufen lassen :-)
Naja, es funktioniert wohl sogar. PHP mit MySQL bekommt man da auch ans laufen, also eigentlich kein großes Ding. Wenn da nicht die Sache mit den Permalinks wäre. Denn die erfordern nun mal ein funktionierendes mod_rewrite, was es aber meines Wissens nur für den Apache-Webserver gibt. Zumindest kann der IIS von Hause aus nichts mit den entsprechenden Einträgen in der .htaccess anfangen. Und WordPress ist auch so schlau, erkennt, daß es unter einem ISS läuft und bietet dann für die Permalinks gleich nur die Form mit dem vorangestellten /index.php an. Die sehen dann z.B. so aus:
/index.php/die-wordpress-import-schnittstelle-47/
Gut, es funktioniert auch aber ist doch eher nur ein Notbehelf, eine Krücke. Schöner sieht es natürlich so aus:
/die-wordpress-import-schnittstelle-47/

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

Weitere Artikel mit Bezug zu diesem:
Keine Kommentare »

Die WordPress Import-Schnittstelle

Keine Plugins im eigentlichen WordPress-Sinne, aber doch soetwas ähnliches sind die Importmodule. Dateimäßig zu finden unter ‚/wp-admin/import‘ bzw. im Backend ansprechbar über ‚Verwalten->Import‘. Bei WordPress-Version 2.2 sind bereits ganze 9 Importer mit der Installation bereits dabei:

  • 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. Weiter lesen

Weitere Artikel mit Bezug zu diesem:
5 Kommentare »

Schwachsinn, Unsinn und Wahnsinn

Wie ich schon früher angemerkt habe, ist das hier alles nur ein großes Experiment. Es kann also passieren, das sich plötzlich und ohne Vorankündigung die Struktur, die Adressen oder die Inhalte ändern oder alles. So habe ich grade das HTML- und Verbindestrichung-Plugin wieder abgeschaltet. Es bringt nichts, funkioniert nur eingeschränkt, hat mir aber einige neue Erkentnisse bezüglich der WordPress-Innereien gebracht, die ich an anderer Stelle sicher noch mal gebrauchen kann.

Weitere Artikel mit Bezug zu diesem:
Keine Kommentare »