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!

Mir eine E-Mail schicken, wenn
[x] ein Kommentar auf Freischaltung wartet.

eingeschaltet wurde, erhält der Blogadmin an die Adresse, die bei “Allgemeinen Einstellungen” als “E-Mail-Adresse” eingetragen ist (normalerweise die bei der WP-Installtion angegeben) eine Nachricht über die anstehende Kommantarmoderation.

Das ist bei so einem “Ein-Mann-Blog” wie diesem hier auch kein Problem, denn ich bin Adminstrator, Herausgeber, Redakteur und Autor in einer Person. Bei Blogs mit mehreren oder vielen Autoren, Redakteuren und Herausgebern wird das aber zum Problem, wenn die ganze Last der Moderation vom Kommentaren nur auf einem Paar Schultern ruht. In Wordpress selbst gibt es aber keine Option, mit der man festlegen könnte, das alle User mit der Berechtigung, Kommentare zu moderieren, eine entsprechende Nachricht erhalten.

Das Schöne an WP ist, daß man nahezu alles, was irgendwie fehlt, mit einem Plugin nachrüsten kann. Und so habe ich kurzerhand das Plugin “123 Moderate Comment Notification” geschrieben. Im Bereich der Einstellungen hat man drei Optionen:

• Administrator immer informieren
• Autor informieren, wenn er Kommentare moderieren darf
• Moderatoren informieren, falls Autor selbst nicht moderieren darf

Wobe mit “Moderatoren” hier alle registrieren Blognutzer gemeint sind, die die Berechtigung zum moderieren von Kommentaren haben. Normalerweise sind das Nutzer mit der Rolle “Administrator” oder “Herausgeber/Redakteur”.

Heute hat sich das Plugin bereits zum ersten Mal in einem Mehrautoren-Blog erfolgreich bewährt.

So konnte ich hier erstmal testen, ob meine eigenen Plugins funktionieren. Ja, das tun sie. Wobei ich das eine oder andere an die neuen Möglichkeiten von Wordpress 2.5 anpassen werde oder schon angepaßt habe. Zudem ist mir grad ein nettes Feature aufgefallen, wenn man Tags (Stichwörter) eingeben will. Dann klappt nach Eingabe von mindestens zwei Zeichen eine Auswahlliste auf, aus der man dann einfach ein passendes, schon vorhandenes Stichwort auswählen kann. Fein Sache, das.

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';

Zunächst wird eine neue statische Seite erstellt, die z.B. “Kontakt” heißt. Hier wird der Text und Code für den Formmailer eingegeben. Die URL der Seite lautet dann beispielsweise

http://schnurpsel.de/kontakt/

Diese wird bei den Einstellungen für den DD-Formmailer als “Contact page” eingetragen.

Dann wird eine Kopie der Datei index.php aus dem Wordpress-Wurzelverzeichnis erstellt und bearbeitet.
Originale index.php:

<?php
/* Short and sweet */
define('WP_USE_THEMES', true);
require('./wp-blog-header.php');
?>

Bearbeitete index.php:

<?php
/* Short and sweet */
define('WP_USE_THEMES', true);
require('../wp-blog-header.php');
?>

Kleine Änderung, große Wirkung, es ist nur ein Punkt beim require hinzugekommen.
Nun wird per FTP im WP-Wurzelverzeichnis ein Unterverzeichnis /kontakt/ angelegt und die geänderte index.php dort hinein kopiert.

Das wars, jetzt kann man die Kontaktseite aufrufen und Daten absenden, sofern man sonst auch alles andere beim DD-Formmailer richtig konfiguriert hat.
Man kann das auch bei mir hier testen, unter Kontakt, wo sonst? :-)

Und zum Schluß noch ein wichtiger Hinweis: Falls man im WP-Wurzelverzeichnis eine php.ini hat, muß diese ebenfalls mit in das /kontakt/-Verzeichnis kopiert werden, denn im Unterschied zur .htaccess werden die dort gemachten Einstellungen nicht auf Unterverzeichnisse “vererbt”.

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.

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.

Generell kann ich die Lektüre der Permalink-Codex-Seite wärmstens empfehlen. Da bekommt man einen guten Überblick, was Permalinks sind, wie sie funktionieren und was man alles damit machen kann (und was nicht). Die Seite sollte auch mal auf Deutsch bei Wordpress-Deutschland aufgenommen werden, viele Fragen im WPD-Forum drehen sich um Permalinks und wären sicher mit dieser Seite einfach beantwortet.

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

Könnte aber sein, das es tatsächlich bereits einen Nutzer gibt. Also falls jemand das erfolgreich bei seinem Strato-Blog im Einsatz hat, würde ich mich über eine kurze Rückmeldung mit Angabe der WP-Version, z.B. hier in den Kommentaren freuen. Oder ich schalte die Kommentare direkt bei der Beschreibungsseite frei. Ja, so werd ichs machen.

Natürlich sind auch Kritik, Problembeschreibungen oder Fragen jederzeit willkommen. Ob ich daruf eingegehen kann, weiß ich allerdings nicht ;-)

Da habe ich mich gestern hier abgemüht, den komplizierten Sachverhalt der Konfiguration eines benutzerdefinierten Fehlerdokumentes darzulegen und extra noch darauf hingewiesen, das mein Plugin des Schreiben der für Strato tödlichen mod_rewrite-Regeln unterbindet, nämlich einfach dadurch, daß ich eine Leerzeile schreiben lasse. Und heute fällt es mir wie Schuppen aus den Haaren, daß ich natürlich genau an der Stelle nur einfach mein “ErrorDocument 404″ einbauen muß. Also vergeßt den ganzen Zauber mit rumgefummle in der .htaccess oder dem Website-Configurator. Es geht viel einfacher so wie hier beschrieben:
Wordpress Permalinks

Praktisch eine Plug&Play-Lösung, Plugin runterladen, aufspielen, aktivieren und fertig.

Man sollt aber tunlichst darauf achten, daß das Plugin immer aktive ist, besonders dann, wenn etwas an den Permalinkeinstellungen verändert wird. Das schreiben der WP-Rewrite-Rules passiert aber auch an anderen Stellen, so z.B einfach schon, wenn die Optionenseite ‘Permalinks’ aufgerufen wird, oder auch wenn neue statische Seiten hinzugefügt oder diese verändert werden.

Achso, das Wetter war heute ähnlich wie gestern. Sonne, Sonne, Sonne und Hitze.

Viel Spaß und Erfolg :-)