Wir haben im Prinzip drei Möglichkeiten um die Editor-Einstellungen zu beeinflussen. Zum einen dann wenn sie definiert werden.

$editor_args = array(
	'textarea_name' => 'content',
	'textarea_rows' => 5,
	'media_buttons' => false,
	'tinymce' => false,
	'quicktags' => $quicktags_settings,
);

$editor_args = apply_filter( 'some_filter', $editor_args );

Leider ist dies nicht immer möglich, vor allen Dingen im gegebenen Fall nicht. Leider bietet auch die verwendetet Funktion wp_editor() noch die die Klasse _WP_Editors einen entsprechenden Filter an. Warum das so ist, sei mal dahingestellt. Ebenso das es bereits diverse Tickets im Trac zu den Thema gibt. Wenn man sein Ziel nicht auf direkten Weg erreichen kann, dann muss man manchmal einen kleinen Umweg gehen.

Eine Lösung wäre, wenn die Funktion wp_editor() plugable wäre, man sie also gegen eine eigene Funktion austauschen kann. Ist sie aber nicht, muss man den Hebel also woanders ansetzen.

Im betreffenden Fall wurde angeregt in der Klasse einen zusätzlichen Filter einzubauen. Bis dies umgesetzt ist, muss man sich also mit einen kleinen Workaround behelfen.
Wirft man einen Blick in den Code, so sieht man das abgefragt wird ob die Klasse _WP_Editors bereits geladen wurde. Nur wenn sie nicht geladen wurde, wird die Klasse aus dem WordPress-Core geladen. Für uns bedeutet dies also, wir können die Original-Klasse durch eine gleichnamige eigene Klasse ersetzen. Wir müssen nur dafür sorgen das unsere Klasse möglichst früh geladen wird. Am einfachsten erreicht man dies indem man einen der sehr früh ausgelösten Hooks benutzt um die eigene Klasse mittels require_once()/include_once() einzubinden.

Wie man sieht, gibt es in WordPress nicht nur eine Möglichkeit um etwas zu beeinflussen. Der einfachste Weg sind Filter und Actions um Variablen direkt zu beeinflussen. Sind diese nicht gegeben, schaut man sich an ob die betreffende Funktion etwas hergibt, also ob diese ggf. einen Filter/Action besitzt oder ob man sie ersetzen kann. Ist dies auch nicht gegeben, so kann man, wie hier im Beispiel, noch eine letzte Chance nutzen und eine Klasse komplett austauschen.

Der erste Schritt zum Plugin besteht also darin die Klasse _WP_Editors komplett in sein Plugin-Ordner zu kopieren. Der nächste Schritt ist das Einbinden der kopierten Klasse:

/**
 * Including the modified WP class _WP_Editors
 */
add_action(
	'plugins_loaded',
	function() {
		require_once dirname( __FILE__ ) . '/class-wp-editor.php';
	},
	0,
	0
);

Um zu überprüfen ob nun die kopierte oder die Original-Klasse geladen wird, kann man am Anfang der Kopie einfach mal ein die( 'Kopierte Klasse' ); setzen. Bricht WordPress nach einem Neuladen mit einen weißen Bildschirm ab auf dem nur “Kopierte Klasse” steht, so können wir sicher sein das nur unsere kopierte Klasse geladen wird. Nun geht es daran die kopierte Klasse zu modifizieren. Wie im Ticket vorgeschlagen ergänzen wir die Klasse um einen zusätzlichen Filter.

Da wir nun in der kopierten Klasse einen Filter haben den wir nutzen können, reicht es aus diesen zu setzen und in einer passenden Funktion die Werte entsprechend zu ändern.

/**
 * Add the filter to modify the editor settings
 */

add_filter( 'wp_editor_settings', 'modify_editor_settings', 0, 2 );

/**
 * Modify the editor settings. Currently only set the value for using the TinyMCE to true.
 *
 * @param array $settings Array with editor settings
 * @param array $editor_id The ID of the editor
 * @return array
 */
function modify_editor_settings( $settings, $editor_id ) {

	if ( 'attachment_content' == $editor_id )
		$settings['tinymce'] = true;

	return $settings;

}

Ich habe hier bewusst auf umständliche Prüfungen verzichtet um das Beispiel einfach zu halten. Man könnte zusätzlich darauf prüfen ob man sich auch tatsächlich in der Medienübersicht bzw. Medienbearbeitung befindet. Es wird lediglich geprüft ob die Editor-ID attachment_content ist und dann das Flag für den TinyMCE auf true gesetzt.
Durch Anpassung der Funktion modify_editor_settings() lässt sich so der TinyMCE für nahezu alle Eingabefelder aktivieren sofern die Editor-ID bekannt ist und das Eingabefeld über die Funktion wp_editor() erzeugt wird.

Das Plugin ist recht wartungsfreundlich. Sollte eines Tages ein Filter zum Modifizieren der Editor-Einstellungen vorhanden sein, so muss man nicht das komplette Plugin neu konstruieren. Es reicht aus die Einbindung der eigenen Klasse zu entfernen und ggf. den Filter-Namen anzupassen.

Sandboxes

Eine Möglichkeit ist Instant WordPress, welches auf Apache, PHP und MySQL setzt. Mit diesen Programm lässt sich WordPress inkl. der nötigen Umgebung z.B. auf einen USB-Stick installieren. Soweit eine tolle Sache, jedoch kann man die installierte Umgebung nur schlecht bis gar nicht anpassen. WordPress liegt i.d.R. in einer sehr alten Version bei, so dass man dies erst einmal updaten darf. Ob man PHP und MySQL überhaupt updaten kann, damit habe ich mich schon gar nicht mehr beschäftigt. Das Paket selber kann man ohne Fachwissen nicht anpassen, man muss nehmen was der Entwickler einen liefert.
So toll Instant WordPress auf den ersten Blick ist, für mein Problem, das mich aktuell beschäftigt, ist es nicht das richtige. Schnell fiel mir wieder Nginx ein, ein Webserver der vor einiger Zeit wegen seiner hohen Geschwindigkeit für viel Aufsehen sorgte. Für mich war Nginx eher deshalb interessant, da man ihn unabhängig von anderen, bereits installierten Komponenten, verwenden kann. Es wäre also möglich sich seine eigene Sandbox mit Nginx, PHP und MySQL zu basteln, was ich auch versucht habe. Jedoch ist das Frustlevel recht schnell sehr hoch. Denn im Netz findet man häufig nur Anleitungen zu Nginx 0.8.x, die aktuelle Version (Stand zur Veröffentlichung des Artikels) ist jedoch schon 1.5.8. Wobei “Anleitung” häufig geschmeichelt ist. Viele “Anleitungen” setzen enormes Wissen voraus und verschweigen das meiste. Irgendwann habe ich es dennoch geschafft Nginx mit PHP zum laufen zu bekommen, hatte dann aber Probleme mit dem von XAMPP installierten MySQL.

WT-NMP

Eine weitere Suche im Netz förderte dann WT-NMP zu Tage. WT-NMP kann man zwischen XAMPP und Instant WordPress ansiedeln. Das Paket liegt u.a. als Zip-Archive vor und kann sowohl als Verzeichnis auf der Festplatte als auch auf einen portablen Medium wie z.B. einen USB-Stick installiert werden. Der große Vorteil an dem Paket ist, es konfiguriert sich selbst, man muss also nicht händisch viel anpassen damit man es zum Laufen bekommt. Der dickste Bonuspunkt ist, wenn man das Paket z.B. auf der Festplatte installiert und eingerichtet hat und anschließend auf einen USB-Stick kopiert, ändert es automatisch die Konfiguration so um, dass es auch auf dem USB-Stick weiterhin läuft.
Ein weiterer Bonuspunkt ist das Fehlen von WordPress. Hört sich merkwürdig an, jedoch kann man sich so selber aussuchen welche Version oder gar welche Software man mit dem Paket bündelt. Da ich das Zip-Archiv und nicht den WT-NMP Installer verwende, kann ich ohne große Probleme alles ins Zip-Archiv schieben was ich brauche, sogar eine Auswahl an Plugins die ich immer wieder einsetze. Im Ergebnis habe ich dann ein Zip-Archiv das meinen Bedürfnissen entspricht, das ich selber Up-To-Date halten kann und an dem ich nicht jedes mal rumfummeln muss wenn ich eine neue WordPress-Sandbox benötige.
Nach der Installation schlägt das Herz dann sogar noch einen Ticken höher, denn schlauerweise sind neben Nginx, MySQL und PHP noch HeidiSQL und Adminer zur Verwaltung der Datenbanken installiert. Obendrein gibt es noch einen RegExp-Tester für PHP (PCRE) und JavaScript. Das man das PHP Error-Log mit einen Mausklick aufrufen kann, Testmails verschicken und XDebug, PHP XCache und PHP OPcache vorinstalliert sind, macht die Sache dann komplett rund. Alles in allem ein Traum für alle die WordPress in einer Sandbox betreiben wollen.

Wie geht’s?

Ich möchte nun im folgenden kurz beschreiben wie man zum einen das Paket für den Betrieb mit WordPress bereit macht und wie man WordPress damit zum Laufen bekommt. Und keine Angst, mehr als einen Texteditor und 5-10 Minuten Zeit braucht es nicht. Als erstes brauchen wir natürlich WT-NMP und WordPress.

• WT-NMP 13.12 als Zip-Archive
• WordPress 3.8 (deutsche Version)

Es gibt zwar neben dem Zip-Archive auch noch einen Windows-Installer, den kann man jedoch nicht so bequem anpassen wie das Zip-Archive. Nach dem Download entpackt man das Zip-Archive in ein Verzeichnis, bei mir ist es das Laufwerk D:/ und als Verzeichnis WT-NMP. Wenn ihr es woanders hin entpackt, kein Problem. Das Laufwerk ist eh egal, der Verzeichnisname sollte zum besseren Verständnis jedoch WT-NMP lauten.
Im Verzeichnis WT-NMP können wir den Unterordner WWW sehen. Man kann es sich fast denken, dass ist der Document Root, also das Verzeichnis in dem alle Web-Projekte landen werden. Dorthin entpacken wir nun WordPress ins Verzeichnis wordpress (man kann natürlich auch einen anderen Namen wählen). Die Verzeichnisse project1, project2 und project3 kann man löschen. Die letzten beiden genannten sind ohnehin leere Verzeichnisse, in project1 ist lediglich eine Testdatei die uns hier jedoch nicht weiter interessieren soll.
An dieser Stelle könnte man das Verzeichnis WT-NMP zu einen Archive packen und hätte so schon mal eine gute Ausgangsbasis für eine fertige Sandbox. Man kann aber auch WT-NMP und WordPress komplett konfigurieren, so dass man in Zukunft nur noch das Zip-Archive entpacken muss um quasi WordPress Out-Of-The-Box starten zu können. Gehen wir zur Konfiguration über.

Konfiguration der php.ini

Eine Datei muss man auf alle Fälle anfassen, und zwar die php.ini. Hier gilt es einige Erweiterungen (Extensions) zu aktivieren und einige kleinere Einstellungen zu korrigieren. Wichtig ist jedoch das man nicht die php.ini aus dem PHP-Verzeichnis nimmt, sie dient als Vorlage wenn WT-NMP automatisch angepasst wird. Alle Dateien die wir anpassen müssen finden wir im Verzeichnis conf!

Beginnen wir mit den Extensions und öffnen die Datei conf/php.ini im Texteditor unserer Wahl. Die Extension php_xcache und die Zend Extension php_opcache kann man aktivieren, muss man aber nicht. Es gibt wohl einige Probleme mit diesen Erweiterungen, so dass man es mal ausprobieren muss ob man besser mit aktivierten oder deaktivierten Cache-Extensions zurecht kommt. Ein aktiviertes XDebug (die Erweiterung steht ganz am Ende der php.ini) gehört zum guten Ton und sollte aktiviert werden. Zudem musste ich auf meinem System (Windows7 64bit) noch php_mysql aktivieren da ich ansonsten keine Verbindung zur Datenbank bekommen habe.
memory_limit sollte man von 64MB auf 128MB herauf setzen. Bei einer lokalen Installation können es auch gerne mehr sein damit PHP möglichst flüssig arbeitet. short_open_tag stellen wir mal brav auf Off, das sollte nirgendwo mehr aktiviert sein. Ob man allow_url_fopen zulässt oder nicht, muss man ggf. im Einzelfall entscheiden. Bei mir steht es eigentlich immer auf On da es vieles leichter macht.
Eine Besonderheit ist noch unter disable_classes zu beachten. Hier sollte man alle deaktivierten PHP-Klassen entfernen da es sonst unter WordPress von SimplePie Fehlermeldungen hagelt. Auch die Liste darüber mit den disable_functions sollte man mal kurz durchschauen. In einer reinen Entwicklungsumgebung stehen dort einige Funktionen die man ganz gut gebrauchen kann und ansonsten nicht zur Verfügung stehen würden.
Im Großen und Ganzen war es das auch schon mit den Änderungen an der php.ini. Erfahrene Benutzer können noch mal alle Einstellungen durchgehen und ihren Bedürfnissen anpassen, für die Mehrheit sollte es so passen.

Eigener Server und Domäne

Wenn man nicht ständig über http://localhost/wordpress auf sein Blog zugreifen möchte und stattdessen lieber eine eigene Domäne verwenden möchte, so muss man sich noch einen zusätzlichen Server in der nginx.conf anlegen und einen Eintrag in der hosts Datei von Windows.
Der Server ist schnell angelegt. Dazu kopieren wir uns einfach den bereits vorhandenen Server und fügen die Kopie hinter den bestehenden an. Lediglich die Zeilen mit listen, server_name und root müssen wir anpassen. In der Zeile listen löschen wir nur den default_server, den server_name ändern wir auf unsere Wunsch-Domäne und bei root ergänzen wir /wordpress damit der root-Eintrag auch auf unsere WordPress-Installation zeigt.

	server {
		listen       127.0.0.1:80;
		server_name  samplewp.tld;

		root "d:/wt-nmp/www/wordpress";
		autoindex on;

		allow		127.0.0.1;
		deny		all;

		# deny access to .htaccess files, if Apache's document root
		# concurs with nginx's one
		#
		location ~ /\.ht {
		    deny  all;
		}

		location ~ \.php$ {
		    try_files $uri =404; 
	            fastcgi_pass	php_farm;
		    include		nginx.fastcgi.conf;
	        }

	}

So sieht das ganze bei mir aus. Das ist lediglich eine Grundkonfiguration, wer mehr benötigt (z.B. URL-Rewriting), muss sich näher mit Nginx beschäftigen, dass geht etwas über diesen Artikel hinaus. In der Windows hosts-Datei machen wir dann noch den Eintrag für unsere Domäne was bei mir so aussieht: 127.0.0.1 samplewp.tld

An der mysql.ini musste ich nichts verändern, hier kann es aber sinnvoll sein die Einstellungen für wait_timeout und connect_timeout hoch zu setzen. Vor allem wenn man WT-NMP auf einen langsamen USB-Stick installiert können schon mal längere Wartezeiten auftreten.

Erster Start

Der WT-NMP Launcher

Nun müssen wir noch Nginx, MySQL und PHP starten. Das erfolgt recht bequem über den WT-NMP Launcher WT-NMP.exe im Verzeichnis WT-NMP. Mit dem Launcher lassen sich auch die einzelnen Prozesse von Nginx, MySQL und PHP starten und stoppen, was recht wichtig ist wenn man Änderungen an den jeweiligen Einstellungs-Dateien (ini-Dateien) vorgenommen hat. Im Launcher sieht man neben den einzelnen Komponenten auch noch ein paar Icons, was sich dahinter verbirgt wird angezeigt wenn man mit dem Mauspfeil über das jeweilige Icon verbleibt. Das einzig wirklich interessante dürfte der Datenbank-Manager (HeidiSQL) neben der MySQL-Komponente sein.
Jetzt kann man auch schon loslegen und im Browser seiner Wahl testweise mal http://localhost/wordpress bzw. seine zuvor angelegte Domäne http://samplewp.tld aufrufen. WordPress wird uns nun mit der einen oder anderen Meldung beglücken das dies und jenes noch nicht vorhanden sei. Bisher haben wir ja auch weder Datenbank noch Datenbank-Benutzer oder eine wp-config.php angelegt.

Datenbank anlegen

Der Startbildschirm von WT-NMP im Browser

Beginnen wir mit dem Anlegen einer Datenbank. Dazu rufen wir im Browser einfach http://localhost auf und sollten die Startseite von WT-NMP sehen (siehe Screenshot). Mit einen Klick auf Adminer Database Manager gelangen wir zur Datenbankverwaltung. Es ist schon fast Geschmackssache ob man HeidiSQL oder Adminer verwendet. Adminer ist jedoch deutlich schlanker und übersichtlicher.
Im Adminer oben rechts eine neue Datenbank anlegen, einen Namen für die Datenbank vergeben und den Rest erst mal so belassen wie es ist. Danach sollte man sich einen neuen Benutzer anlegen, dazu klickt man oben rechts auf Rechte. Nun werden die vorhandenen Benutzer angezeigt und unterhalb der Tabelle mit den Benutzern der Link für Neuer Benutzer. Erneut einen Namen eingeben, Passwort und die Checkboxen All Privileges und Grand option anhaken, mit Speichern bestätigen und das war es dann auch schon.

Auf in den Schlussspurt. Dazu öffnen wir die wp-config-sample.php-Datei aus unserer WordPress-Installation und passen sie wie gewohnt mit Datenbankname, Nutzer und Passwort an. Noch bequemer geht es eigentlich nur indem man http://samplewp.tld (bzw. http://localhost/wordpress) aufruft und die wp-config.php von WordPress erstellen lässt. Diejenigen unter uns die öfters WordPress einrichten und zusätzliche Angaben in der wp-config.php machen werden ersten Weg wählen, ansonsten reicht halt auch der bequeme Weg.

Damit sind wir eigentlich auch schon fertig. Ich denke mal wer öfters WordPress installiert und auch schon mal mit XAMPP gearbeitet hat, dürfte für alles zusammen kaum mehr als 10 Minuten benötigen. Wobei man sich die Arbeit ab jetzt auch sparen kann, denn es reicht aus das Verzeichnis WT-NMP als Zip-Archive abzuspeichern und hat ab dann immer ein frisches WordPress komplett installiert parat.

Bonus-Runde

Adminer im Einsatz

Also auf zur Bonus-Runde. Es gibt tatsächlich noch Server die mit PHP5.2 arbeiten bzw. Nutzer die PHP5.2 verwenden (müssen). Für einen Entwickler ist das recht lästig, muss man doch ständig irgendwo einen Server mit PHP5.2 parat haben für den Fall der Fälle das man was entwickeln oder testen will. WT-NMP macht uns hier das Leben sehr leicht. Es wird zwar mit PHP5.4 bzw. PHP5.5 ausgeliefert, jedoch ist es sehr einfach auch noch PHP5.2 nachzurüsten. Dazu benötigt man lediglich das Zip-Archive von PHP5.2 Non Thread Safe. Das NTS (Non Thread Safe) ist wichtig, da PHP ansonsten nicht starten will. Das Zip-Archive bekommt man bei PHP.net im Museum (letzte verfügbare Version dort ist PHP-5.2.16-nts (Windows Binairies)). Wer mit der von mir verlinkten Version nichts anfangen kann, muss ein wenig nach der für sein Betriebssystem passenden Version suchen.
Das Zip-Archive entpacken wir einfach in einen Ordner in WT-NMP/bin/ (z.B. WT-NMP/bin/php-5.2.16). Der WT-NMP Launcher bietet uns ab nun die Wahl zwischen den installierten PHP-Versionen an. Zum Wechseln der PHP-Version einfach den PHP-Prozess stoppen, Version wechseln und der Neustart von PHP wird automatisch eingeleitet. Bequemer geht es nun doch wirklich nicht, oder!?
Ich habe es nun nicht ausprobiert mit welchen PHP-Versionen das funktioniert. Da aber immer die gleiche php.ini verwendet wird, hängt es wohl in erster Linie davon ab ob die PHP-Version mit der vorhandenen php.ini zusammen arbeitet.

Fazit

Für mich ist WT-NMP momentan das ultimative Tool wenn es darum geht mit verschiedenen PHP-Versionen zu entwickeln oder WordPress in einer Sandbox oder auf einen USB-Stick zu installieren. Bisher habe ich nur ein wenig mit WT-NMP herum gespielt und mich noch nicht näher z.B. mit der Konfiguration von Nginx beschäftigt. Auch habe ich noch nicht getestet ob die Aktivierung der Cache-Extensions (XCache und OPcache) wirklich so negative Auswirkungen haben wie auf der WT-NMP Webseite beschrieben. Deswegen würde ich mich über ein paar Erfahrungsberichte, gerne auch in Form eines Blog-Posts, freuen.

Auf die Variable x die in Funktion y definiert wurde, kann nicht ohne weiteres in Funktion z zugegriffen werden. Das Problem ist der sogenannte Scope, also der Gültigkeitsbereich in PHP. WordPress umgeht das Problem einfach dadurch, indem es recht rücksichtslos fast alle seine Variablen mit den Schlüsselwort global in den globalen Namensraum verfrachtet und somit überall verfügbar macht. Das ist zwar eine sehr einfache Lösung, jedoch auch eine sehr egoistische. Nehmen wir einfach mal an wir hätten ein Plugin oder Theme das die Variable foo verwendet.

<?php
function set_foo( $var ) {
  global $foo;
  $foo = $var;
}

function print_something() {
  global $foo;
  print( "Foo is {$foo}<br>" );
}

function do_something() {
  global $foo;
  $foo = (int) $foo;
  $foo++;
}

Prefixen

Nun kommt die nächste Version von WordPress raus und BÄMM, WordPress verwendet selber die Variable foo und macht sie mittels global auch noch überall verfügbar. Eine Katastrophe, denn nun müssten wir unser Plugin/Theme komplett umschreiben.
Bisher vermied man dieses Problem indem man alle seine Variablen und Funktionen mit einem Prefix versah, also anstatt einfach nur $foo mit einem Prefix wie z.B. $fb_foo. Diese Lösung hat jedoch auch seine Nachteile. Frank Bültge hatte seit jeher den Prefix fb_ verwendet, dieser wird jedoch mittlerweile häufig im Zusammenhang mit FaceBook verwendet. Einen kurzen und recht eindeutigen Prefix zu finden, dürfte so langsam schwer werden. Könnte man hingehen und einen längeren Prefix verwenden, zum Beispiel frabue_ der so lange funktioniert, bis jemand anderes ihn ebenfalls verwendet. Eine Rüstungsspirale die dazu führt das der Prefix irgendwann länger ist als der Variablen- oder Funktionsname.

Namespaces

Seit PHP5.3 haben wir die Möglichkeit Namespaces zu nutzen. Namspaces lösen eine ganze Reihe solcher und vergleichbarer Probleme, weshalb ich inzwischen nur noch für PHP5.3+ schreibe. Man sollte aber auch nicht verschweigen, dass man sich angewöhnen muss seinen Code anders zu schreiben. Am Anfang bedeutet dies etwas Frust, der schwindet jedoch recht schnell weil die Vorteile überwiegen. Leider hat nicht jeder die Möglichkeit PHP5.2 einfach zu ignorieren. Arbeitet man im Kundenauftrag und weigert der Kunde sich beharrlich auf PHP5.3+ zu wechseln, kann man nicht auf Namespaces zurück greifen.

Containern

Aber wir können zumindest für unsere Variablen unseren eigenen kleinen Namespace basteln. Und den können wir dann auch noch wesentlich komfortabler ausstatten als den globalen Namensraum. Dazu nutzen wir eine Klasse die in der Grundversion aus lediglich zwei magischen Methoden besteht, __set() und __get(). Der Klasse geben wir noch eine statische Eigenschaft mit in der wir dann alle unsere Variablen speichern können. Der große “Zauber” an dieser Klasse besteht im Grunde genommen darin, dass statische Eigenschaften immer ihren Wert behalten, egal wie viele Instanzen wir von der Klasse erstellen.

<?php 
class DataContainer
{
  public static $data = array();

  public function __set( $name, $value ) {
    self::$data[$name] = $value;
  }

  public function __get( $name ) {
    if ( isset( self::$data[$name] ) )
      return self::$data[$name];
    else
      return null;
  }
}

Die Verwendung der Klasse ist recht simpel. Wollen wir eine Variable setzen, erzeugen wir eine Instanz der Klasse und setzen die Variable. Wollen wir an einer anderen Stelle die gleiche Variable wieder zurück lesen, erzeugen wir eine Instanz und lesen ganz einfach die Variable.

<?php
function set_foo( $var ) {
  $dc = new DataContainer;
  $dc->foo = $var;
}

function print_something() {
  $dc = new DataContainer;
  $foo = $dc->foo;
  print( "Foo inside DataContainer: {$dc->foo}
 Foo as local variable: {$foo}
" );
}

function do_something() {
  $dc = new DataContainer;
  $foo = &$dc::$data['foo'];
  $foo = (int) $foo;
  $foo++;
}

set_foo( '1' );
do_something();

$dc = new DataContainer();
echo "Foo is now: {$dc->foo}";

Wie man an der Funktion do_something() sieht, ist es auch möglich die Variablen innerhalb vom DataContainer mittels Referenz zu bearbeiten, so dass man bearbeitete Werte nicht zwangsweise wieder zurück in den DataContainer schreiben muss.

Vererbung

Nun ist es unter Umständen etwas mühselig in jeden Funktionsaufruf eine neue Instanz des DataContainers zu erzeugen. Arbeitet man objektorientiert, ist es etwas einfacher, da die Klassen den DataContainer erweitern können.

<?php
class Bar extends DataContainer
{
  public function hello_foo() {
    printf( 'Foo used inside %s: %s
', __CLASS__, $this->foo );
  }
}

$bar = new Bar();
$bar->hello_foo();

Alle Variablen die im DataContainer abgelegt, gelöscht oder geändert werden, sind in der Klasse Bar genauso verfügbar. Vererbung ist nicht gerade die Paradedisziplin von PHP weswegen man wohl eher auf Dependency Injection zurück greifen würde. Ein weiterer, meinem persönlichen Geschmack nach, besonders wertvoller Vorteil von DI ist, man kann seinen DataContainer Mocken und die testbarkeit seiner Klassen deutlich erhöhen. DI, Unittest und Mockings sind aber ein ganz anderes Thema.

RODC – Read Only DataContainer

Es kann natürlich sein das unser Theme oder Plugin durch Filter und Hooks erweitert werden kann, dann könnte es durchaus sein das wir einmal gesetzte Variablen davor schützen wollen das sie von unbekannten Code überschrieben werden. Nutzt man den globalen Namensraum, so ist das nahezu unmöglich. In WordPress gibt es z.B. keine Möglichkeit die globale Variable $post, die eine zentrale Rolle spielt, vor dem Überschreiben zu schützen. Jeder kann sie jederzeit löschen oder ändern, was dazu führt das andere Codeabschnitte, die diese Variable benötigen, unter Umständen versagen. Mit einem DataContainer ist das deutlich einfacher zu handhaben, wir bauen einfach eine Methode ein die bestimmte Variablen als Read Only kennzeichnet.

<?php
class DataContainer
{
  public static $data = array();

  public static $protected = array();

  public function __set( $name, $value ) {
    if ( ! in_array( $name, self::$protected ) )
      self::$data[$name] = $value;
  }

  public function __get( $name ) {
    if ( isset( self::$data[$name] ) )
      return self::$data[$name];
    else
      return null;
  }

  public static function protect( $name ) {
    if ( ! in_array( $name, self::$protected ) )
      array_push( self::$protected, $name );
  }
}

function good_foo() {
  $dc = new DataContainer();
  $dc->foo = 'protected foo';
  $dc->bar = 'unprotected bar';
  $dc->protect( 'foo' );
}

function bad_bar() {
  $dc = new DataContainer();
  $dc->foo = 'hahaha!';
  $dc->bar = 'I change everything!';
}

$dc = new DataContainer();

echo "Set <code>foo</code> to <b>protected foo</b> and <code>bar</code> to <b>unprotected bar</b><br>";
good_foo();

echo "Try to overwrite <code>foo</code> and <code>bar</code><br>";
bad_bar();

echo "<code>foo</code> is still <b>{$dc->foo}</b> and <code>bar</code> is now <b>{$dc->bar}</b><br>";

Das dürfte nun nicht jeden Tag vorkommen das man seine Variablen schützen muss, zeigt aber schön welche Vorteile ein DataContainer gegenüber den globalen Namensraum hat. Man ihn nämlich nahezu nach belieben an seine Bedürfnisse anpassen.

Shutdown

Zum Schluss noch ein kleines Beispiel wie ich bei einem Plugin, an dem ich gerade schreibe, mit Hilfe eines DataContainers ein paar Probleme gelöst habe.
Das Plugin erforderte die Zwischenspeicherung einiger Daten da diese zur Laufzeit erstellt werden und über verschiedene Seitenaufrufe verfügbar bleiben müssen. Gegeben sei also z.B. ein Array $a das zur Laufzeit befüllt wird und bei einem Ajax-Request verfügbar sein muss. Mein erster Lösungsansatz war die Verwendung von $_SESSION, denn genau dazu sind Sessions da. Um Daten über verschiedene Seitenaufrufe breit zu stellen. Um sicher zu gehen das am Ende des Skripts auch alle Daten in der Session gespeichert wurden, habe ich shutdown Hook von WordPress benutzt. Dieser Hook wird bei Beendigung des Skriptes ausgeführt, zu einem Zeitpunkt also, wenn alle Daten vorhanden sein sollten. In der Callback-Funktion habe ich dann einfach alle Daten in die Session geschrieben und die Session geschlossen.
Nun taten sich verschiedene Probleme auf. Zum einen ist das recht unflexibel. Fügt man noch weitere Daten hinzu, muss man sich darum kümmern das auch diese in der Session gespeichert werden. Genauso wenn Daten entfallen, muss man sich darum kümmern das diese, nicht mehr vorhandenen Daten, nicht gespeichert werden. Der erste Lösungsansatz war dann anstatt einzelner Arrays einen DataContainer zu verwenden und dann den kompletten DataContainer in der Session zu speichern. Das funktioniert erstaunlich gut, jedoch musste ich mich immer noch selber darum kümmern das die Daten in der Session gespeichert werden.
Zudem ist der shutdown Hook nicht wirklich sicher. Wird das Skript z.B. mit einem exit() die() beendet bevor der Hook registriert wird, werden die Daten nicht in der Session gespeichert. Dieses Problem lässt sich dadurch lösen, indem man das Speichern und lesen der Daten in bzw. aus der Session in den DataContainer verlagert.

<?php
class DataContainer
{
	const SESSION_KEY = 'Example_DataConatiner';

	public static $data = array();

	public function __construct() {
		( ! session_id() ) AND session_start();

		if ( isset( $_SESSION[self::SESSION_KEY] ) && ! empty( $_SESSION[self::SESSION_KEY] ) )
			self::$data = $_SESSION[self::SESSION_KEY];

		register_shutdown_function( array( $this, '__destruct' ) );
	}

	public function __destruct() {
		( ! session_id() ) AND session_start();

		$_SESSION[self::SESSION_KEY] = self::$data;
		session_write_close();
	}

	public function __set( $name, $value ) {
		self::$data[$name] = $value;
	}

	public function __get( $name ) {
		if ( isset( self::$data[$name] ) )
			return self::$data[$name];
		else
			return null;
	}

	public static function reset() {
		self::$data = array();
		unset($_SESSION[self::SESSION_KEY]);
		session_write_close();
	}
}

$dc  = new DataContainer();
$uri = $_SERVER['PHP_SELF'];

if ( null === $dc->session_data ) {
	$dc->session_data = 'Value from previous page request';
	echo 'This is the first run<br>';
	die( "<a href='{$uri}?run=2'>Klick</a>" );
}

$pagerequest = filter_input( INPUT_GET, 'run', FILTER_SANITIZE_NUMBER_INT );
echo "This is the {$pagerequest}nd run with <b>{$dc->session_data}</b> from session-data";
$dc::reset();

Das funktioniert schon recht wunderbar. Durch die __destruct() Methode wird der Inhalt des DataContainers in der Session gespeichert sobald er zerstört wird. Da PHP am Ende eines Skriptes alle bestehenden Objekte zerstört (schließt), wird die __destruct Methode automatisch am Ende eines Skriptes aufgerufen. Im Beispiel oben wird die __destruct() Methode mittels register_shutdown_function() noch zusätzlich registriert, so dass sie beim Beenden des Skriptes auch definitiv ausgeführt wird. Verwendet man anstatt der magischen __destruct() Methode eine eigene Methode und registriert sie mit register_shutdown_function(), so kann man den DataContainer verwerfen ohne das seine Werte gespeichert werden, die Werte werden jedoch automatisch am Ende des Skriptes gespeichert.

Allerdings wurden Sessions zu einen Zeitpunkt erfunden als Browser keine Tabs kannten und anscheinend geht jeder Browser etwas anders damit um. Ich hatte zumindest massive Probleme mit dem FireFox wenn ich mehr als einen Tab zum gleichen Server offen hatte (z.B. die Startseite in den einen Tab, einen Artikel in der Einzelansicht in einen anderen). Chrome und Opera können das besser, aber ich kann meinen Besuchern ja schlecht vorschreiben welchen Browser sie zu benutzen haben oder wie viele Tabs sie öffnen dürfen.
WordPress bietet uns einen guten Ersatz für Sessions sofern man damit Probleme hat. Wir verwenden einfach Transients zum Speichern der Daten. Man muss hier abwägen ob die zusätzlichen DB-Zugriffe und vor allem die Menge an Daten die man speichern möchte dies rechtfertigt. Transients haben den Vorteil das man recht genau einstellen kann wie lange sie gültig sind. Das geht zwar mit Sessions auch, jedoch erlaubt nicht jeder Hoster das Verändern des Wertes für die Session-Lifetime. Transients sind sogar beständiger als Sessions, so kann man einen Transient an einen Login koppeln und somit eine Art von Server-Cookie umsetzen.

Fazit

Ich hoffe es ist deutlich geworden das der globale Namensraum eigentlich mehr Nach- als Vorteile hat und das man mit nur wenig Aufwand eine bessere Lösung bekommen kann die man nach seinen eigenen Bedürfnissen anpassen kann. Vor allem das automatische Speichern, ob in Sessions oder Transients, erleichtert die tägliche Arbeit enorm da man sich weniger Gedanken darum machen muss ob man nun alles gespeichert hat oder nicht. Der DataContainer lässt sich enorm ausbauen, denkbar wäre z.B. auch eine Methode die Werte aus einen Aufruf der Settings-API validiert und speichert. Am Ende des Skriptes werden die Daten automatisch in die Options geschrieben, stehen aber während der Laufzeit weiterhin zur Verfügung ohne das man sie sich extra aus den Options holen müsste.
Vor allem das man den DataContainer, und somit auch Zugriffe auf Transients und die Options-Tabelle, sehr einfach mocken kann, erleichtert das Unittesting ungemein wodurch man wiederum viel Zeit und Mühe beim Programmieren spart.
Alle in diesen Artikel verwendeten Skripte sind als Gist erhältlich für den Fall das sich jemand dazu ermuntert fühlt ein wenig mit DataContainern zu experimentieren.

Der offensichtlichste Unterschied ist erst einmal der Rückgabewert. is_email() prüft ob eine gegebene E-Mail Adresse überhaupt den Kriterien entspricht und gibt einen String zurück wenn dem so ist. Andernfalls gibt is_email() false zurück. sanitize_email() hingegen gibt entweder einen String mit einer gültigen E-Mail Adresse oder einen leeren String zurück.
is_email() gibt also einen boolschen Wert oder einen String, sanitize_email() immer einen String zurück.

Nun könnte man mit einer einfachen Typumwandlung is_email() dazu bringen ebenfalls immer einen String zurück zu geben. (string) is_email( $email ) würde sich nahezu gleich verhalten wie sanitize_email(). Im Erfolgsfall eine gültige E-Mail Adresse, im Fehlerfall einen leeren String. Stimmt das? Überprüfen wir es:

$emails = array( 'foo@bar.com', 'baz-at-example-org', 'öttö@wördpäss.com', 'meh@cöm.com' );
echo '<ol>';
array_walk(
	$emails,
	function ($email) {
		$empty = 'an empty string';
		$is = (string) is_email( $email );
		$se = sanitize_email( $email );

		printf(
			'<li>%s - %s (%s)</li>',
			( '' != $is ) ? $is : $empty,
			( '' != $se ) ? $se : $empty,
             $email
		);
	}
);
echo '</ol>';

Die Ausgabe sieht in etwa so aus:

1. foo@bar.com – foo@bar.com (foo@bar.com)
2. an empty string – an empty string (baz-at-example-org)
3. an empty string – tt@wrdpss.com (öttö@wördpäss.com)
4. an empty string – meh@cm.com (meh@cöm.com)

Wie man sehen kann, gibt (string) is_email( $email ) wie erwartet bei ungültigen E-Mail Adressen einen leeren String zurück. Das WordPress glaubt das Umlaute in E-Mail Adressen nicht erlaubt seien, lass wir an dieser Stelle mal dahingestellt. WordPress kann halt (noch) nicht mit Umlautdomains umgehen.
Viel interessanter ist die Ausgabe von sanitize_email(). Auch sanitize_email() kann nicht mit Umlauten umgehen, streicht sie aber einfach aus der E-Mail Adresse anstatt sie z.B. zu kodieren.

Das führt nun natürlich zu Problemen wenn man es nicht weiß. Sollte mal eine größere Anzahl an E-Mails nicht versendet werden, kann das mitunter daran liegen das man vergessen hat vor dem Speichern zu prüfen ob WordPress damit umgehen kann.

// FALSCH
$user = array(
  'name' => 'Hans'
  'email' => sanitize_email( $email )
);
update_option( 'awesome_options', $user );

// Richtig
$user = array(
  'name' => 'Hans'
  'email' => sanitize_email( (is_email( $email ) )
);
update_option( 'awesome_options', $user );

Merke!

Jede E-Mail Adresse sollte bevor sie mit sanitize_email() verarbeitet wird erst mit is_email() validiert werden. Ansonsten bekommt man E-Mail Adressen die vielleicht lustig aussehen, es aber definitiv nicht sind.

Die einfachste Lösung ist wie so oft ein Filter, der allerdings etwas versteckt ist. Die Funktion add_meta_box() selber hat keinerlei Filter oder Actions in die man sich einhängen könnte.
Dafür aber die Funktion die dafür zuständig ist die Titleleiste der Metabox darzustellen. Damit es etwas klarer ist um welchen Teil des HTMLs es hier geht, auszugsweise das HTML der Excerpt-Metabox:

<div id="postexcerpt" class="postbox">
  <div class="handlediv" title="Zum umschalten klicken">
    <h3 class="hndle">
      <span>Auszug</span>
    </h3>
   <div class="inside">
[...]
    </div> <!-- Ende div .inside -->
  </div> <!-- Ende div .handlediv -->
</div> <!-- Ende div #postexcerpt -->

Der Filter kann CSS-Klassen zum äußersten Div-Container, hier im Beispiel mit der ID postexcerpt, hinzufügen. Somit ist es dann auch möglich im Stylesheet die nachfolgenden HTML-Elemente zu stylen.

add_action( 'add_meta_boxes', 'add_my_metabox' );

function add_my_metabox() {
  $id       = 'my-metabox';
  $title    = 'My Metabox';
  $callback = 'my_metabox_content';
  $page     = 'post';

  add_meta_box( $id, $title, $callback, $page );

  add_filter( "postbox_classes_{$page}_{$id}", 'minify_my_metabox' );
}

function my_metabox_content() { ... }

/**
 * Add extra css-classes to a meta-box
 *
 * @param array $classes Array with css-classes
 */
function minify_my_metabox( $classes ) {
  array_push( $classes, 'closed' );

  return $classes;
}

In der Funktion add_my_metabox() wird zunächst einmal ganz normal eine Metabox erzeugt. Anschließend wird jedoch noch ein Filter gesetzt der als Callback die Funktion minify_my_metabox() aufruft. Der Hook für den Filter muss man um die ID der Metabox und den Post-Type ergänzen. An dieser Stelle wird es ein wenig kompliziert. Im Codex wird der Begriff “Post Type” verwendet, da der Filter und die zugehörige Funktion jedoch undokumentiert sind, muss man im Quellcode nachschauen. Und dort wird “page” als Variablenname verwendet.
Ich persönlich finde den Begriff “page” sinnvoller, da man mit der gleichen Methode auch z.B. die Widgets im Dashboard beeinflussen kann (siehe Beispiel unten). Als “page” müsste man dazu lediglich dashboard angeben und kann dann eigenen oder bereits vorhandenen Widgets, weitere CSS-Klassen hinzufügen. Im Codex findet man bei remove_meta_box() noch ein paar weitere mögliche Werte für page. Hier wird übrigens wieder von page gesprochen, im Gegensatz zu post type bei add_meta_box().

function register_dash_widget(){

	$id   = 'debugoutput';
	$page = 'dashboard';

	wp_add_dashboard_widget(
		$id,
		'Debug Output',
		function () { echo 'Hello World!'; }
	);

	add_filter(
		"postbox_classes_{$page}_{$id}",
		function ( $classes ) {
			array_push( $classes, 'closed' );
			return $classes;
		}
	);

}

add_action( 'wp_dashboard_setup', 'register_dash_widget' );

Die Callback-Funktion minify_my_metabox() ist dann wieder recht unspektakulär. Sie erwartet als einzigen Parameter ein Array mit den CSS-Klassen. Fügt man z.B. die Klasse closed hinzu und gibt das Array zurück, so wird die Metabox (oder das Widget) minimiert anstatt geöffnet dargestellt. Denkbar wäre es natürlich auch eine CSS-Klasse alert hinzuzufügen um eine Metabox (oder Widget) farblich hervorzuheben.

Ein paar Basics

Im Grunde genommen nutze ich immer zwei Git-Repos. Zum einen ein lokales Repo im Ordner in dem ich den Code entwickele. Zum anderen ein entferntes (remote) Repo in dem ich meine Arbeit speichere. Viele nutzen als Remote-Repo GitHub, BitBucket oder einen Firmenserver. Ich nutze aus verschiedenen Gründen einen Ordner in meiner Dropbox. Da im späteren Verlauf eine lokale Kopie des SVN-Repos benötigt wird, empfiehlt es sich neben den üblichen Remote-Repos (GitHub, BitBucket, usw.) ein Remote-Repo auf der eigenen Festplatte einzurichten. Das muss nicht zwingend in einer Dropbox sein, bietet sich jedoch an wenn man, so wie ich zum Beispiel, an mehreren Rechnern oder im Team an einem Plugin arbeitet.
Beispielhaft sieht die Ordnerstruktur nun so aus das /d/local/plugin-name/ der Ordner ist in dem entwickelt wird und /d/dropbox/plugin-name/ der Ordner für das Remote-Repo darstellt. Um es etwas einfacher zu machen verwende ich ‘local‘ als Namen für den lokalen Entwickelungs-Ordner und ‘remote‘ als Namen für den Ordner der das Remote-Repo enthält.

Hooks

Um das automatische Committen ins SVN-Repo durchzuführen hatte ich recht schnell git hooks als Lösungsweg ausgespäht. Dank einer guten Dokumentation zu Git und sich selbst installierende Beispielen, fand ich dann auch schnell einen passenden Hook und wie ich ihn zu meinen Zwecken nutzen kann. Bei dem Hook handelt es sich um den update hook, der immer dann ausgeführt wird, wenn in ein Remote-Repo hinein gepusht wird. Um das zu verstehen, ein kurzer Einblick in die Hooks von Git.
Es gibt Hooks die nur dann ausgeführt werden wenn eine Aktion im lokalen Repo durchgeführt wird (z.B. beim Committen). Und es gibt Hooks die nur im Remote-Repo ausgeführt werden (z.B. beim Pushen). Die Hooks unterscheiden sich allerdings nicht nur darin wann (und wo) sie ausgeführt werden, sondern auch darin, welche Parameter sie mitgegeben bekommen. Da es keinen Hook gibt den man im lokalen Repo nutzen kann sofern man feststellen möchte ob ein Tag gesetzt bzw. gepusht wurde, entschied ich mich auf das Remote-Repo auszuweichen wo es den update hook gibt der von Git die benötigten Parameter übergeben bekommt.

Das Setup

Nun müssen noch ein paar Kleinigkeiten eingerichtet werden. Das git init im local Ordner dürfte mittlerweile in Fleisch und Blut übergegangen sein. Als nächstes wird mit einer Zeile sowohl das remote Verzeichnis als auch die Kopie des SVN-Repos angelegt. Dazu nach /d/dropbox/ wechseln, eine Shell öffnen und svn checkout http://plugins.svn.wordpress.org/plugin-name eingegeben. SVN erzeugt einen Ordner plugin-name der bereits alle für SVN benötigten Unterordner enthält. Da nun noch das Remote-Git-Repo fehlt, wird in den Ordner plugin-name gewechselt und mit git init --bare ein Remote-Git-Repo angelegt. Wer es mal ausprobiert, wird merken das git svn im Grunde genommen nichts anderes macht. Es werden einfach zwei Repos unterschiedlicher CVS in einen Ordner untergebracht. Zum Schluß wird der remote noch in local als Remote-Repo hinzugefügt: git remote add dropbox /d/dropbox/plugin-name
Jetzt ist das Setup fast geschafft, was noch fehlt ist das Script für den update hook. In /d/dropbox/plugin-name/hooks/ finden sich einige Beispiele für git hooks. Die können alle gelöscht werden um es schön übersichtlich zu halten. Statt der Beispiel-Scripte wird das update Script hier hinein kopiert und damit ist das Setup abgeschlossen.

Jetzt können wir fleißig an unseren Code im Entwickelungs-Ordner local arbeiten. Als gute Entwickler committen wir oft und aussagekräftig. Am Ende eines jeden Tages (oder auch öfters), pushen wir unsere Arbeit in den remote. Wenn man nun einmal in den remote schaut, wird man merken das sich nichts (sichtbares) dort tut. Weder kommt Code hinzu noch wird ein SVN-Commit durchgeführt (lässt sich ganz einfach mit svn log prüfen). Dies ist jedoch auch genau so gewollt. WordPress verbietet es uns jeden Commit in das WP-SVN zu committen.
Wie kommt nun unsere neue Version ins WP-SVN? Wenn es denn soweit ist das eine neue Version fertig ist, dann wird diese in Git getaggt: git tag 1.0 -a -m 'A new version of plugin-name was released with version number 1.0' oder mit einen schlichteren “un-annotated tag” git tag 1.0. Dieser Tag muss noch nach remote gepusht werden (git push dropbox 1.0), ab jetzt fängt die Magie des update hooks an zu wirken.
Das Shell-Script macht nun folgendes:

• Prüfe ob ein Git-Repo im Ordner trunk vorhanden ist. Wenn nicht, dann erzeuge eines
• Prüfe ob in diesen Git-Repo ein Remote-Repo namens svn-master vorhanden ist. Wenn nicht, dann füge es hinzu
• Hole dir die Daten aus dem Remote-Repo svn-master in den master branch (pull = fetch&merge)
• Füge den neuen Code/Dateien im SVN-Repo hinzu und führe ein SVN-Commit durch
• Erzeuge mit svn copy einen sauberen SVN-Tag im Remote-SVN-Repo

Das update Script muss dabei auf einen kleinen Trick zurück greifen. Tags sind nichts anderes als Revisionen die einen bestimmten Zustand des Codes widerspiegeln. Normalerweise könnte man beim pull auch auf den Tag zugreifen, dieser existiert im Remote-Repo allerdings zu diesen Zeitpunkt noch nicht. Deswegen muss der Code erst in einen Commit zum Remote-Repo gepusht werden, da der Code anschließend aus den letzten Commit gezogen wird!
Es gibt sicherlich Möglichkeiten auch Clientseitige Hooks, also Hooks die im lokalen Repo ausgeführt werden, zu nutzen. Dann müsste man jedoch bei jedem klonen des Remote-Repos diese Hooks neu einrichten. So läuft der Prozess mehr oder minder zentral ab und man muss alles nur einmal einrichten egal mit wie vielen Computern oder Teammitgliedern man das ganze nutzt.

Fazit

Das ganze ist noch etwas wackelig, vor allem was Merge-Konflikte angeht. Mir fehlen dazu bisher die praktischen Erfahrungen und weitere Tests. Da das Git-Repo im Verzeichnis trunk jedoch einzig und alleine dazu dient den Code in das trunk Verzeichnis zu kopieren, kann man hier sehr grob vorgehen und einfach den bestehenden Code gnadenlos überschreiben. Es finden sich dazu mehrere Methoden im Netz, ich bin mir nur noch nicht ganz sicher welche die beste ist. Wahrscheinlich ist es das Beste den Code aus dem Remote-Repo in einen neuen, temporären Branch zu kopieren, den SVN-Commit durchzuführen und den Branch anschließend wieder zu löschen. Wer es ganz hart mag, kann das Git-Repo auch einfach komplett löschen indem er den Ordner .git im Verzeichnis trunk löscht.
Auf ein svn update verzichte ich bewusst, da dies ebenfalls zu Merge-Konflikten führen kann. Meine Lösung ist also nichts für diejenigen, die mit mehreren an einen WP-SVN-repo arbeiten. Hier sind andere Strategien gefragt die um etwas Handarbeit, vor allem beim Lösen von Merge-Konflikten, nicht drum herum kommen.

Diejenigen die sich mit Shell- bzw. Bash-Scripten auskennen, werden schnell erkennen das dies mein allererstes Bash-Script ist. Der Code ist definitiv nicht optimal, erfüllt jedoch seinen Zweck. Auch lässt sich das eine oder andere in Sachen SVN vielleicht noch optimieren, denn auch SVN war bisher nicht mein Fachgebiet (wird es wohl auch nie werden).
Ein paar Kleinigkeiten sollten noch gelöst werden, so zum Beispiel das automatische Übernehmen der Commit-Nachricht bei annotated Tags. In meinen Augen aber eher Komfort-Funktionen die eine etwas geringere Priorität haben.
Das es ein Repo ist, kann sich ja ohnehin jeder den Code ziehen und die Verbesserungen/Optimierungen einbauen die er meint das sie dort hin gehören. Da es sich um “Social Coding” handelt, würde es mich freuen wenn auch der eine oder andere Pull Request bei mir ankommt.

Mein erster Gedanke war, nein geht nicht. Denn das Registrierungsformular bietet weder Hooks noch Filter an die man nutzen könnte um eigene Felder einzufügen. Nun ist das Einfügen einer Tabellenzeile und eines Input-Feldes mit jQuery keine Raketenwissenschaft, beides ist mit ein paar Zeilen Code schnell erledigt.

<?php
/**
 * Plugin Name:	Custom user registration fields
 * Plugin URI:	http://yoda.neun12.de
 * Description:	Add custom fields to the user registration
 * Version: 	0.1
 * Author: 		Ralf Albert
 * Author URI: 	http://yoda.neun12.de
 * Text Domain:
 * Domain Path:
 * Network:
 * License:		GPLv3
 */

add_action( 'plugins_loaded', 'wp_custom_user_registration_fields', 10, 0 );


function wp_custom_user_registration_fields(){

	add_action(
		'admin_print_scripts-user-new.php',
		function (){

			wp_enqueue_script(
				'add_custom_user_registration_field',
				plugins_url( 'wp_curf.js', __FILE__ ),
				array( 'jquery' ),
				false,
				true
			);

			wp_enqueue_script( 'wp_curf_l10n' );

			wp_localize_script(
				'wp_curf_l10n',
				'wp_curf_l10n',
				array(
					'label'		=> _( 'Biographical Info' ),
					'description'	=> _( 'Share a little biographical information to fill out your profile. This may be shown publicly.' )
				)
			);

		}
	);

}

/**
 * jQuery part of Costum User Registration Field
 *
 *  @author		Ralf Albert
 *  @version	0.1
 */

jQuery( document ).ready(

    function($){

        var insertElements =
            '<tr class="form-field">' +
            '   <th scope="row"><label for="description">' + wp_curf_l10n.label + '</label></th>' +
            '   <td><textarea name="description" id="description" rows="5" cols="30"></textarea><br /><span class="description">' + wp_curf_l10n.description + '</span></td>' +
            '</tr>';

        $( '#createuser .form-table tbody' ).append( insertElements );

    }

);

Das der Code so schlank und kompakt aussieht, liegt daran das ich die “Biographischen Angaben” aus dem Benutzer-Profil, also ein Standardfeld von WordPress, verwendet habe. WordPress verwendet sowohl für das Anlegen als auch für das Bearbeiten eines Benutzers nahezu die gleiche Routine. Somit muss ich mich nicht um die Speicherung des Feldinhaltes kümmern.
Will ich nun ein komplett eigenes Feld erstellen, nennen wir es mal “Abteilung”, muss ich mich wieder um die Speicherung des Feldinhaltes und auch die Anzeige im Benutzerprofil, kümmern. Wie man eigene Felder dem Benutzerprofil hinzufügt und diese anzeigt, dazu gibt es im Netz zahlreiche Tutorials, zum Beispiel bei WP Engineer.
Da aber bereits bei der Registrierung eines Benutzers Daten gespeichert werden sollen, muss noch ein zusätzlichen Hook bemüht werden: user_register. Als Callback kann hier wieder die gleiche Funktion benutzt werden die auch beim Bearbeiten eines Benutzers verwendet wird, so sparen wir uns ein paar Zeilen Code.

Alles zusammen findet sich in diesen Gist und kann als Ausgangspunkt für ein eigenes Plugin verwendet werden.

Im ersten Teil hatte ich einen Formatter vorgestellt mit dem ich auf vergleichsweise einfache und flexible Art aus Daten eine Ausgabe machen kann. Im zweiten Teil habe ich mittels der Formatter-Klasse und einer Templates-Klasse eine Mini-Template-Engine gebastelt. Die hat aber noch etliche Nachteile und diente lediglich der Darstellung des Prinzips das dahinter steckt.
Diesmal möchte ich auf eine konkrete Implementierung in WordPress eingehen die in dieser Form immer wieder verwendet werden kann.

Das Pferd von hinten aufgezäumt

Es ist vielleicht etwas ungewöhnlich, ich will jedoch von hinten anfangen und beginne mit den eigentlichen Templates. Das ist in sofern sinnvoll, als das wir konkrete Templates haben und uns dann einen Weg überlegen können wie wir an diese heran kommen. Hier also erst einmal die Template-Klassen:

<?php
/**
 * 
 * Abstract class Wp Simple Templates define one method to retrive the defined templates
 * @author Ralf Albert
 *
 */
abstract class WP_Simple_Templates
{

	/**
	 * 
	 * Returns the template if it was defined in the template class. If the requested template was not
	 * defined in the template-class, return a wp-error.
	 * @param string $type
	 * @return array|string|object Array with template-strings or a single template-string or wp-error on failure
	 */
	public function get_templates( $type = '' ){

		if( '' == $type )
			return NULL;

		// if the template-class have a method $type, return the template(s). else return a wp-error
		if( method_exists( $this, $type . '_template' ) ){

			$method = $type . '_template';
			return $this->$method();

		} else {

			return new WP_error(
				'template_error',
				printf(
					'<h4>Template Error</h4>Template <strong>%s</strong> does not exists in <strong>%s</strong>',
					$type,
					get_class( $this )
				)
			);

		}

	}

	/**
	 * 
	 * Return an array with all available templates from the template-class
	 */
	public function get_available_templates(){

		// get all methods from the abstract class (__CLASS__) and the extended class ($this)
		$self_methods		= get_class_methods( __CLASS__ );
		$extended_methods	= get_class_methods( $this );

		// remove the '_template' extension and return the array with template-names
		$templates = array();

		foreach( array_diff( $extended_methods, $self_methods ) as $template )
			array_push( $templates, str_replace( '_template', '', $template ) );

		return $templates;

	}

}

/**
 * 
 * Concrete class WP Simple HTML Templates defines the templates
 * @author Ralf Albert
 *
 */

class WP_Simple_HTML_Templates extends WP_Simple_Templates
{
	/**
	 * Returns an array with list templates
	 */
	public function list_template(){

		return array(
			'ol'	=> array(
						'outer'	=> "<ol>n%inner%</ol>n",
						'inner'	=> "<li>%item%</li>n"
			),

			'ul'	=> array(
						'outer'	=> "<ul>n%inner%</ul>n",
						'inner'	=> "<li>%item%</li>n"
			),

			'div'	=> array(
						'outer'	=> "<div>n%inner%</div>n",
						'inner'	=> "<p>%item%</p>n"
			),
		);

	}

	/**
	 * Returns a headline template with h1-tags
	 */
	public function hone_template(){

		return '<h1>%headline%</h1>';

	}

	/**
	 * Returns a paragraph-template with p-tags
	 */
	public function paragraph_template(){

		return '<p>%text%</p>';

	}

}

Am Anfang sehen wir eine abstrakte Klasse WP_Simple_Templates. Diese Klasse hat lediglich zwei Methoden (get_templates() und get_available_templates()) und da sie als abstrakt definiert wurde, kann man von ihr keine Instanz (kein Objekt) erzeugen. Die zweite Klasse enthält lediglich Methoden die nichts anderes machen als Strings und Arrays zurück zu geben.
Wir könnten uns jetzt die abstrakte Klasse sparen und direkt auf die Methoden der Template-Klasse zugreifen. Dazu muss man aber immer genau wissen welche Methoden in der Template-Klasse definiert wurden. Das ist irgendwie doof, besser wäre es doch wenn man die Klasse fragen kann und sie antwortet mit einer Liste der verfügbaren Templates. Genau diese Aufgabe übernimmt die Methode get_available_templates() in der abstrakten Klasse.
Um an die einzelnen Templates heran zu kommen gibt es die Methode get_templates(). Sie liefert immer ein Array mit den angeforderten Template(s) zurück. Es muss uns also gar nicht mehr interessieren wie die Templates in der Template-Klasse benannt wurden oder wie die Template-Klasse diese erzeugt, mit get_template( 'list' ) bekommen wir immer das Template für HTML-Listen geliefert.
Da wir später noch verschiedene Template-Klassen verwenden wollen, habe ich die Logik der Template-Klasse (get_template() und get_available_templates()) in eine abstrakte Klasse ohne Template-Strings ausgelagert und erweitere die Template-Klassen um diese abstrakte Klasse. Einfaches Code-Recyling halt.

Die Templates verarbeiten

Nun nützt es uns recht wenig wenn wir an die Templates heran kommen. Im Grunde genommen wollen wir das auch gar nicht. Das einzige was wir machen wollen ist, Daten angeben und eine Ausgabe zurück bekommen. Wir benötigen also noch eine Klasse die unsere Daten in die Templates einfügt:

<?php
/**
 * 
 * Abstract class WP Simple Templater creates a copy of the template-class and
 * provide the templates to the template-engine
 * @author Ralf Albert
 *
 */
abstract class WP_Simple_Templater extends Formatter
{
	/**
	 * 
	 * Instance of template-class
	 * @var object $templates_object
	 */
	protected $templates_object = NULL;

	/**
	 * 
	 * Constructor
	 * Creates an instance of the template-class and setup the delimiters for Formatter
	 * @param WP_Simple_Templates $templates
	 */
	public function __construct( WP_Simple_Templates $templates ){

		$this->templates_object = &$templates;

		$this->set_delimiter( '%', '%' );

	}

	/**
	 * 
	 * Return a template by given type. Returns an wp-error on failure
	 * @param string $type
	 * @return string|bool Return a template-string if it was defined by the template-class. Or false if no such template was defined
	 */
	protected function get_templates( $templatetype = '', $type = '' ){

		// error message
		$err_msg = '';

		// if the sub-type is empty (e.g the template is a string not an array), use the template-type as sub-type
		if( '' == $type )
			$type = $templatetype;

		// first check if a template-type was set
		if( '' == $templatetype )
			$err_msg = 'Empty template-type';

		// check if a template-class was loaded
		elseif( NULL === $this->templates_object )
			$err_msg = 'No templates defined in <strong>' . get_class( $this ) . '</strong>';					

		// we have a template-type and a template-class. get the template(s)
		else {

			 $template = $this->templates_object->get_templates( $templatetype );

			 // get error-message thrown by template-class
			 if( is_wp_error( $template ) )
			 	$err_msg = $template->get_error_message();

			 // check the template.
			 // convert a string into an array. else check if the requested type is in the template-array
			 else {

				 if( ! is_array( $template ) )
				 	$template[$type] = $template;

				 elseif( ! in_array( $type, array_keys( $template ) ) )
				 	$err_msg = $type . ' is not defined.';

			 }

		}

		// if a error occurs, return an error-object
		if( '' != $err_msg ){

			return new WP_Error(
					'template_error',
					sprintf(
						'<div class="error"><h4>Template Error</h4>%s</div>',
						$err_msg
					)
				);

		}

		// finally all checks are ok, return the template-array
		return $template;

	}

}

/**
 * 
 * The concrete class WP Simple HTML insert the data in the templates
 * @author Ralf Albert
 *
 */
class WP_Simple_HTML extends WP_Simple_Templater
{

	/**
	 * 
	 * Constructor overrides the delimiters in parent class
	 * @param WP_Simple_Templates $templates
	 */
	public function __construct( WP_Simple_Templates $templates ){

		parent::__construct( $templates );

		$this->set_delimiter( '{', '}' );

	}

	/**
	 * 
	 * Create a html list (ul, ol or with div-tag)
	 * @param string $type The type of the list. ul, ol or div
	 * @param array $data Data to display inside the list
	 */
	public function get_list( $type = '', $data = array() ){

		// get list templates
		$templates = $this->get_templates( 'list', $type );

		if( is_wp_error( $templates ) )
			return $templates->get_error_message();

		// create list
		$inner	= new stdClass();
		$values	= new stdClass();

		foreach( $data as $key => $value ){

			$values->key	= $key;
			$values->item	= $value;

			$inner->inner	.= self::sprintf( $templates[$type]['inner'], $values );

		}

		return self::sprintf( $templates[$type]['outer'], $inner );

	}

	/**
	 * 
	 * Prints a html-list (ul, ol or with div-tag)
	 * @param string $type The type of the list. ul, ol or div
	 * @param array $data Data to display inside the list
	 */
	public function print_list( $type = '', $data = array() ){

		if( ! is_array( $data ) )
			$data = (array) $data;

		echo $this->get_list( $type, $data );

	}

	/**
	 * 
	 * Create a H1-headline
	 * @param string $text
	 */
	public function get_headline( $text = '' ){

		// get headline template
		$template = $this->get_templates( 'hone' );

		if( is_wp_error( $template ) )
			return $template->get_error_message();

		$data = new stdClass();
		$data->headline = $text;

		return self::sprintf( $template, $data );

	}

	/**
	 * 
	 * Print a H1-headline
	 * @param string $text
	 */
	public function print_headline( $text = '' ){

		echo $this->get_headline( $text );

	}

}

Damit haben wir jetzt die Logik von der Ausgabe getrennt. Sowohl in unserer Template-Klasse (WP_Simple_Templates und WP_Simple_HTML_Templates), als auch in der Template-Engine (WP_Simple_Templater und WP_Simple_HTML). Wiederkehrende Logik haben wir in abstrakte Klassen ausgelagert die wir problemlos recyclen können.
Die einzige Arbeit die uns zukünftig bleibt, ist eine Template-Klasse zu schreiben die die entsprechenden Templates enthält und für jedes Template die nötige Logik schreiben die die Daten aufbereitet und anschließend Daten und Template verbindet. Da wir die Logik für die Datenaufbereitung von den Templates getrennt haben, können wir munter die Templates umstellen ohne in unseren eigentlichen Plugin- oder Theme-Code eingreifen zu müssen.
Die Logik für die Datenaufbereitung müssen wir auch nur dann anfassen, wenn wir die Templates um weitere Variablen ergänzen oder ändern. Logik und Ausgabe sind in allen Bereichen komplett voneinander getrennt.

Lose koppeln anstatt fest verdrahten

Wie würde man nun diese Template-Engine in seinem Plugin oder Theme verwenden? Wahrscheinlich würde man sie an entsprechender Stelle so im Code einfügen:

$template = new WP_Simple_HTML_Templates();
$html = new WP_Simple_HTML( $template );
//some other code

$html->print_headline( 'Success!' );

$list = $html->get_list( 'ol', array( 'one' => 'eins', 'two' => 'zwei', 'three' => 'drei' ) );

// more code
echo $list;

Das sieht im Grunde genommen schon mal schön aus. Relativ schön, um genau zu sein. Denn sowohl die Template-Klasse ($template) als auch die Template-Engine ($html) sind mehr oder minder fest verdrahtet. Würden wir für unsere Template-Engine eine andere Template-Klasse verwenden wollen, müssten wir dies im Code ändern. Gleiches gilt für den Fall das wir unsere Template-Klasse behalten aber auf eine andere Template-Engine zurückgreifen wollen.

Besser wäre es, wenn wir später noch andere Template-Engines und Template-Klassen angeben könnten. WordPress bietet uns hierzu die Möglichkeit mit apply_filters() und add_filter(). Schauen wir uns dazu folgende Demo an:

<?php
class Template_Engine_Test
{
	/**
	 * 
	 * Container for the different template-engines
	 * @var object $template_engine
	 */
	public static $template_engine;

	/**
	 * 
	 * Initial some vars
	 */
	public function __construct(){

		// initialize the template-engine to avoid strict errors
		self::$template_engine = new stdClass();

	}

	/**
	 * 
	 * Caching for the template-classes
	 * Create a WP-Error if the template-engine could not be initialize
	 * @param string $template_engine The requested template-engine
	 * @return object The requested template-engine if available
	 */
	protected function get_template_engine( $template_engine ){

		$template_engine = strtolower( $template_engine );

		// available template-engines and the template-classes
		$available_template_engines = array(

			'html'	=> array( 'WP_Simple_HTML', 'WP_Simple_HTML_Templates' )

		);

		$available_template_engines = apply_filters( 'available_template_engines', $available_template_engines );

		// check if the requested template-engine is available. if not, try to create it
		if( ! isset( self::$template_engine->$template_engine ) ){

			if( ! isset( $available_template_engines[$template_engine] ) ){

				return new WP_Error( 'template_engine', 'Unknown template-engine <strong>' . $template_engine . '</strong>' );

			} else {

				$tmpl_ng	= &$available_template_engines[$template_engine];
				$class		= &$tmpl_ng[0];
				$template	= &$tmpl_ng[1];

				self::$template_engine->$template_engine = new $class( new $template );

			}

		}

		return self::$template_engine->$template_engine;

	} 

	/**
	 * 
	 * The output
	 */
	public function output( $stream ){

		$output = $this->get_template_engine( $stream );

		if( is_wp_error( $output ) )
			die( $output->get_error_message() );

		$output->print_headline( strtoupper( $stream ) );

		$list = $output->get_list( 'ol', array( 'eins', 'zwei', 'drei' ) );
		echo $list;

	}

	/**
	 * 
	 * Setup html-mode
	 */
	public function set_html(){

		// html is build in

	}

	/**
	 * 
	 * Setup xml-mode
	 */
	public function set_xml(){

		add_filter( 'available_template_engines', array( &$this, 'add_xml' ), 1, 0 );

	}

	/**
	 * 
	 * Add the XML-Template-Engine
	 */
	public function add_xml(){

		return array(

			'xml'	=> array( 'WP_Simple_HTML', 'WP_Simple_HTML_Templates' ),

		);

	}

	public function set_feed(){

		add_filter( 'available_template_engines', array( &$this, 'add_feed' ), 1,1 );

	}

	public function add_feed( $template_engines ){

		$feed_engines = array(

			'rss'	=> array( 'WP_Simple_HTML', 'WP_Simple_HTML_Templates' ),
			'atom'	=> array( 'WP_Simple_HTML', 'WP_Simple_HTML_Templates' ),

		);

		return array_merge( $template_engines, $feed_engines );

	}

}

$html = new Template_Engine_Test();
$html->set_html();
$html->output( 'html' );

$xml = new Template_Engine_Test();
$xml->set_xml();
$xml->output( 'xml' );

$feed = new Template_Engine_Test();
$feed->set_feed();
$feed->output( 'rss' );
$feed->output( 'atom' );

$bar = new Template_Engine_Test();
$bar->output( 'wallawalla' );

Die Methode get_template_engine() erfüllt zwei Aufgaben. Zum einen gibt sie die angeforderte Template-Engine inkl. der dazugehörigen Template-Klasse zurück (sofern beides vorhanden). Und zum anderen speichert sie die Template-Engine und Template-Klasse in einer statischen Variablen. Welche Kombination aus Template-Engine und Template-Klasse zurück gegeben wird, wird anhand eines Tags entschieden. So ist dem Tag ‘html’ schon einmal die Kombination WP_Simple_HTML/WP_Simple_HTML_Templates zugeordnet.
Weitere Kombinationen aus Template-Engine und Template-Klasse lassen sich über einen Filter hinzufügen. Bevor geprüft wird ob es den angeforderten Tag mit der entsprechenden Kombination gibt, wird ein Filter ausgeführt der es uns erlaubt weitere Kombinationen hinzuzufügen.
Dies nutzen die Methoden set_xml() und set_feed() aus. Sie fügen einfach dem Array der verfügbaren Template-Engines/Klassen ihre eigenen hinzu und machen diese dadurch zugänglich. Danach kann in der Methode output() auf die neu hinzugefügten Template-Engines und Klassen zugegriffen werden. Hiermit sind wir quasi am Ziel unserer Wünsche angelangt. Denn die Methode output() muss sich gar nicht mehr darum kümmern wie die Daten ausgegeben werden, sie stellt diese einfach bereit und erwartet das die entsprechende Template-Engine entsprechende Methoden zur Ausgabe zur Verfügung stellt.

Ein paar Grundlagen

Viele kennen es, wenn WordPress versucht Dateiaktionen auf den Server durchzuführen, z.B. ein Plugin oder Theme zu installieren, wird man nach seinen FTP-Zugangsdaten gefragt. Dabei ist es egal ob man eine Archivdatei direkt hochlädt oder von einen entfernten Server ein Update einspielt. Der Grund dafür liegt nicht bei WordPress, sondern bei Unix bzw. einem Unix-ähnlichen Betriebssystem wie Linux. Die Unix-ähnlichen Betriebssysteme kennen nämlich verschiedene Dateiberechtigungen und vor allem Dateibesitzer. Wenn unter einem Unix-System der (FTP-) Benutzer A eine Datei anlegt, so kann auch nur der Benutzer A diese Datei beschreiben bzw. löschen. Benutzer A ist der Dateibesitzer und hat die volle Kontrolle über die von ihm angelegte Datei. Möchte der Benutzer A das die Datei auch von anderen FTP-Benutzern gelesen bzw. beschrieben werden kann, so müssen entsprechende Berechtigungen vergeben werden. Es gibt drei Gruppen denen man den Zugriff auf die Datei erlauben kann: Nur der Eigentümer (also derjenige der die Datei angelegt hat), eine Gruppe von FTP-Benutzern und Alle anderen (others oder public). Zudem kann auch noch die Art des Zugriffs geregelt werden. Möglich sind: Lesen, Schreiben und Ausführen.
Benutzer A könnte z.B. festlegen das die von ihm angelegte Datei nur von ihm beschrieben werden kann, jedoch z.B. alle FTP-Benutzer aus der Gruppe Tastatursklaven die Datei zumindest lesen können. Alle anderen FTP-Benutzer, so z.B. anonyme Gäste, können die Datei weder lesen noch sie beschreiben.

Dies ist ein grundlegender Schutz vor unberechtigten Zugriffen. Es wäre ja schon ein wenig fatal wenn jeder der will z.B. die Datei wp-config.php lesen, geschweige denn sie nach Lust&Laune verändern könnte. Dieser “Schutz” wirkt sich nun nicht nur auf Dateien aus, sondern auch auf Verzeichnisse. Dateien die in einem Verzeichnis liegen das nur vom Eigentümer gelesen werden kann, können nicht von anderen FTP-Benutzern gelesen werden, egal welche Dateiberechtigung die einzelnen Dateien haben.
Jetzt stellt sich natürlich die Frage was das alles mit WordPress zu tun hat. Schauen wir uns dazu erst einmal die “Ausnahme” an. Das wäre der Fall, wenn WordPress auf einem Server installiert ist auf dem PHP als so genanntes php-cgi läuft. Php-cgi ist eine ausführbare Datei und wird immer unter dem Konto des FTP-Benutzers ausgeführt. Wenn php-cgi also eine Datei auf den Server schreibt, hat die Datei als Eigentümer automatisch den FTP-Benutzer als Dateieigentümer.
Der andere Fall, der weitaus verbreiteter ist, ist der, dass PHP als Apache-Modul (php_mod) ausgeführt wird. In diesen Fall ist nicht der FTP-Benutzer der Dateieigentümer, sondern der Apache-Server, der so gesehen auch ein FTP-Benutzer ist, jedoch mit einen anderen Benutzernamen. Je nachdem wie der Server konfiguriert ist, variiert der FTP-Benutzername des Servers. Häufig ist dies “nobody”, aber auch “wwwrun”, “PHP-User” oder schlicht “PHP”. Welcher Benutzername der Apache-Server genau hat, muss also im Einzelfall jeder selber heraus finden, ist aber für das Verständnis gar nicht so wichtig.

Halten wir kurz fest:

• Unter Unix und Unix-ähnlichen Betriebssystemen haben Dateien und Verzeichnisse einen Besitzer
• Nicht jeder FTP-Benutzer kann auf alle Dateien und Verzeichnisse zugreifen
• Die Zugriffe auf Dateien und Verzeichnisse werden durch Zugriffsrechte geregelt
• Läuft PHP als Apache-Modul, so hat der Server einen eigenen “Benutzernamen” und hat dementsprechend auch Besitzrechte an den von ihm angelegten Dateien und Verzeichnisse.

Was passiert beim Upload?

Wenn wir nun versuchen Dateien oder Verzeichnisse in unser Blog hochzuladen, dann muss WordPress erst einmal feststellen wie es dies bewerkstelligen kann. Die einfachste Methode wäre natürlich WordPress würde die Daten einfach mal so auf dem Server ablegen. Genau genommen versucht WordPress dies auch, lässt es aber meistens aus Sicherheitsgründen sein. Um festzustellen ob WordPress die Daten direkt auf den Server speichern kann, schreibt es eine kleine Testdatei. Danach prüft WordPress ob der FTP-Benutzer mit dem Dateibesitzer der Testdatei übereinstimmt.
Im Fall von php-cgi stimmen die Besitzrechte überein und WordPress kann ohne weitere Nachfrage weiter machen.
Im Fall von PHP als Modul hat die Testdatei jedoch den Server als Besitzer und nicht den FTP-Benutzer. WordPress entscheidet sich in diesen Fall dagegen die Daten direkt auf den Server zu schreiben und sucht nach einer anderen Methode.

Natürlich stellt sich jetzt die Frage warum WordPress nicht doch einfach die Daten auf den Server ablegt. Der Grund liegt in den Zugriffsrechten und und einer Sicherheitslücke die sich (theoretisch) daraus ergibt.
Stellen wir uns mal vor Benutzer A und Benutzer B haben auf dem Webserver C jeweils einen Webspace gemietet. Alle Dateien und Verzeichnisse die von Benutzer A angelegt werden, können auch nur von Benutzer A gelesen und beschrieben werden. Genauso verhält es sich mit den Dateien und Verzeichnissen von Benutzer B. Was ist aber mit den Dateien und Verzeichnissen von “Benutzer C“? Benutzer C wäre in diesem Fall der Webserver. Und wenn der Webserver im Webspace von Benutzer A eine Datei anlegt, dann ist der Webserver der Besitzer dieser Datei. Da sich Benutzer A und B einen Webserver teilen, hat Benutzer B theoretisch über den Webserver Zugriff auf die Dateien im Webspace von Benutzer A, die vom Webserver angelegt wurden. Theoretisch könnte Benutzer B also den Webserver anweisen Dateien die er im Webspace von Benutzer A angelegt hat, auszulesen und im Webspace von Benutzer B zu kopieren. Möglich wäre dies, da der Webserver als Dateibesitzer ja die nötigen Rechte dazu hat.
Dies ist eine eher theoretische Sicherheitslücke. Theoretisch deshalb, da auf einen vernünftig konfigurierten Server so etwas nicht möglich sein sollte. Der Server sollte so konfiguriert sein, dass kein Benutzer auf Dateien oder Verzeichnisse außerhalb seines Webspaces zugreifen kann. Andernfalls könnte jeder Benutzer auch problemlos die Konfigurationsdateien des Webservers manipulieren.
Doch grau ist alle Theorie, die Praxis hat schon andere Fälle hervor gebracht. Und genau deswegen geht WordPress auf Nummer sicher und zieht es vor die Daten nicht direkt auf den Server abzulegen sofern es unter PHP als Apache-Modul läuft.

Kurz zusammen gefasst: Stellt WordPress fest das es nicht mit den gleichen Benutzernamen wie der FTP-Benutzer läuft, weigert es sich schlichtweg die Daten direkt auf den Server zu schreiben um nicht eine Sicherheitslücke bei den Zugriffsberechtigungen zu öffnen.

Und es nervt doch

Da PHP als Apache-Modul sehr verbreitet ist, werden auch viele WordPress-Nutzer regelmäßig nach ihren FTP-Zugangsdaten gefragt. FTP ist die zweite Variante mit der WordPress die Daten auf den Server bekommt. Dazu tut WordPress einfach so, als sei es der FTP-Benutzer unter dem der Blog angelegt wurde und der rechtmäßig Zugriff auf alle Dateien hat. Somit werden die Daten nicht mit dem FTP-Benutzer “nobody” (oder PHP-Run, oder PHP, oder oder oder) geschrieben, sondern mit dem von uns angegebenen Benutzernamen und Passwort.

Wer nur selten Daten auf seinen Server kopiert, den wird es nicht stören ab und an mal seine FTP-Daten anzugeben. Es gibt aber so einige Fälle wo es doch sehr nervig werden kann. Als Entwickler schiebt man ständig zu Testzwecken Daten auf den Server und löscht sie dort wieder. Das man auch beim Löschen von Daten die FTP-Zugangsdaten angeben muss, dürfte mittlerweile klar sein. Denn WordPress kann aufgrund der fehlenden Zugriffsberechtigungen nicht als Benutzer “PHP-Run” auf die Daten von FTP-Benutzer “Horst4711″ zugreifen.
Manchmal ist es aber auch einfach zu unbequem die FTP-Zugangsdaten, die sich natürlich kaum einer merkt weil das Passwort kryptisch³ ist, raus zu suchen. Und manchmal hat ausgerechnet der Mitarbeiter die FTP-Zugangsdaten, der gerade in Kambodscha Urlaub macht und nicht erreichbar ist.

Für solche Fälle gibt es einige Möglichkeiten die FTP-Zugangsdaten direkt in WordPress zu hinterlegen. Alle Möglichkeiten haben ihre Vor- und Nachteile. Einige sind sogar, m.E. nach, ein wenig gefährlich.

Speichern ist einfacher als raus suchen

Ab Werk kann man WordPress seine FTP-Daten also nur per Formular übergeben. Wer häufig unterwegs ist und sich dementsprechend genauso häufig in ungesicherte WLAN-Netzwerke einloggt (oder einloggen muss), wird immer ein mulmiges Gefühl haben wenn er die FTP-Zugangsdaten ungesichert quer durch die Bahnhofshalle zum Router schicken muss. Gerade wenn es um Kunden-Server geht ist hier etwas Vorsicht geboten. Falls jetzt jemand die Idee hat SSL wäre ja eine Lösung, der hat im Prinzip Recht. Jedoch denken die meisten Kunden da ganz anders. Wenn SSL extra kostet, dann braucht man das nicht. So denken zumindest die meisten Kunden.
Diese Lösung hat allerdings auch einen Vorteil. Legt man auf dem Server für jeden Admin einen FTP-Konto an, so kann Admin B nicht aus versehen (oder mit voller Absicht) die Dateien und Verzeichnisse von Admin A löschen oder überschreiben.

wp-config

Die erste Alternative zur Übertragung via Formular wäre die FTP-Zugangsdaten in der wp-config.php abzulegen. Dazu stellt WordPress drei Konstanten bereit: FTP_HOST, FTP_USER und FTP_PASS. Die Namen sprechen für sich und es dürfte klar sein für was die einzelnen Konstanten stehen. Wer mehr über die Konstanten von WordPress erfahren will, sollte mal einen Blick bei Dominik Schilling (G+ Profil)  rein werfen. Er hat eine umfangreiche Auflistung alle Konstanten.
Beispiel:

// defining the ftp-account data
if( ! defined( 'FTP_HOST' ) )
  define( 'FTP_HOST', 'meine-dmoain.de' );

if( ! defined( 'FTP_USER' ) )
  define ( 'FTP_USER', 'Horst4711' );

if( ! defined( 'FTP_PASS' ) )
  define( FTP_PASS', '&SchmierMaxe$0815!' );

Man sieht schon wo hier das Problem liegen könnte. Das Passwort liegt unverschlüsselt in einer PHP-Datei von der so ziemlich jeder Hacker weiß das dort was zu holen ist. Auf der anderen Seite steht in der selben Datei aber auch das Passwort für die Datenbank, ebenfalls unverschlüsselt. Man kann jetzt so oder so argumentieren. Die einen sind der Meinung das eh Hopfen&Malz verloren ist wenn die wp-config.php geknackt ist. Die anderen sagen das man einen Hacker nicht noch freien FTP-Zugang zum Server geben muss wenn er sich schon die Datenbank unter den Nagel gerissen hat.
Diese Methode spart auf alle Fälle die lästige Tipparbeit und man muss, sofern man mit mehren Mitarbeitern an einen Blog arbeitet, die FTP-Zugangsdaten nicht jedem aufs Auge drücken. Irgendwo gibt es immer einen der Zugangsdaten auf einen PostIt schreibt und diesen dann irgendwo vergisst oder verliert.
Hier wird deutlich das WordPress eigentlich ein Single-User-System ist dem man notdürftig eine Benutzerverwaltung aufgepflanzt hat. Denn so kann jeder Benutzer mit Admin-Rechten auf alle Dateien und Verzeichnisse zugreifen. Ob nun gewollt oder ungewollt. Es ist durchaus denkbar das Admin B ein Verzeichnis löscht oder überschreibt das von Admin A angelegt wurde und das auf gar keinen Fall gelöscht oder überschrieben werden durfte.

FS_METHOD

Eine andere Alternative zum Formular besteht darin, WordPress dazu zu zwingen die Daten direkt auf den Server zu schreiben. Indem man die Konstante FS_METHOD auf direct setzt, lässt man WordPress erst gar nicht dazu kommen auszuwählen ob es die Daten direkt oder per FTP auf den Server schreibt.
In meinen Augen ein Fauxpas sofern man dies auf einen Shared-Host anwendet. Für die möglichen Gefahren, siehe oben.
Nun ist aber nicht jedes Blog auf einen Shared-Host angelegt. Wer stolzer Besitzer eines eigenen Servers ist, kann diese Methode durchaus dazu nutzen den FTP-Upload zu umgehen. Wenn es auf dem ganzen Server nur einen FTP-Benutzer gibt, gibt es auch keinen zweiten der unberechtigt auf die Dateien zugreifen kann. Wobei man diese Aussage ein wenig relativieren muss. Denn als Apache-Modul ausgeführt, ist der Webserver natürlich auch ein FTP-Benutzer. Durch setzen der Konstante FS_METHOD auf direct, werden alle Dateien und Verzeichnisse mit dem Besitzer “Webserver” (oder so ähnlich) erstellt. Das kann in sofern problematisch werden, wenn in einem Plugin oder Theme “versehentlich” etwas wie exec( "rm -rf /" ); drin steht. Dann werden halt mal alle Dateien und Verzeichnisse die vom aktuellen Benutzer, sprich Webserver, angelegt wurden, gelöscht. Ohne Rückfrage versteht sich. Aber auch ein unlink() kann an der falschen Stelle mit dem falschen Pfad ausreichend Schaden anrichten.
Ein weiteres Problem dürfte zwar nur selten auftreten, ist mir persönlich aber durchaus schon mal passiert. Daten die vom Webserver geschrieben worden sind konnte ich als FTP-Benutzer nicht mehr löschen. Sicherlich auch eine Sache der Server-Konfiguration, man sollte aber vor Einsatz dieser Alternative erst einmal ausprobieren ob man denn die Daten die der Webserver geschrieben hat auch wieder löschen kann. Das Selektive Löschen einzelner Dateien oder Verzeichnisse kann sich dann sehr mühsam gestalten.

Die Konstante FS_METHOD kann jedoch auch sehr nützlich sein. Wir erinnern uns an php-cgi bei dem alle Daten unter dem Benutzernamen geschrieben werden. WordPress muss unter php-cgi nicht nachfragen ob es die Methode “direct” oder “ftp” benutzen soll, dadurch kann es gleich loslegen. Das ist vielleicht aber gar nicht immer erwünscht. Mit FS_METHOD können wir WordPress auch dazu zwingen FTP als Methode zu verwenden und jedes mal Benutzernamen und Passwort (und Hostname) abzufragen. Für Blogs die unter php-cgi laufen also ein kleiner Workaround wie man ganz einfach eine Authentifizierung vor dem Schreiben/Löschen von Daten erzwingen kann.

/*
 * force users to use ftp
 *
 * use 'ftpext' for using Apache FTP Extension
 * use 'ftpsockets' for ftp-sockets (Socket-Class or PHP-Extension)
 *
 */

if( ! defined( 'FS_METHOD' ) )
  define( 'FS_METHOD', 'ftpext' );

Obwohl ich hier nur mehr oder minder die Oberfläche angekratzt habe, sieht man schon wie komplex die gesamte Thematik ist. Gänzlich ausgeklammert habe ich z.B. die ganze Thematik um SSH/SSL, SFTP und das WordPress-Filesystem sowieso. Das ist genug Stoff für weitere drei oder vier Artikel.

Eine Plugin-Lösung

Meiner Philosophie zur Folge muss ein Blogartikel nicht komplett und vollständig sein, sondern vielmehr zum Nachdenken, Experimentieren und vor allem Diskutieren anregen. Sicherlich gibt es den einen oder anderen Aspekt den ich übersehen, falsch oder missverständlich dargestellt habe oder der mehr Interesse geweckt hat als der Artikel bedienen kann.
Genauso halte ich es auch mit meinen Plugins. Keine fertige Allroundlösung mit allen erdenklichen Features, sondern ein Lösungsansatz für ein Problem. Das folgende Plugin liegt in der Version 0.1 vor, ist also der erste Entwurf und eher ein PoC (Proof of Concept). Sowohl Artikel als auch Plugin sind beide an einen Tag entstanden, dementsprechend unausgiebig wurde das Plugin von mir getestet. Ich bitte dies beim Ausprobieren zu berücksichtigen.

FTP-Account to UserMeta

Dieses Plugin macht in etwa genau das was der (uninspiriert gewählte) Name aussagt. Es speichert die FTP-Zugangsdaten in den Benutzer-Daten des jeweiligen Benutzers. Damit sind zwei Anforderungen die im Laufe des Artikels aufgetaucht sind erledigt. Zum einen, und wichtigsten, muss man die FTP-Zugangsdaten nicht mehr ständig eintippen. Einmal im Benutzerprofil eingegeben stehen sie ab dann immer zur Verfügung wenn WordPress diese anfordert. Zum anderen können mehrere FTP-Benutzer ihre Daten hinterlegen da für jeden Benutzer separate FTP-Zugangsdaten gespeichert werden. Dadurch kann z.B. verhindert werden das Benutzer A die Dateien von Benutzer B versehentlich löscht, das Plugin kommt also aus der Ecke “Betreutes Bloggen”.

Das Plugin hinkt noch an der einen oder anderen Stelle. So werden die FTP-Passwörter (noch) im Klartext in der Datenbank gespeichert. Es sollte aber kein Problem darstellen eine entsprechende Ver- und Entschlüsselung nachzurüsten.
Auch fehlt noch die Unterstützung für SFTP/SSL da mir hierfür derzeit die nötige Umgebung fehlt (ja, ich habe weder SSL noch sonst was auf meinen lokalen Server. Nicht mal mod_ftp). Gegen Bereitstellung von etwas Platz auf einen entsprechenden Server mit SSL/SFTP bin ich gerne bereit das zu ändern Ansonsten muss man halt warten bis ich das auf meinem lokalen Server nachgerüstet habe.

Die Bedienung des Plugins ist recht simple. Nach der Installation und Aktivierung werden im Benutzerprofil drei Felder für FTP-Hostname, FTP-Benutzername und FTP-Passwort hinzugefügt. Sind die drei Felder ausgefüllt und wird das Profil aktualisiert, verschwindet ab diesen Zeitpunkt für diesen Benutzer die Aufforderung seine FTP-Zugangsdaten einzugeben sofern diese erforderlich sind. Alle anderen Benutzer die FTP benutzen können aber keine Zugangsdaten hinterlegt haben, werden weiterhin aufgefordert ihre Zugangsdaten bei Bedarf einzugeben.
Die Kontrolle darüber welche Benutzer überhaupt die drei Felder zu sehen bekommen, erfolgt hardcodiert im Plugin selber. Voreingestellt sind Administratoren (Role administrator), was wahrscheinlich am meisten Sinn macht. Es können aber auch andere Rollen bzw. Fähigkeiten (Capabilities) angegeben werden, womit eine recht feine Einstellung möglich ist wer seine FTP-Zugangsdaten eingeben kann.
Damit nach der Deinstallation des Plugins keine sensiblen Daten in der Datenbank verbleiben, werden diese bei der Deinstallation (nicht deaktivierung!) gelöscht. Sofern man das Plugin also über das Backend entfernt, kann man es gefahrlos ausprobieren.

Das Plugin findet ihr auf Github. Für diejenigen die es nicht so mit Git haben, als Zip-Datei. Die anderen dürfen gerne forken, pullen und commiten.

Update

Da das Plugin auf  einiges Interesse gestoßen ist, habe ich den Code mal etwas bereinigt und glatt gezogen. Neue Funktionen sind in dieser Version (v0.1.2) nicht hinzugekommen, dafür aber die eine oder andere Funktion für die nächsten Versionen notiert. Es wird sicherlich noch das eine oder andere umgesetzt werden, da ich hierdurch auch die Möglichkeit bekomme verschiedene Sachen auszuprobieren und ggf. darüber etwas zu schreiben.

WordPress lässt sich relativ einfach dazu bringen Login-Daten automatisiert anzunehmen. In erster Linie ist die Funktion wp_signon() dafür zuständig den Login durchzuführen. Dazu übergibt man ihr Benutzername und Passwort, die Funktion gibt daraufhin true zurück bzw. ein WordPress-Fehler-Objekt. Dies kann man bequem mit is_wp_error() abfragen und so mit nur wenigen Zeilen einen Login durchführen.

<?php
require( dirname(__FILE__) . '/wp-load.php' );
is_wp_error(
	wp_signon(
		  array(
			'user_login'=>'YourLoginName',
			'user_password'=>'YoUrAw3s0M3P455W0rD'
			) 
		 )
) ? die('Mooo... :(') : wp_safe_redirect( admin_url() );

Speichert man den Code in einer separaten Datei ab, so muss zuerst wp-load.php eingebunden werden um die WordPress-Funktionen verfügbar zu machen. Hier bitte auf den Pfad achten, iom Gist liegt die Datei im gleichen Verzeichnis wie wp-load.php.  Danach wird direkt wp_signon() mit einem Array aus Benutzername und Passwort gefüttert, welches wiederum direkt als Parameter an is_wp_error() übergeben wird.
Durch Aufruf der Datei ist man direkt eingeloggt und wird ins Backend umgeleitet. Möchte man lieber ins Frontend umgeleitet werden, so ersetzt man einfach admin_url() durch site_url().

Ich habe mir für meine Entwicklungsarbeit ein kleines Plugin geschrieben mit dem ich recht schnell zwischen verschiedenen Benutzern hin- und her wechseln kann. Dazu listet mir das Plugin auf der Login-Seite die Test-User auf, welche ich zuvor angelegt habe. Durch einen Klick auf einen entsprechenden User-Namen kann ich mich dann ohne Eingabe von Benutzername und Passwort anmelden. Auf Optik habe ich verzichtet, da es ein Werkzeug bei der Entwicklung ist. Wer mag, kann dem ganzen ja noch ein bisschen optischen Feinschliff verpassen.
Das Plugin WP-Quicklogin ist auf Github zu finden.