Schnurpsel 

my-hacks.php wird auch in Wordpress 3.0 noch unterstützt

Puhhh, Glück gehabt. Nachdem bereits mit Wordpress 2.8 die Option für die my-hacks.php aus dem Backend verschwunden war, hatte ich befürchtet, daß auch die Unterstützung für diese älteste Wordpress-Erweiterungs-Schnittstelle ab Wordpress 3.0 ganz unter den Tisch fallen würde.

Das scheint aber nicht der Fall zu sein, denn in WP 3.0 RC1 wird die my-hacks.php weiterhin geladen, sofern sie aktiviert ist. Damit ist gewährleistet, daß nicht plötzlich nach dem Update wichtige Funktionen ausgesperrt werden, die möglicherweise in der my-hacks.php stehen.

Allerdings kann man nach einer Neuinstalltion die my-hacks-Erweiterung nicht mehr im Backend aktivieren. Dafür müßte man direkt in der Datenbank rumfummeln oder man verwendet das “123 Hackfile Option”-Plugin:

Download: Plugin 123 Hackfile Option 0.12

Die Option dafür erscheint nun allerdings nicht mehr bei Einstellungen->Verschiedenes (gibt es nicht mehr), sondern ganz am Ende von Einstellungen->Allgemein.

Alles Nichts oder nicht alles?

Wenn Besucher über Google auf die eigene Webseite kommen, ist das ja normalerweise eine schöne Sache. Allerdings nicht, wenn es über einen seltsamen Link, wie er oben zu sehen ist, passiert. Wie kommt aber soetwas überhaupt in den Index einer Suchmaschine?

Das gibts doch gar nicht

Bereits im Oktober letzen Jahres hatte ich etwas Ähnliches beobachtet. Da wurden Google massiv mit Links auf irgendwelche nicht existierende Seiten gefüttert. Wenn nun eine dieser nicht vorhandenen Seiten auf die Anfrage des Googlebots einen HTTP-Status “200 OK” zurückliefert, geht Google davon aus, daß es die Seite gibt und nimmt sie in den Index auf. Korrekterweise sollte aber mit dem Fehlerstatus “404 Not found” geantwortet werden, so daß die Seite nicht im Index landet. Genau das war damals bei mir der Fall, also ist eigentlich alles in Butter. Nur habe nicht mit der Großzügigkeit von Wordpress gerechnet.

Die Wordpress.presse.pressung

In manchen Dingen ist Wordpress recht großzügig. Früher war es möglich, wenn in den Permalinks die Artikel ID verwendet wurde, einen Artikel über nahezu beliebig viele URLs aufzurufen. Sobald die ID erkannt wurde und existierte, wurde der Rest der URL nicht weiter überprüft. So hätte man diesen Beitrag hier auch noch mit /alles-quark-399/ oder /blafasel-399/ aufrufen können. Das geht mittlwerweile nicht mehr. Allerdings ist zur Zeit etwas Ähnliches immer noch möglich, wenn man in den Permalinks die Kategorie verwendet.

Wenn nun eine Wordpress-Seite mit Parametern in der Form /?parameter=wert aufgerufen wird, ignoriert Wordpress einfach unbekannte Patemeter oder ungültige Paremeterwerte und tut so, als würde es diese Parameter gar nicht geben. Somit führen folgende Aufrufe zu gültigen Seiten:

http://testblog.schnurpsel.de/?q=Diese Seite gibt es nicht
http://testblog.schnurpsel.de/?quark=Gesund und schmeckt lecker
http://testblog.schnurpsel.de/?p=Hier steht normalerweise die ID

Bei den ersten beiden Beispielen wir ein unbekannter Paremeter verwendet, im dritten Beispiel der gültige Parameter p= (Short-Link), der allerdings eine numerische Artikel-ID erwartet. In allen Fällen wird die Startseite mit dem Status “200 OK” angezeigt. Es funktioniert aber ebenso mit Einzelseiten oder anderen Permalinks:

http://testblog.schnurpsel.de/...hallo-welt/?frage=was-soll-das
http://testblog.schnurpsel.de/2010/03/?jahreszeit=Frühling

Gut oder schlecht

Ob dieses Verhalten von Wordpress nun gut oder schlecht, gewollt oder ein Fehler ist, mag ich nicht beurteilen. Ich finde es zumindest suboptimal, denn dadurch entstehet z.B. die oben gezeigte URL als Google-Treffer, und sowas möchte ich nicht haben. Dabei wäre es für Wordpress kein größeres Problem, unbekannte Parameter oder ungültige Parameterwerte als Fehler zu behandeln. Das schöne an Wordpress ist ja, daß es recht einfach erweitert und modifiziert werde kann.

Fehler bleibt Fehler

Deshalb habe ich mir diese Parameterprüfung hier nachgerüstet (aber nicht für den Testblog!), übrigens auch für die worpdresseigene Suchfunktion. Denn falls es keinen Suchtreffer gibt, finde ich, ist das auch einen “404 Not Found” wert :-)
Nun sollte auch die ganz oben gezeigte, hier nicht existierende Seite nach einiger Zeit aus dem Suchindex verschwinden.

Nachtrag:
Weil es angefragt wurde, hier mein Code zur Parameterprüfung, der sich per Action-Hook in parse_request reinhängt:

<?php
 function plw123_parse_request( $data ) {
  // Liste der numerischen Parameter
  $num_para = array( 'p', 'page_id', 'attachment_id', 'tag_id',
          'page', 'paged',
          'year', 'monthnum', 'day', 'w', 'm',
          'hour', 'minute', 'second' );
  // Parameter übergeben, aber nicht gefunden
  foreach( $_GET as $key => $value )
   if( !array_key_exists( $key, $data->query_vars ) ) {
    $data->query_vars['error'] = '404';
    return;
   }
  // Numerische Parameter prüfen
  foreach( $data->query_vars as $key => $value ) {
   // Sonderbehandlung Kategorie-IDs
   if( 'cat' == $key ) {
    // darf eine Liste von kommaseparierten Integerwerten sein
    $test_value = preg_replace( '|[^0-9,-]|', '', $value );
    if( $test_value != $value ) {
     $data->query_vars['error'] = '404';
     return;
    }
   }
   // Numerische Werte
   if( in_array( $key, $num_para ) ) {
    $value = trim( $value );
    // Page bei Einzelansicht (Seite, Artikel) kann führenden Slash enthalten
    if( 'page' == $key )
      $value = ltrim( $value, '/' );
    $test_value = absint( $value );
    if( !$test_value ) {
     $data->query_vars['error'] = '404';
     return;
    }
   }
  }
 }
 add_action( 'parse_request', 'plw123_parse_request' );
?>

Das Ende der Wordpress-Hacker

Fä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

Wordpress 2.3 – Plugins oder my-hacks bei der Installation aktivieren

Bereits seit Wordpress 2.1 gibt es ein vermutlich eher unbekanntes Feature, mit dem man bereits bei der Installation eines neuen, nackten Wordpress benutzerdefinierte Aktionen ausführen kann. Schlüssel dazu ist eine Datei install.php, welche sich im Verzeichnis wp-content befinden muß. Ist also bei der Installation die Datei wp-content/install.php vorhanden, wird deren Inhalt noch vor den WP-eigenen Installtionsfunktionen geladen und kann damit z.B. die wp_install ersetzen.

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.

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.

Hackers Paradise

Es klingt ein bißchen illegal, doch es geht hier um die in Wordpress nutzbare Erweiterung ‘my-hacks.php’. Also alles im grünen Bereich.
Wenn sich solche eine Datei im WP-Wurzelverzeichnis befindet und außerdem die Option

[x] Unterstütz die veraltete my-hacks.php-Datei

aktiviert ist, wird der darin befindliche PHP-Code ausgeführt.
Nun gibt es ja mittlerweile die tolle Plugin-Schnittstelle und deshalb stehte da wahrscheinlich auch “veraltete my-hacks.php-Datei”, aber sie hat einen großen Vorteil. Sie wird nämlich vor allen Plugins geladen. So habe ich mir hier z.B. eine kleines Debugmodul eingerichtet, mit dem ich dann innerhalb eines Plugins Debug-Infos in eine Datei schreiben kann.

Nette Sache, denn man kann meist schlecht reingucken, was das Plugin so gerade macht. Ich teste zwar das Meiste auf einem lokalen Testserver, aber die hier bei Strato existierende Umgebung kann und will ich nicht simulieren. Es fängt schon damit an, daß meine PHP als Apache-Modul läuft, bei Strato aber als CGI. Und einige Dinge verhalten sich halt abhängig von der Server-API unterschiedlich.

Hier mal meine my-hacks.php-Datei. In die Debug-Datei schreiben geht dann einfach mit

plw123_debugfile_write( "Text" );

wenn man nicht vergessen hat, bei “Einstellungen” -> “Verschiedenes” die Option “Unterstütz die veraltete my-hacks.php-Datei” zu aktivieren :-) .