Ich hatte in meinem letzten Artikel bereits kurz angesprochen das es eine gute Idee ist Logik und Ausgabe voneinander zu trennen. Eins der besten Argumente für die Trennung von Logik und Ausgabe ist wohl das, dass man einmal geschriebenen Code erneut verwenden kann, man spart sich so viel Arbeit. Aber auch die Übersichtlichkeit steigt, was z.B. die Fehlersuche vereinfacht. Und nicht zu Letzt ist es leichter im Team zu arbeiten. So kann sich einer um die Logik kümmern während der andere sich ausschließlich um das Design (Ausgabe) kümmert.

Das hier im Artikel beschriebene dürfte für PHP-Profis nichts neues sein. Für den einen oder anderen meiner Leser (sofern vorhanden ) kann es aber durchaus interessant sein. Fangen wir also mal ganz locker an.

Ran an den Speck

Ziel soll es sein das in der einen Datei ein Template (Vorlage) steht, während in einer anderen Datei dieses Template mit Daten gefüllt wird. Will man die Trennung noch weiter voran treiben, so legt man weitere Dateien an die sich z.B. um die Beschaffung der Daten kümmern oder um die Ausgabe der Daten (HTML, RSS, Druck, usw.).
Wir wollen uns aber mal darauf beschränken ein einfaches  Template mit einem ebenso einfachem Array zu füllen. Bei dem Template soll es sich um eine Liste handeln. In WordPress zum Beispiel ist fast alles eine Liste. Ob nun die Artikel auf der Startseite, die Blogroll, eine Aufzählung der letzten Kommentare, Menüs, usw. Eigentlich besteht WordPress zu gefühlten 90% aus Listen. Listen dürften als Beispiel also ganz brauchbar sein.
Schauen wir uns mal kurz die Anatomie einer Liste in HTML an. Sie besteht im Prinzip aus zwei Teilen. Den äußeren Teil der die Liste definiert und den inneren Teil der die eigentliche Liste darstellt. In HTML gibt es drei native Listentypen: <ol> (Ordered List), <ul> (Unordered List) und <dl> (Defenition List). Da die <dl>-Liste etwas komplexer ist nehmen wir uns mal die <ol>- und <ul>-Listen vor. Als “Ersatz” für die <dl>-Liste möchte ich eine einfache <div>-Liste dazu nehmen. Die <div>-Liste besteht aus einem äußeren Div-Container und <p>-Tags für die Listenelemente.

Nachdem nun klar ist um welche Listen es geht, brauchen wir noch ein paar Daten für die Liste. Die meisten Daten werden uns als Array oder Objekt zur Verfügung gestellt. Wir können ja mal annehmen wir hätten gerade eine Datenbankabfrage gemacht und wollten nun das Ergebnis als Liste darstellen. Der Einfachheit halber begnügen wir uns mit einem eindimensionalen Array das lediglich die Zahlwörter von Eins bis Drei enthält.

Aus Daten wird eine Liste

Das Problem ein Array als Liste darzustellen ist recht einfach zu lösen. Äußeren Teil ausgeben, das Array durchlaufen und den inneren Teil erstellen, inneren Teil in den Äußern Teil einbetten und fertig ist die Liste.

<?php
require_once 'class-formatter.php';

class Lister extends Formatter
{	
	public function get_list( $data = array() ){

		$inner	= new stdClass();
		$values	= new stdClass();

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

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

			$inner->inner .= self::sprintf( '<li>%item%', $values );
		}

		return self::sprintf( '<ol>%inner%</ol>', $inner );

	}

}

$data = array( 'Eins', 'Zwei', 'Drei' );

$list = new Lister();
echo $list->get_list( $data );

Wenn wir jetzt aber anstatt der Ordered List eine Unordered List erstellen wollen, schreiben wir uns eine neue Klasse!? Das wäre ja nicht Sinn der Aktion, wir wollen ja eine flexible Lösung haben.
Es fehlt die Möglichkeit einen Listen-Typ auszuwählen. Was dafür geändert werden muss, sind die Template-Strings mit dem HTML-Code. Die einfachste Methode um die Templates für verschiedene Listen-Typen zu speichern ist ein Array. Wir benötigen also ein Array das zu jeden Listen-Typ (ol, ul und div) zwei Template-Strings speichert (den inneren Teil und den äußeren Teil).

<?php
require_once 'class-formatter.php';

class Lister extends Formatter
{	
	public $templates = array();

	public function __construct(){

		$this->templates = $this->get_templates();

	}

	public function get_templates(){

		$this->templates = 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"
			),
		);

	}

	public function get_list( $type = '', $data = array() ){

		// get templates if not already set
		if( empty( $this->templates ) )
			$this->get_templates();

		// check if the requested list-typ is defined
		if( ! in_array( $type, array_keys( $this->templates ) ) )
			return FALSE;

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

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

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

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

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

	}

}

$data = array( 'Eins', 'Zwei', 'Drei' );

$list = new Lister();
echo $list->get_list( 'ol', $data );
echo $list->get_list( 'ul', $data );
echo $list->get_list( 'div', $data );

Wunderbar. Jetzt können wir ganz einfach durch Angabe eines Listen-Types und eines Arrays eine Liste erzeugen. Das spart uns schon mal viel Arbeit, denn anstatt für jede Liste eine eigene Foreach-Schleife zu schreiben, benutzen wir einfach die Instanz unserer Klasse.
Und wenn wir jetzt der Liste noch eine CSS-Klasse mitgeben wollen, dann schreiben wir uns eine andere Klasse die das kann!? Vielleicht erweitern wir einfach unsere Klasse dahingehend das sie nicht so starr ist.

Noch mehr Flexibilität

Die fest eingebauten Templates sind zu starr für unsere Zwecke, irgendwie müssen die raus aus der Klasse. Zu Anfang habe ich ja schon geschrieben das die Templates in die eine Datei, die Klasse die aus den Templates fertiges HTML macht in eine andere Datei soll. Das die Klasse oben einen Konstruktor hat, hat seinen Sinn. Denn das ist unser nächster Ansatzpunkt.
Wir schieben einfach die Methode get_templates() in eine Template-Klasse und übergeben der Lister-Klasse ein Objekt das aus der Template-Klasse erzeugt wurde. Damit können wir innerhalb der Lister-Klasse auf die Templates zugreifen. Alles klar soweit? Nicht? Einfach das Beispiel anschauen.

<?php
require_once 'class-formatter.php';
require_once 'class-templates.php';

interface Templates
{
	public function get_templates();
}

class Lister extends Formatter
{	
	public $templates_object = NULL;

	public $templates = array();

	public function __construct( Templates $templates ){

		$this->templates_object = &$templates;

		$this->get_templates();

	}
	protected function get_templates(){

		if( NULL === $this->templates_object )
			throw new Exception( 'No templates defined' );

		$this->templates = &$this->templates_object->get_templates();

	}

	public function get_list( $type = '', $data = array() ){

		// get templates if not already set
		if( empty( $this->templates ) )
			$this->get_templates();

		// check if the requested list-typ is defined
		if( ! in_array( $type, array_keys( $this->templates ) ) )
			return FALSE;

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

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

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

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

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

	}

}

$data = array( 'Eins', 'Zwei', 'Drei' );

$list = new Lister( new Simple_List_Templates );

echo $list->get_list( 'ol', $data );
echo $list->get_list( 'ul', $data );
echo $list->get_list( 'div', $data );

<?php
class Simple_List_Templates implements Templates
{
	public function get_templates(){

		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"
			),
		);

	}
}

Ich möchte zur Erklärung schnell mal über die Klasse Lister fliegen. Am Anfang sehen wir ein Interface, das hat in sofern seinen Sinn, als dass man damit bestimmte Bedingungen festlegen kann. So wird im Konstruktor der Lister-Klasse festgelegt das ein Objekt übergeben werden muss das aus einer Klasse erstellt wurde die das Interface Template imlementiert. Damit gehen wir sicher, das dass übergebene Objekt über die Methode get_templates() verfügt. Würden wir versuchen ein Objekt zu übergeben das nicht über diese Methode verfügt, sprich nicht das Interface Template implementiert, würden wir beim Aufruf der Methode get_templates() eine Fehlermeldung bekommen. Damit gehen wir zwar nicht sicher das die Template-Klasse uns beim Aufruf der Methode get_templates() auch ein Array mit Templates zurück gibt, es hilft aber unter Umständen sehr bei der Fehlersuche wenn mal wieder etwas nicht funktioniert.
Im  Konstruktor sehen wir das bei der Parameterübergabe darauf gepocht wird das dass übergeben Objekt das Interface Templates implementieren muss. Das übergebene Objekt speichern wir uns in einer Klassen-Variablen damit wir in anderen Methoden ggf. darauf zugreifen können. Zum Schluss holen wir uns noch die heiß begehrten Templates von der Template-Klasse.
Als nächstes sehen wir dann eine get_templates() Methode. Die Methode sollte ja eigentlich ausgelagert werden. Hier steht sie quasi als Wrapper damit man z.B. noch weitere Kontrollen oder ähnliches einbauen kann. Natürlich hätte man auch z.B. in der Methode get_list() direkt auf die gespeicherte Instanz der Template-Klasse zugreifen können. Aber wir wollen uns ja mal angewöhnen gleich von Anfang an vernünftigen Code zu schreiben. Auch in Beispielen.
Über get_list() muss ich hoffentlich keine Worte mehr verlieren. Templates abholen, Variablen ggf. verifizieren und desinfizieren, Liste basteln und ausgeben.

Ein konkretes Beispiel

Im Prinzip sind wir schon fertig und haben alle unsere gesteckten Ziele erreicht. Die Templates (Ausgabe) stehen in der einen Datei, die Verarbeitung der Daten (Logik) in einer anderen. Beides ist sauber voneinander getrennt. Kommen wir noch mal kurz darauf zurück warum das so sinnvoll sein kann.
Nehmen wir einfach mal den Fall das wir relativ viele Templates haben in denen eine Footer definiert ist . Der könnte nach traditionellem HTML in etwa so aussehen:

<div class="footer">
	<p>Copyright © 2001-2012</p>
</div>

Nun kommt unser Kunde der gelesen hat das HTML5 der letzte Schrei ist und er möchte nun seine Webseite auf HTML5 umgestellt haben weil er befürchtet das sie ansonsten morgen nicht mehr erreichbar ist. Dazu müssten auch alle Footer-Bereiche nach HTML5-Footer konvertiert werden. Aus den Code oben müsste also in etwa folgendes werden:

<footer>
	<p>Copyright © 2001-2012</p>
</footer>

Und das dann nicht nur auf einer Seite, sondern auf allen. Und nicht nur die Footer, sondern auch die Bereiche die eine Section, Navigation, Artikel, usw. darstellen. Der richtige Zeitpunkt um eine Reihe böser Flüche los zu werden, denn das bedeutet tagelanges Wühlen in unübersichtlichen Codezeilen.
Nun werfen wir einen Blick auf unsere Template-Klasse. Dort habe ich eine “Div-Liste” definiert mit der man z.B. solche Footer-Bereiche erzeugen kann. Anstatt nun den kompletten Code neu zu schreiben, tauscht man einfach seine Template-Klasse aus. Aus Simple_List_Templates wird dann z.B. HTML5_List_Templates. Das macht die Sache doch erheblich einfacher als in jeder HTML-Datei Änderungen manuell durchzuführen.
Mit etwas Überlegung kommt man dann auch recht schnell darauf das es eine relativ blöde Idee ist die Template-Klasse beim erzeugen der Lister-Klasse fest zu verdrahten. Zu den Problem komme ich in einen anderen Artikel, dort will ich noch mal auf ein paar Feinheiten eingehen. Dann gehe ich auch noch mal auf die Key-Value-Paare in der Foreach-Schleife ein.

Aber wir sehen schon so, dass man mit der Trennung von Ausgabe und Logik für die Zukunft programmiert. Man kann sowohl die Logik als auch die Templates in verschiedenen Projekten erneut verwenden. Zudem sind Änderungen nicht mehr der Weltuntergang weil man unzählige Dateien durchsuchen und kontrollieren muss. Ich hoffe dem einen oder anderen einen kleinen Denkanstoß gegeben zu haben und wünsche viel Spaß beim selber Ausprobieren.

Vor allem bei WordPress sieht man folgende Konstrukte sehr häufig. Das hängt zum einen damit zusammen das WordPress keine Template-Engine hat und man gewissermaßen dazu gezwungen wird PHP und HTML zu vermischen. Zum anderen hängt es wohl auch damit zusammen, dass irgend ein Sepp bei WordPress mal damit angefangen hat solch grausige Konstrukte zu erstellen und jetzt einfach nicht mehr damit aufhören kann.

<?php
	$href	= 'http://example.com';
	$title	= 'Link zu Example.com';
	$class	= 'example_link';
	$id		= 'first_anchor';
	$text	= 'Dies ist ein Link zu Example.com';
?>
<a href="<?php echo $href; ?>" title="<?php echo $title; ?>" id="<?php echo $id; ?>" class="<?php echo $class; ?>"><?php echo $text; ?></a>

Übersichtlich und lesbar ist was anderes. Wirklich schlimm wird es dann, wenn anstatt der Variablen auch noch Funktionsaufrufe direkt in die Ausgabe gemischt werden. Fehler sind so quasi vorprogrammiert und diese dann zu finden, ist eine Qual.

Deutlich übersichtlicher wird es, wenn man Curly Braces verwendet. Anstatt jede Variable mit einem<?php echo ...; ?> auszugeben, verwendet man geschweifte Klammern ( { und } ) um die Variable in einem String unterzubringen.

<?php
echo "<a href=\"{$href}\" title='{$title}' id='{$id}' class='{$class}'>{$text}</a>";
?>

Das sieht doch schon mal deutlich übersichtlicher aus, hat aber auch seine Nachteile. Der String muss z.B. in doppelten Anführungszeichen (“) eingeschlossen sein, was zur Folge hat das man innerhalb des Strings nur einfache Anführungszeichen(‘) verwenden kann oder doppelte Anführungszeichen mit einem Backslash maskieren muss (\”).
Zudem funktionieren Funktionsaufrufe nicht mehr so einfach. Man müsste das Ergebnis des Funktionsaufrufes erst in einer Variablen zwischenspeichern bevor man den Wert im String verwenden kann. Dies kann etwas kniffelig werden wenn die Funktion keinen Wert zurück gibt, sondern ihn stattdessen direkt ausgibt.

Arbeitet man mit Klassen, ist es etwas leichter den Rückgabewert einer Funktion im String mit geschweiften Klammern zu integrieren.

<?php
	class Link
	{
		public $href	= 'http://example.com';
		public $class	= 'example_link';
		public $id		= 'first_anchor';
		public $text	= 'Dies ist ein Link zu Example.com';

		public function get_title(){
			return 'Link zu Example.com';
		}
	}

	$obj = new Link();

	echo  "<a href='{$obj->href}' title='{$obj->get_title()}' id='{$obj->id}' class='{$obj->class}'>{$obj->text}</a>";
?>

Genau genommen handelt es sich hierbei um einen Methodenaufruf und nicht um einen Funktionsaufruf. Der “Trick” an der ganzen Sache ist einfach der, dass PHP $obj wie eine Variable behandelt (was es ja auch ist) und deswegen der Methodenaufruf relativ problemlos möglich ist.

Der größte Nachteil an allen Varianten ist meiner Meinung nach aber der, dass man Logik und Ausgabe miteinander vermischt. Gerade wenn man komplexe Ausgaben hat, wird es schwer die Stelle wiederzufinden an der die gesuchte Ausgabe formatiert wird.
Besser wäre es, wenn man alle Strings zentral an einer Stelle sammelt und in der Logik dann nur noch eine Variable zur Ausgabe verwendet.

<?php
$format = "<a href='{$href}' title='{$title}' id='{$id}' class='{$class}'>{$text}</a>";

// some other code...

echo $format;
?>

Dies wäre ein netter Ansatz, hat jedoch auch so seine Haken. Denn $format kann erst gebildet werden, nachdem alle anderen Variablen bereits definiert sind.

<?php
$format = "<a href='{$href}' title='{$title}' id='{$id}' class='{$class}'>{$text}</a>";

// some other code...

$text = 'Ein anderer Linktext';
echo $format;
?>

Würde zum Beispiel nicht funktionieren. Denn zu dem Zeitpunkt an dem $format erstellt wird ist $text noch gar nicht oder mit einen anderen Wert definiert.

Wir bräuchten also eine Funktion die quasi einen abstrakten Formatierungs-String entgegen nimmt und an den entsprechenden Stellen die Werte der Variablen einsetzt. Grundsätzlich hat PHP eine solche Funktion: printf() bzw. sprintf().
printf()nimmt einen Formatierungs-String und eine Reihe an Variablen entgegen. Die Platzhalter im Formatierungs-String erlauben zudem eine gewisse Formatierung der Ausgabe.

<?php
$format = "<a href='%s' title='%s' id='%s' class='%s'>%s</a>";

// some other code...

printf( $format, $href, $title, $id, $class, $text );
?>

Das sieht schon ganz brauchbar aus. Der Formatierungs-String kann z.B. ganz am Anfang des Scriptes definiert werden bevor auch nur eine der verwendeten Variablen definiert wurde. Und man kann anstatt einer Variablen auch einen Funktionsaufruf verwenden.
Einige kleine Nachteile hat printf() jedoch auch. In der gezeigten Variante muss z.B. die Reihenfolge strikt eingehalten werden. printf() bietet einige Möglichkeiten wie man die Reihenfolge flexibler gestalten kann und Variablen mehrfach verwenden kann. Zur genauen Verwendung der Formatierung schaut man am besten im PHP-Manual nach.

Aber auch printf() wird bei komplexen Ausgaben recht schnell unübersichtlich. Vertauscht man zwei Variablen im Funktionsaufruf, kommt es zur fehlerhaften Ausgabe. Auch wenn man die mehrfache Verwendung von Variablen nutzt, muss man die Übersicht behalten an welcher Stelle welche Variable steht.
Im Großen und Ganzen eine etwas unbefriedigende Situation die zu unleserlichen Code und versteckten Fehlern führt. Aus diesen Grund habe ich mir eine Klasse geschrieben mit der ich den Code etwas übersichtlicher gestalten kann.
Die Anforderung lag darin, zum einen die Übersichtlichkeit der Variante mit geschweiften Klammern zu erhalten. Zum anderen die Flexibilität, Abstraktion und Formatierungsmöglichkeiten von printf() zu haben. Heraus gekommen ist die Klasse Formatter.

Formatter nimmt einen Formatierungs-String ähnlich wie printf() entgegen, jedoch kann man den Platzhaltern Namen geben, was für mehr Übersichtlichkeit sorgt. Als zweiten Parameter nimmt Formatter ein Array mit Schlüssel-Werte-Paaren oder ein Objekt entgegen. Daher spielt die Reihenfolge in der die Werte definiert werden keine Rolle mehr. Zusätzlich lässt sich die Ausgabe wie bei printf()formatieren.

<?php
$format_time = 'Es ist jetzt %stunden[02d]%:%minuten[02d]%:%sekunden[02d]% Uhr %tageszeit%';
// some other code...

$time_values = array(
		'tageszeit'	=> 'mitten in der Nacht',
		'stunden'	=> 1,
		'minuten'	=> 23,
		'sekunden'	=> 8,
	);
// more code...

Formatter::printf( $format_time, $time_values );
// Es ist jetzt 01:23:08 Uhr mitten in der Nacht.
?>

So ist es sehr leicht Formatierung, Logik und Ausgabe voneinander zu trennen und das dann auch noch lesbar zu gestalten. Das es durchaus Vorteile hat das alles voneinander zu trennen, zeige ich dann im nächsten Artikel.

$mPost = array(
		'action'	=> 'send',
		'user'		=> 'Horst',
		'a'		=> 'On',
		'c'		=> 'On',
		'foo'		=> 'bar',
		'baz'		=> '',
	);

Dies ist nun eine Simulation des POST-Arrays und man kann sehen das für ‘b’ kein Wert gesetzt wurde sofern die Checkbox ‘b’ nicht ausgewählt wurde.
Wie wertet man nun üblicherweise die drei Checkboxen aus? Wahrscheinlich mit vielen If-ElseIf-Else Konstrukten und isset():

if( isset( $_POST['a'] ) )
...
elseif( isset( $_POST['a'] ) && isset( $_POST['b'] ) )
...
elseif( isset( $_POST['a' ) && ! isset( $_POST['b' ) )
...

if( isset( $_POST['b'] ) && isset( $_POST['c'] ) )
...

So wühlt man sich Zeile für Zeile durch alle möglichen Kombinationen und versucht keine zu vergessen. Das. Ist. Blöd! Und nicht nur blöd, sondern auch verdammt unübersichtlich. Bei drei Checkboxen mag es noch machbar sein, aber wenn man fünf, acht oder mehr Checkboxen hat, dann wird es fast schon unmöglich alle Kombinationen von ausgewählten und nicht ausgewählten Checkboxen zu berücksichtigen.

Da eine Checkbox nur ein Ja-Nein-Wert (Wahr oder Falsch) darstellt, habe ich mich recht schnell an die Zeit erinnert als ich mit der Computerei angefangen habe. Damals hatte ich einen C16 mit 16kB RAM. Dort war jedes Bit kostbarer als Gold und durfte nicht verschwendet werden. Deswegen hatte man oft mit Bitmasken gearbeitet. In einer Bitmaske steht jedes Bit für einen Ja oder einen Nein-Wert. Das war und ist recht effizient, denn in einem Byte kann ich so 8 Werte speichern. Und natürlich auch wieder abfragen.

Nun stehen wir vor dem Problem unsere drei Checkboxen in eine Bitmaske zu bekommen. Dazu benötigen wir erst einmal eine entsprechende Maske. Mit printf() bzw. sprintf() können wir eine solche Maske leicht erstellen:

$bin = sprintf( '%b%b%b', $mPost['a'], $mPost['b'], $mPost['c'] );

Das PHP-Manual sagt zum Platzhalter %b folgendes:

das Argument wird als Integer angesehen und als Binär-Wert ausgegeben

%b wird also immer zu 1 oder 0 umgewandelt. Wandeln wir nun unsere Variablen (a, b und c) in Boolsche Werte um, so würde PHP %b durch 1 bzw. 0 ersetzen, je nachdem ob die Variable TRUE oder FALSE ist. Denn zuerst würde der boolsche Wert in einen Integer (1 bzw. 0) umgewandelt und dann in einen einstelligen Binärwert. Dies erreichen wir dadurch, dass wir mit isset() abfragen ob die Variable überhaupt existiert. Somit umschiffen wir gleichzeitig das Problem das nicht ausgewählte Checkboxen keinen Wert übertragen.

$bin = printf( '%b%b%b', isset( $mPost['a'] ), isset( $mPost['b'] ), isset( $mPost['c'] ) );

Das klappt soweit schon wunderbar und bei drei Checkboxen ist es auch noch recht übersichtlich.
Als Ergebnis erhalten wir einen String der z.B. “101″ enthält. Je nachdem welche Variable gesetzt ist und welche nicht. Diesen String können wir nun ganz einfach mit einem switch-case abfragen und darauf reagieren:

switch( $bin ){
	case '000':
		//nichts ausgewaehlt
	break;

	case '100':
		// nur checkbox 'a' wurde ausgewählt
	break;

	case '101':
		// checkbox 'a' wurde ausgewaehlt, checkbox 'b' jedoch NICHT, checkbox 'c' ist uns egal
	break;

	default:
		// alle anderen Faelle
	break;
}

Bei drei Checkboxen ist das schon eine ganz brauchbare Lösung. Aber was ist wenn wir jetzt, sagen wir mal, 20 Checkboxen haben. Zum Beispiel eine Umfrage oder ähnliches?
Hier stehen wir vor zwei Problemen. Zum einen wäre der sprintf() nicht mehr übersichtlich und recht unbrauchbar. Zum anderen müssen wir ja gewähren das jede Variable an ihren Platz ist und nicht z.B. ‘a’ und ‘g’ vertauscht sind.

Als erstes legen wir uns mal ein Muster fest welche Variablen uns in welcher Reihenfolge interessieren. Das machen wir einfach mit einem Array:

$defaults = array(
		'a'	=> '',
		'b'	=> '',
		'c'	=> '',
	);

Damit wir nicht mit uninitialisierten Variablen arbeiten müssen, mischen wir das POST-Array mit unserer Vorgabe. Dadurch gehen wir sicher das alle benötigten Variablen auch mit einem (leeren) Wert initialisiert sind.

$data = array_merge( $defaults, $mPost );

Nun müssen wir nur noch über unser Vorgabe-Array ($defaults) laufen und abfragen ob die entsprechenden Schlüssel im Daten-Array ($data) gesetzt sind.

$bin = '';
foreach( $defaults as $key => $val )
	$bin .= sprintf( '%b', !!$data[$key] );

Dies kann man auch anders lösen, z.B. mit einem Trinären Operator. Je nach Geschmack des Programmierers halt:

$bin .= ! empty( $data[$key] ) ? '1' : '0';

Wenn der entsprechende Wert im Daten-Array nicht leer ist, wird eine 1 ausgegeben, ansonsten eine 0.
Als Ergebnis erhalten wir wieder einen String mit vielen Einsen und Nullen den wir im Switch-Case abfragen können. Wandelt man den String mit bindec() in eine Dezimalzahl um, kann man die Auswahl schön platzsparend speichern. Wenn man mit Cookies arbeitet, wird man nämlich schnell wieder daran erinnert das Speicherplatz Mangelware ist. Odre man nutzt den Dezimalwert um eine statistische Auswertung durchzuführen. Oder verwendet ihn im Switch-Case. Oder mit If-Abfragen. Oder, oder, oder…

Und hier das ganze dann  noch mal als komplettes Script:

$mPost = array(
		'action'	=> 'send',
		'user'		=> 'Horst',
		'a'			=> 'On',
		'c'			=> 'On',
		'foo'		=> 'bar',
		'baz'		=> '',
	);

$defaults = array(
		'a'	=> '',
		'b'	=> '',
		'c'	=> '',
	);

$data = array_merge( $defaults, $mPost );

$bin = '';

foreach( $defaults as $key => $val ){
	$bin .= sprintf( '%b', !!$data[$key] );
	//$bin .= ! empty( $data[$key] ) ? '1' : '0';
}	

$dec = bindec( $bin );

var_dump( $bin );
var_dump( $dec );

switch( $bin ){
	case '000':
		//nichts ausgewaehlt
	break;
	
	case '100':
		// nur checkbox 'a' wurde ausgewählt
	break;
	
	case '101':
		// checkbox 'a' wurde ausgewaehlt, checkbox 'b' jedoch NICHT
	break;
	
	default:
		// alle anderen Faelle
	break;
}

Zum Schluss noch etwas “dreckiges” PHP. Hier möchte ich mal schnell den NOTNOT-Operator einwerfen auf den ich bei der Suche nach der Lösung gestoßen bin. !$data[$key] wird Wahr (TRUE) wenn $data[$key] leer ist. Ich möchte aber wissen ob eine Variable nicht leer ist, denn printf() soll ja aus ‘%b’ eine ’1′ machen wenn die Variable gesetzt ist. Also muss ich die Bedingung !$data[$key] noch einmal negieren. Aus !$data[$key] wird also !!$data[$key].
Dies ist also im Grunde genommen nur eine fürchterliche Kurzschreibweise für ! empty( $data[$key] ). Für das schnelle Programmieren sind solche Kurzschreibweisen ganz nützlich. Sie sparen eine Menge Tipperei wenn man viel Code schreiben muss. Für die Lesbarkeit des Codes sind sie jedoch sehr kontraproduktiv. Man muss schon genau überlegen was da gerade passiert und sicher gehen das die Variable auch initialisiert ist, ansonsten hagelt es Notices.

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.

Die Klasse lässt sich vielfältig konfigurieren und flexibel einsetzen. Mit der statischen Methode is_WP() lässt sich z.B. prüfen ob WordPress bereits gestartet wurde. Ist dies nicht der Fall, werden 403-Header (forbidden) gesendet und das Script beendet. Dies ist z.B. nützlich um ein Script gegen direktes Aufrufen zu schützen.
Bsp.:

// beendet das Script falls WordPress nicht zuvor gestartet wurde
WP_Environment_Check::is_WP();

Kern der Klasse sind allerdings die drei Methoden check_wp(), check_php() und run_all_tests() (die Methode check_mysql() ist, wie erwähnt, nur der Vollständigkeit halber dabei und dürfte eher selten Anwendung finden). Konfiguriert man ein Array oder ein Objekt mit den entsprechenden Werten und übergibt das Array bzw. Object der Methode run_all_tests(), so werden die entsprechenden Versionen geprüft und ggf. das Script beendet. Natürlich kann man auch nur einzelne Komponenten testen. Im Gist ist noch eine Datei mit einigen Beispielen, ich denke dadurch wird klar wie man die Klasse verwenden kann.
Im Normalfall ruft man die Klasse beim Aktivieren des Plugins auf, so dass das Plugin erst gar nicht aktiviert wird.

Nun möchte man vielleicht nicht gleich mit dem Hammer zuschlagen und das Script beenden weil es sich um ein Theme und nicht um ein Plugin handelt. Dafür ist die Methode set_die_on_fail() nützlich. Übergibt man ihr den Wert TRUE, so wird das Script bei einen fehlerhaften Test nicht beendet, sondern FALSE als Rückgabewert zurück gegeben. Die Rückgabewerte kann man dann entsprechend auswerten und Meldungen ausgeben.

Falls man mit den Standardmeldungen nicht glücklich ist, kann man diese ebenfalls recht einfach anpassen. Einfach der Klasse einen neuen String übergeben. Das macht z.B. Übersetzungen der Fehlermeldungen recht einfach. Auch hierzu gibt es ein Beispiel im Gist.

Vielleicht findet der eine oder andere die Klasse ganz nützlich oder erweitert sie sogar. In beiden Fällen würde ich mich über Feedback natürlich freuen. Und hier noch der Gist zur Klasse und den Beispielen:

<?php
/**
 * 
 * Class to check the environment (WordPress-, PHP and MySQL-version)
 * Test only on minimum or equal version
 * 
 * @author Ralf Albert
 * @version 1.0
 * 
 * @var array|object $versions (optional) Array with key=>val or object $version->wp|php|mysql; what to test => minimum version
 *
 */
class WP_Environment_Check
{
	/**
	 * 
	 * WP version
	 * @access public
	 * @var string minimum or equal version of WordPress
	 */
	public $wp	  = '3.2';

	/**
	 * 
	 * PHP version
	 * @access public
	 * @var string minimum or equal version of PHP
	 */
	public $php   = '5.2';

	/**
	 * 
	 * MySQL version
	 * @access public
	 * @var string minimum or equal version of MySQL
	 */
	public $mysql = '5.0';

	/**
	 * 
	 * Exit message if WordPress test failed
	 * @access public
	 * @var string
	 */
	public $exit_msg_wp = '';

	/**
	 * 
	 * Exit message if PHP test failed
	 * @access public
	 * @var string
	 */
	public $exit_msg_php = '';

	/**
	 * 
	 * Exit message if MySQL test failed
	 * @access public
	 * @var string
	 */
	public $exit_msg_mysql = '';

	/**
	 * 
	 * If set to true, the class will die with a message if a WP|PHP|MySQL test fail.
	 * Does not affect is_WP() or if forbidden_headers() is called withot a message 
	 * @access public static
	 * @var bool true (default)|false
	 */
	public static $die_on_fail = TRUE;

	/**
	 * 
	 * Constructor
	 * Run all test that are defined in $version
	 * @access public 
	 * @param array|object $versions
	 */
	public function __construct( $versions = NULL ){
		self::is_WP();

		if( ! empty( $versions ) || ( is_array( $versions ) || is_object( $versions ) ) )
			$this->run_all_tests( $versions );
	}

	/**
	 * 
	 * Set $die_on_fail
	 * @param bool $status True exits the script with a message 
	 */
	public function set_die_on_fail( $status = TRUE ){
		if( ! is_bool( $status ) )
			$status = (bool) $status;

		self::$die_on_fail = $status;
	}

	/**
	 * 
	 * Check if WordPress is active (if $wp is an object of class wp() )
	 * @access public static
	 * @return bool true|die with message and send forbidden-headers if WP is not active
	 */
	public static function is_WP(){
		global $wp;

		if( ! $wp instanceof WP )
			self::forbidden_header();
		else
			return TRUE;
	}

	/**
	 * 
	 * Run all tests
	 * @access public
	 * @param array|object $versions
	 * @return bool true if all tests passed successfully
	 */
	public function run_all_tests( $versions = NULL ){
		if( empty( $versions ) || ( ! is_array( $versions ) && ! is_object( $versions ) ) )
			return FALSE;

		$tests = array( 'wp', 'php', 'mysql' );

		foreach( $versions as $test => $version ){
			// check if the wanted test is available (means: is the test x a method 'check_x')
			if( in_array( strtolower( $test ), $tests ) ){
				$method = strtolower( $test );
				$func = 'check_' . $test; // create the method (check_wp|check_php|check_mysql)
				$this->$method = $version; // set $this->wp|php|mysql to version x

				if( ! call_user_func( array( &$this, $func ) ) )
					die( 'Test ' . __CLASS__ . '::' . $func . ' failed!' ); // this should never happen...
			}
		}

		return TRUE;
	}

	/**
	 * 
	 * Check WordPress version
	 * @access public
	 * @return bool true returns true if the test passed successfully. Die with a message if not.
	 */
	public function check_wp(){
		if( empty( $this->wp ) )
			return FALSE;

		if( empty( $this->exit_msg_wp ) )
			$this->exit_msg_wp = 'This plugin requires WordPress ' . $this->wp . ' or newer. <a href="http://codex.wordpress.org/Upgrading_WordPress">Please update WordPress</a> or delete the plugin.';

		global $wp_version;
		if( ! version_compare( $wp_version, $this->wp, '>=' ) ){
			return self::forbidden_header( $this->exit_msg_wp );
		}

		return TRUE;
	}

	/**
	 * 
	 * Check PHP version
	 * @access public
	 * @return bool true|die with message
	 */
	public function check_php(){
		if( empty( $this->php ) )
			return FALSE;

		if( empty( $this->exit_msg_php ) )
			$this->exit_msg_php = 'This plugin requires at least PHP version <strong>' . $this->php . '</strong>'; 

		if( ! version_compare( PHP_VERSION, $this->php, '>=' ) ){
			return self::forbidden_header( $this->exit_msg_php );
		}

		return TRUE;
	}

	/**
	 * 
	 * Check MYSQL version
	 * @access public
	 * @return bool true|die with message
	 */
	public function check_mysql(){
		if( empty( $this->mysql ) )
			return FALSE;

		if( empty( $this->exit_msg_mysql ) )
			$this->exit_msg_mysql = 'This plugin requires at least MySQL version <strong>' . $this->mysql . '</strong>';

		global $wpdb;
		if( ! version_compare( $wpdb->db_version(), $this->mysql, '>=' ) ){
			return self::forbidden_header( $this->exit_msg_mysql );
		}

		return TRUE;
	}

	/**
	 * 
	 * Send forbidden-headers (403) if no message is set. Only dies if a message is set
	 * @access public static
	 * @param string (optional) $exit_msg
	 */
	public static function forbidden_header( $exit_msg = '' ){

		if( empty( $exit_msg ) ){
			header( 'Status: 403 Forbidden' );
			header( 'HTTP/1.1 403 Forbidden' );
			die( "I'm sorry Dave, I'm afraid I can't do that." );
		} else {		
			if( FALSE === self::$die_on_fail )
				return FALSE;
			else			
				die( $exit_msg );
		}
	}	
}

<?php
/*
 * Mocking
 */
class WP{}
$wp = new WP;

class WPDB
{
	public function db_version(){
		return '5.1';
	}
}
$wpdb = new WPDB();

$wp_version = '3.3.1';
/* end mocking */

/*
 * Creating an instance ov WP_Environment_Check
 * Setup the minimum versions
 * Setup an exit-message if the WordPress test fail
 * Performs every single test one by one  
 */

$a = new WP_Environment_Check();
$a->wp = '3.3.1';
$a->php = '5.2';
$a->mysql = '5.1';
$a->exit_msg_wp = 'The plugin <em><a href="http://example.com/my_plugin/">Acme Plugin</a></em> requires WordPress ' . $a->wp . ' or newer. <a href="http://codex.wordpress.org/Upgrading_WordPress">Please update WordPress</a> or delete the plugin.';
$a->check_wp();
$a->check_php();
$a->check_mysql();

/*
 * Creating an object with the minimum versions
 * Create an instance of WP_Environment_Check
 * Performs all tests at once
 */

$v = new stdClass();
$v->wp = '3.3.1';
$v->php = '5.2';
$v->mysql = '5.0';
$a = new WP_Environment_Check();

$a->run_all_tests( $v );


/*
 * Setup an array with the minimum versions
 * Performs all test by creating an instance of WP_Environment_Check
 */

$v = array( 'wp' => '3.0', 'php' => '5.2', 'MySQL' => '5.1' );
$a = new WP_Environment_Check( $v );

/*
 * Store testresult in an object. Disable dying if tests failed
 */

$a = new WP_Environment_Check();
$a->set_die_on_fail( FALSE );
$a->wp = '3.3.1';
$a->php = '5.2';
$a->mysql = '7.0';

$r = new stdClass();

$r->wp = $a->check_wp();
$r->php = $a->check_php();
$r->mysql = $a->check_mysql(); // fail on MYSQL -> 'mysql' => false

var_dump( $r );

Zunächst einmal ein Stück PHP-Code wie er lange Zeit für WordPress-Plugins benutzt wurde. Unter anderem, weil der Codex es so vorgeschlagen hatte (mittlerweile wird von der Verwendung dieses Codes dringendst abgeraten):

	// Pre-2.6 compatibility
	if ( ! defined( 'WP_CONTENT_URL' ) )
		define( 'WP_CONTENT_URL', get_option( 'siteurl' ) . '/wp-content' );
	if ( ! defined( 'WP_CONTENT_DIR' ) )
		define( 'WP_CONTENT_DIR', ABSPATH . 'wp-content' );
	if ( ! defined( 'WP_PLUGIN_URL' ) )
		define( 'WP_PLUGIN_URL', WP_CONTENT_URL. '/plugins' );
	if ( ! defined( 'WP_PLUGIN_DIR' ) )
		define( 'WP_PLUGIN_DIR', WP_CONTENT_DIR . '/plugins' );

Der Code ist relativ logisch. Sollten bestimmte Konstanten nicht definiert sein, so werden sie definiert. So weit, so unschlimm. Aber der Teufel steckt, wie so oft, im Detail.
Bedenkt man das alle Plugins nacheinander geladen werden, wird schnell klar dass das erste Plugin welches diese Konstanten definiert gewinnt. Typische Race Condition: Wer zuerst kommt, mahlt zuerst.
Was passierte nun wenn das erste Plugin das geladen wurde WP_CONTENT_URL nicht dem Codex entsprechend mit get_option( 'siteurl' ) . '/wp-content' ) definierte, sondern z.B. mit define( 'WP_CONTENT_URL', '/my_bad_content/wp-content/' ); ? Ganz klar, alle anderen Plugins die auf WP_CONTENT_URL zurückgriffen versuchten aus dem falschen Verzeichnis zu lesen. Da define() nicht “überschreibbare globale Variablen”, auch bekannt als Konstanten, definiert, konnte auch kein anderes Plugin den Pfad zum wp-content-Verzeichnis wieder grade biegen.
Im einfachen Fall führt das zu nicht mehr funktionierenden Plugins. Im schlimmeren Fall deutet WP_CONTENT_URL auf einen entfernten Server und könnte Schadcode nachladen. Zugegeben, ein sehr konstruierter Fall da WordPress in der Regel diese Konstanten selber definiert hatte. Aber es ist nun einmal ein mögliches Szenario was man im Hinterkopf haben sollte.

Nun haben wir die 2.6er Zeit in WordPress ja hoffentlich lange hinter uns gelassen und niemand verbreitet mehr Plugins die solche Code-Zeilen enthalten. Oder? Ich schau mal böse zu den Kollegen rüber und schweige mich aus wo ich den Code her habe. Ich müsste auch einige böse anschauen, dazu fehlt mir die Zeit.

Aber was für WordPress-Konstanten gilt, gilt leider auch für unsere eigenen Konstanten. Schnell mal mit define() eine Konstante definieren weil die Verwendung von Konstanten ja so einfach ist. “Ich definiere in Datei A eine Variable die ich in Datei B brauche? Nimm eine Konstante, die sind überall verfügbar.” Dies ist ein Gedankengang, von dem wir uns schleunigst trennen sollten.
Das fängt damit an, dass Konstanten “überall” verfügbar sind. Es interessiert kein anderes Script wo ich z.B. meine JavaScript-Dateien ablege, deswegen braucht es auch kein define( 'SCRIPT_DIR', '/my_ugly_dir/ );. Mal davon abgesehen das ich damit Informationen “nach außen” trage die andere nicht interessieren, verseuche ich damit auch den globalen Namensraum. Alle anderen Scripte können nun die Konstante SCRIPT_DIR nicht mehr verwenden da sie bereits belegt ist.
Um diesen Umstand zu umgehen, werden Konstanten gerne mit Prefixen versehen. define( 'MY_UGLY_SCRIPT_DIR', '/my_ugly_script_dir' ); ist auch nicht wesentlich besser. Je mehr Plugins auf den Markt kommen, desto einfallsreicher muss ich meine Prefixe aussuchen. Das endet in immer längeren Prefixe und macht den Code am Ende nur unübersichtlicher. Zudem löst es das Problem von Namenskollisionen nicht komplett.

Denn was ist denn wenn ich mehr als ein Plugin schreibe? Hand auf’s Herz, wir sind doch alles faule Säue. Also kopieren wir einfach Code den wir bereits geschrieben haben um ihn wiederzuverwenden. So gesehen nicht schlimm, ist ja sogar quasi ein empfohlenes Vorgehen. Nur blöd wenn ich in zwei Plugins die gleiche Konstante verwende, sie jedoch in beiden Plugins unterschiedliche Werte enthält (z.B. __FILE__.
Race Condition. Das zuerst geladene Plugin gewinnt. Ich mache mir das Leben also unnötig schwer. Denn Code den ich einmal geschrieben habe, kann ich nicht gefahrlos wiederverwenden ohne ihn erneut anzufassen.

Ewig nur meckern kann aber auch nicht die Lösung sein. Eine Alternative zu define() kommt aus dem OOP-Bereich und ist ein einfacher Datencontainer.

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

	public static function __set( $name, $value ){
		if( ! isset( self::$data[$name] ) )
			self::$data[$name] = $value;
		else
			return FALSE;

		return TRUE;
	}

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

$dc = new DataContainer;
$dc->FILE = basename( __FILE__ );

var_dump( $dc->FILE );

$dc_two = new DataContainer;
$dc_two->FILE = 'mettigel';

var_dump( $dc->FILE );

Das Prinzip sollte schnell klar sein. Es wird eine Klasse erzeugt die nichts anderes macht als Variablen über die magischen Methoden __set() und __get() entgegen zu nehmen und zu speichern. Da das Array $data als statisch deklariert wurde, wird es bei neuen Instanz der Klasse nicht verändert.
Der Trick an der ganzen Sache besteht darin, in der magischen Methode __set() zu überprüfen ob die Variable $name bereits gesetzt ist. Ist sie es nicht, wird sie gesetzt. Ist sie es, wird FALSE zurück gegeben. So sind einmal gesetzte Variablen vor dem Überschreiben geschützt.
Damit kann man die Klasse DataContainer genauso verwenden wie ein define(). Darüber hinaus kann man sich auch noch eine Methode reset( $name ) schreiben, mit der man im Notfall eine einmal gesetzte Pseudo-Konstante wieder löschen kann. Selbst ein redefine(), das es in PHP nicht gibt, wäre damit möglich. Mit so einem Datencontainer sind wir also sogar flexibler als mit define().

Jetzt stellt sich natürlich die Frage wenn ich den Datencontainer in Datei a.php habe, aber in Datei b.php darauf zugreifen will, wie macht man das?
Da gibt es elegante und weniger elegante Wege. Ein etwas weniger eleganter Weg wäre es den Datencontainer mittels define()verfügbar zu machen.

$dc = new DataContainer;
$dc->FILE = basename( __FILE__ );
define( 'DATACONTAINER', serialize( $dc ) );

// somewhere over the rainbow ... ehmm ... in another file
$e = unserialize( DATACONTAINER );
var_dump( $e->FILE );

Bitte schlagt mich nicht für diesen Code-Schnipsel. Kann man machen, muss man aber nicht. Denn deutlich eleganter geht es mit einem Autoloader, darüber schreibe ich aber demnächst etwas (Cliffhänger )

Ich hoffe es ist klar geworden das die Verwendung von Konstanten relativ viele Probleme mit sich bringt die man relativ einfach beseitigen kann. Überlassen wir die Verwendung von Konstanten besser WordPress und widmen uns lieber einfacheren und eleganteren Methoden.

Viele Tests messen einfach das, was man einfach messen kann. Das wäre dann z.B. der Speicherverbrauch. Dann wird auch gerne die Ausführungszeit gemessen, was aber aufgrund der unterschiedlichen Systeme schon kaum noch Aussagekraft hat. Reicht das alles nicht, kommen gerne noch so obskure Faktoren wie Codezeilen oder Anzahl der verwendeten Hooks und Filter hinzu.
Selten bis gar nicht wird die Code-Qualität bewertet. Dies ist für mich aber ein sehr wichtiges Kriterium. Denn ein schlampig programmiertes Plugin läuft oft auch schlampig, wirft Fehlermeldungen und ist nicht zukunftssicher. Häufig sieht man Plugins die über die Jahre gewachsen sind bis der Autor selber den Überblick verliert. Entweder wird das Plugin dann von Grund auf neu programmiert und weiter gepflegt. Oder aber, was häufiger vorkommt, man lässt das Plugin so wie es ist und kümmert sich nicht mehr darum.
Nun ist Code-Qualität nicht ganz so einfach zu “messen”. Man muss den Code bewerten und hierzu eine Reihe von Kriterien heranziehen. das kostet Zeit und Mühe, weshalb es wohl niemand macht. Ein Kriterium wären zum Beispiel die Übersichtlichkeit. Das kann eigentlich jeder bewerten der sich den Code anschaut. Oder aber auch ob der Code ein Wust aus wilden Zeilen darstellt die kaum entzifferbar sind. Ist der Code gut kommentiert damit auch jemand der nicht so viel Ahnung von Programmierung hat versteht was da vor sich geht. Hält der Code sich an gewisse Programmierrichtlinien. Nur um mal einige wenige Kriterien zu nenne die man verwenden kann.
All das kann man mit Noten bewerten, sogar relativ objektiv. Nun werden einige sagen “Hauptsache es rennt!“. Das ist natürlich auch ein Argument. Also zieht man noch die Anzahl an Fehlern, Notices usw. heran die das Plugin wirft wenn man es einsetzt. Auch grausam geschriebener Code kann fehlerfrei laufen. So kommt man schon zu einen recht guten und nachvollziehbaren Ergebnis.
Kennt man sich bei der Programmierung ein wenig besser aus, dann kann man auch noch einzelne Code-Abschnitte genauer unter die Lupe nehmen. Ist der Code gemäß den empfohlenen Vorgaben geschrieben? Wenn nicht, macht es Sinn von den Vorgaben abzuweichen? Gibt es “merkwürdige” Programmiertechniken im Code oder ist alles auf den ersten Blick verständlich?

Für mich sind dies deutlich wichtigere Faktoren als Millisekunden Laufzeit und Megabyte Speicherverbrauch. Denn dies sind Faktoren die ich erklären kann, so dass auch jemand der weniger Ahnung hat versteht wie ich zu meinen Testergebnis gekommen bin. Und vor allem wird schnell deutlich wo noch Potenzial für Verbesserungen besteht. Code der leicht verständlich ist, wird auch gerne von anderen gepflegt, so dass er sich recht schnell verbreitet und mit der Zeit (hoffentlich) besser wird.

Ein ziemlich merkwürdiger Test macht hingegen gerade auf Google+ die Runde. Es geht um den Plugin-Test von MillaN. Sergej Müller hat sich wohl zurecht gefragt wie MillaN auf seine Ergebnisse kommt. Getestet wurden 35 Plugins aus den unterschiedlichsten Kategorien und mit einem Wert von 1 (schlecht) bis 5 (sehr gut) bewertet. Nur wie dieser Wert zustande kommt, bleibt vielen vollkommen unergründlich.
Vielleicht ist weniger Speicherverbrauch besser als mehr? Also FPW Post Instructions bekommt eine 4 bei einem konstanten Speicherverbrauch von 0,1MB. GD Press Tools Pro verbraucht zwar 29 mal so viel Speicher (2,9MB), bekommt aber die Bestnote 5. Es scheint also etwas mit dem Speicherverbrauch im Frontend bzw. Backend zu tun zu haben. Denn GD Press Tools Pro verbraucht im Frontend “nur” 2MB Speicher, während FPW Post Instructions sowohl vorne wie hinten den gleichen Speicherverbrauch hat. So wirklich schlüssig ist das Konzept jedoch nicht. Denn Event Manager bekommt die schlechteste Note 1 bei einem Speicherverbrauch von 5 bzw 3,7MB (Front-/Backend). GD Custom Posts And Taxonomies Tools Lite bekommt für die gleiche Leistung (1,5/1,3MB) eine noch ganz gute 4 verpasst. Event Manager ist also schlechter obwohl es mehr Speicher einspart?
Ich könnte jetzt noch weiter rätseln ob es vielleicht an der Ausführungszeit liegt oder an der Anzahl der verwendeten Hooks. Vielleicht auch am Mondstand beim Test des Plugins. Man weiß es nicht und der Autor trägt auch nicht zur Aufklärung bei.

Grade 2 plugins have only some elements of optimization, but they are close to grade 1. Adminimize plugin shouldn’t even load on the front end except for some elements, and that needs to be optimized.

Das soll also der Grund sein warum einige Plugins schlechter sind als andere? Adminimize soll z.B. im Frontend nur das laden was es benötigt, was es im Prinzip auch macht, dies sollte aber optimiert werden? Hö? Es scheint also darum zu gehen was ein Plugin im Front- bzw. Backend lädt. Da ist es wohl egal welche Aufgabe es hat, wenn es nicht den geheimen Richtlinien des Autors entspricht, ist es schlecht.

Na dann schauen wir uns doch mal eins dieser supertollen Grade-5 Plugins an. Ich habe mich für GD Unit Converter entschieden und es mal unter die Lupe genommen. Was mir beim ersten Blick auffiel, waren folgende Codezeilen:

$this->script = $_SERVER["PHP_SELF"];
$this->script = end(explode("/", $this->script));

Und? Sinn erkannt? Also ich habe erst mal längere Zeit gerätselt was da passiert bis ich den Code kopiert und getestet habe. OK, ich schreibe es mal ein wenig um:

$this->script = basename(__FILE__);

So einfach kann PHP sein. Der nächste Horror folgt sofort:

    private function plugin_path_url() {
        $this->plugin_url = plugins_url("/gd-unit-converter/");
        $this->plugin_path = dirname(dirname(__FILE__))."/";

        define("GDUNITCONVERTER_URL", $this->plugin_url);
        define("GDUNITCONVERTER_PATH", $this->plugin_path);
    }

Da werden also zwei globale Variablen definiert die zwanzig Zeilen später bei einem wp_enqueue_script() wieder verwendet werden. Klar, man hätte auch einfach auf $this->plugin_url zurück greifen können (OOP, u know!?). Aber warum sparsam mit dem Speicher umgehen wenn man doch so schön sinnlos welchen durch Verwendung globaler Variablen verschwenden kann?
Ach ja. Weil man anderen gerne vorschreibt sie sollen doch bitte schön sparsam mit dem Speicher umgehen:

I am sure that many developers will say that these results are not important, but considering that most of the WordPress users are on shared hosting with limited memory and resources available to them, this is most important thing to have plugins they need and still have server running fine.

Also Wasser predigen und Wein saufen. Contactform 7 bekommt übrigens nur eine schwache 2, dafür aber eine extra Erwähnung:

All tested plugins, but one, used the internal WordPress AJAX handling. Contact Form 7 uses own handler and that is not something I can recommend. Using WP handler is best solution considering that it is already written with security concerns in mind and it is very easy to use, making plugin fit better with WP development concepts.

Muss ich extra erwähnen das GD Unit Converter seinen eigenen Caching-Mechanismus mitbringt und mal ganz elegant auf den in WordPress bereits eingebauten Caching-Mechanismus pfeift?
Natürlich darf auch der eigene Logger nicht fehlen, der zwar nicht genutzt wird aber dennoch geladen werden muss (require_once). Über solch lustige Konstrukte wie folgenden wundert man sich dann schon gar nicht mehr.

$js_url = defined("SCRIPT_DEBUG") && SCRIPT_DEBUG ? "js/src/unit-converter.js" : "js/unit-converter.js";

Wenn SCRIPT_DEBUG definiert ist, sollen die JavaScripte aus dem nicht vorhandenen Verzeichnis js/src/ geladen werden. Das gibt lustige Fehlermeldungen wenn man sein Blog im Debug-Modus startet. So lustig, das man das Plugin sofort deaktiviert.

Es ist einfach schlau daher zu reden und dann selber solch einen Mist zu veröffentlichen. Gefühlt die Hälfte des Codes die das Plugin umfasst ist sinnlos, wird nicht benötigt, verstößt gegen Coding Guidelines oder ist schlichtweg Speicherverschwendung. Hier sollte der Herr MilanN vielleicht selber noch mal Hand anlegen und das Plugin um fluffige 90% Code reduzieren bevor er ihm die Bestnote 5 verpasst. Ich habe mich vorhin mal eine Stunde lang hingesetzt und versucht das Plugin von Scratch (also ohne Vorlage) nachzubauen. Nach einer Stunde hatte ich bereits brauchbare Ergebnisse und kam mit einem Zehntel an Code aus. Der Speicherverbrauch dürfte noch sparsamer sein, da ich nicht total unnützes Zeug lade, sondern mich darauf beschränke das zu nutzen, was ich benötige.

Solche Tests die nicht klar machen wie eine Bewertung zu Stande kommt und bei denen der Autor sich die Testbedingungen so zurecht biegt das er sich selbst Bestnoten verpassen kann, kann man getrost außer Acht lassen. Hier muss sich jeder selber fragen wie objektiv der Test sein kann wenn die eigenen Plugins den Maßstab vorgeben. Da sollte man sich als Autor nicht wundern wenn andere einen auf den Zahn fühlen und zeigen wo der Mops die Locken hat.

Fazit

Gute Tests sind objektiv und vergleichen nicht eigene Arbeit mit der von Fremden. Wird die eigene Arbeit dennoch im Test mit einbezogen, dürfen die Testkriterien nicht auf die eigene Optimierung hin zugeschnitten sein.
Die Testkriterien sollten klar und verständlich sein. Was man als Leser nicht nachvollziehen kann, ist nichts wert. Ist es fraglich wie eine Bewertung zu Stande gekommen ist, ist der ganze Test wertlos. Moinka Thon-Soun hat auf Texto in einen Artikel beschrieben wie ein schlecht gemachter Test auf einen Laien wirkt. Nämlich verwirrend, sonst nichts.
Die Tests sollten nachprüfbar sein. Dazu müssen Testscripte zugänglich sein und die Testumgebung erläutert werden.
Test sollten nicht auf einen einzelnen Aspekt fokussiert sein. Jeder Test hat einen Schwerpunkt, dies rechtfertigt jedoch nicht eine schlechte Bewertung weil ein Testkandidat eben nicht genau den Schwerpunkt trifft. Ein guter Tests umfasst mehrere Aspekte und bildet aus den Einzelergebnissen eine Bewertung. Jedes Plugin hat seine Stärken und Schwächen. Ein Plugin das optisch gut gestylt daher kommt, verbraucht eben mehr Speicher (mehr Grafiken, mehr CSS, mehr Code) als ein Plugin welches sehr spartanisch gestaltet ist. Was nützt einem aber ein Plugin das am falschen Ende spart, wenn es durch seinen Purismus nur schwer bedienbar ist?
Tests sollten sich auf das beschränken, was unter anderen Systemen ähnliche (vergleichbare) Ergebnisse liefert. Eine systemunabhängiger Wert sind z.B. Fehlermeldungen (auch Notices und Deprecated Meldungen) . Die werden auf jeden System gleich sein, denn falsch ist hier wie da falsch.
Test sollten realitätsnah sein. Im Labor gelten andere Regeln als in der Wildnis. Selbst wenn ein Plugin im Test wunderbar abschneidet, kann es dadurch versagen das es andere Plugins behindert oder gar komplett ausschaltet. Man kann nicht alle Kombinationen von Plugins prüfen, jedoch gibt es eine Reihe von Regeln für ein friedliches Miteinander die man beachten sollte.

Also bitte nicht jeden Test blauäugig Glauben schenken. Lieber einmal mehr als einmal zu wenig an den Ergebnissen zweifeln. Wir wissen doch alle: Die Statistik die man selber gefälscht hat, ist immer noch die beste

Dazu filtern wir das Array mit den sortierbaren Spalten und fügen den Spalten-Schlüssel ‘posts‘ hinzu. Den Spalten-Schlüssel finden wir in den Core-Dateien, genauer gesagt in der Klasse WP_Users_List_Table (wp-admin/includes/class-wp-list-users-table.php; Zeile 160 – 174) (direkt da drunter finden wir dann übrigens auch gleich die sortierbaren Spalten).
Der Name des benötigten Filters setzt sich aus einem Muster und den Screennamen zusammen: manage_xxx_sortable_columns. xxx ist dabei durch den Screennamen zu ersetzen. Dies funktioniert auch mit anderen Seiten im Backend, sofern dort eine Tabelle mit WP_List_Table erstellt wurde. Dazu ein anderes mal mehr.

Der Wert für den entsprechenden Eintrag im Array kann entweder ein String oder ein Array sein. Übergibt man lediglich einen String, so legt man nur fest wonach sortiert werden soll. In diesen Fall wird dann die Standardsortierung asc (Ascending = Aufsteigend) verwendet. Möchte man eine absteigende Reihenfolge (desc = Descending = Absteigend), so muss man anstatt eines String ein Array übergeben. Der erste Wert im Array ist dabei der Schlüssel nach dem sortiert werden soll und der zweite Wert die Reihenfolge (asc/desc).
In unseren Fall ist es ganz sinnvoll absteigend zu sortieren damit die Benutzer mit den meisten Beiträge als erstes aufgelistet werden. Wir übergeben also ein Array. Da wir nach Anzahl der Beiträge sortieren wollen, ist der erste Wert demnach ‘post_count‘ und der zweite Wert ‘desc‘.

Das modifizierte Array mit return zurück geben und schon sind wir fertig. Im großen und Ganzen ist das alles eine recht interessante Sache da man auch Spalten hinzufügen bzw. entfernen kann. Dieser Code-Schnipsel ist lediglich ein kleiner Einstieg, ich werde demnächst noch etwas zu den Thema “Spalten in Tabellen” schreiben. Hier noch das komplette Plugin (wer es nicht als Plugin haben will, kopiert sich den Filter und die Funktion in die functions.php. Mit PHP5.3 ist das übrigens alles sehr kompakt und ein schöner Fall für eine anonyme Funktion).

<?php
/*
Plugin Name: Sortable post column
Description: Make posts column on users screen sortable
Version: 0.0.1
Author: Ralf Albert
Author URI: http://yoda.neun12.de 
*/

// make posts-column sortable
add_filter( 'manage_users_sortable_columns', 'register_user_post_column_sortable' );

function register_user_post_column_sortable( $columns ){
	$columns['posts'] = array( 'post_count', 'desc' );
	return $columns;
}

/* PHP5.3 style */
/*
add_filter( 'manage_users_sortable_columns', 
	function( $columns ){		
		$columns['posts'] = array( 'post_count', 'desc' );
		
		return $columns;
	}
);
*/

In poEdit muss man einen neuen Parser anlegen (Datei -> Einstellungen -> Parser):

• Sprache: XML
• Durch Semikola getrennte Liste der Dateiendungen (z.B. .cpp;.h): *.xml
• Parser Befehl: xgettext --force-po -o %o %C %K %F -L glade
• Ein Eintrag in der Schlüsselwortliste: -k%k
• Ein Eintrag in der Eingabedatei-Liste: %f
• Zeichensatz des Quellcodes: --from-code=%c

Erzeugt man nun einen neuen Katalog, so fügt man in den Katalogoptionen unter Schlüsselwörter noch ein zusätzliches Schlüsselwort ein. Diesen kann man relativ frei wählen, ich habe mich hier für translate entschieden.
In der XML-Datei muss man nun noch die zu übersetzenden Zeichenketten mit seinen gewählten Schlüsselwort umschließen:

<root>
  <title><translate>My headline</translate></title>
  <text><translate>This is the text</translate></text>
  <options>
   <font>strong</font>
   <color>black</color>
  </options>
</root>

poEdit ist nun in der Lage die in der XML-Datei mit translate gekennzeichneten Zeichenketten zu übersetzen.

Unter Windows kann es vorkommen das man noch eine Fehlermeldung erhält das glade und/oder expat nicht unterstützt werden. Das liegt an der mit poEdit ausgelieferten Version von gettext. In diesen Fall sollte man sich das vom gnuwin32 Projekt bereit gestellte gettext-Paket runterladen.
Die in dem Paket enthaltenen Dateien kopiert man sich dann in poedit/bin/ (vorher das Verzeichnis sichern). In einigen Quellen wird angegeben das man lediglich die gettext.exe kopieren muss, andere sagen man kopiert sich die gettext.exe, startet sie und schaut welche Abhängigkeiten/Bibliotheken (.dll Dateien) noch fehlen. Ich habe einfach das komplette Paket kopiert (WinXP / Win7) und es funktioniert einwandfrei.

Die genaue Konfiguration der Editor-Klasse soll aber nicht Gegenstand des Beitrages sein. Denn beim Testen der neuen Editor-Klasse bin ich auf ein ganz anderes Problem gestoßen zu dem ich hier ein paar Worte schreiben will.

Mein Wunsch war es nämlich, den Editor in einer Thickbox zu öffnen, dazu sollte der Editor mittels einem Ajax-Request in die Thickbox geladen werden. Was auf den ersten Blick recht simple erscheint, birgt ein paar Stolperfallen in sich. Denn der alleinige Aufruf von wp_editor() erzeugt zwar das benötigte HTML, jedoch nicht die ebenfalls benötigten JavaScripte.

Die Ausgangssituation ist folgende: Ich habe für den TinyMCE ein Plugin welches eine Thickbox öffnet und den Inhalt der Datei editor_popup.php in die Thickbox lädt. Die Datei editor_popup.php hat anfangs folgenden schlichten Inhalt:

<?php
// get wp-load
$abspath = isset( $_GET['abspath'] ) ? $_GET['abspath'] : '';
if( '' != $abspath )
	require_once $abspath.'/wp-load.php';
else
	die('No abspath submitted!');
?>
<!DOCTYPE html>

<html>
	<head>
		<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
		<title>Thickbox test</title>
	</head>

	<body>

		<div id="editorwrapper">
			<form action="display.php" method="get" target="_blank">
<?php
	wp_editor( '<p>Some more content</p>', 'editortest' );
?>
				<input type="submit" value="Submit" />
			</form>
		</div>

	</body>
</html>

Den ABSPATH übergebe ich als GET-Request, somit ist es ein Leichtes wp-load.php einzubinden um an die WordPress-Funktionen zu gelangen. Der Rest ist ein bisschen HTML und der Aufruf der Funktion wp_editor().
Dies führte jedoch zu keinem Ergebnis, denn es fehlt so ziemlich alles an JavaScript was benötigt wird damit der Editor überhaupt betriebsbereit ist.

Schaut man sich die Klasse WP_Editor einmal etwas genauer an, so findet man zwei Methoden die das Einbinden und die Ausgabe des benötigten JavaScriptes übernehmen. Dies sind zum einen enqueue_scripts() und editor_js(). Diese Methoden übernehmen die Ausgabe bzw. das Einreihen des benötigten JavaScriptes und werden in den Hooks ‘admin_print_footer_scripts‘ / ‘wp_print_footer_scripts‘ bzw. ‘admin_footer‘ und ‘wp_footer‘ eingehakt.
Da wir in unserer Testseite weder den einen noch den anderen Hook automatisch ausführen, müssen wir dies von Hand machen. Dazu fügen wir einfach vor dem schließenden </body> ein <?php do_action( 'wp_footer' ); ?> ein. Um noch das passende Loook&Feel von WordPress zu bekommen, nutzen wir das Admin-CSS und optional noch z.B. das Stylesheet ‘colors-fresh‘ um ein paar Buttons zu stylen.

<?php
add_filter( 'show_admin_bar', '__return_false' );

$styles = array( 'wp-admin', 'colors-fresh'  );
wp_print_styles( $styles );
?>

Dieser Code kommt vor dem schließenden </head>. Nebenbei habe ich noch die Admin-Bar entfernt, da diese in einem kleinen Popup eher suboptimal dargestellt wird und obendrein eher nutzlos ist.

Et voilá! Da ist der funktionierende Editor. Und hier noch einmal das komplette Script zusammen:

<?php
// get wp-load
$abspath = isset( $_GET['abspath'] ) ? $_GET['abspath'] : '';
if( '' != $abspath )
	require_once $abspath.'/wp-load.php';
else
	die('No abspath submitted!');
?>
<!DOCTYPE html>

<html>
	<head>
		<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
		<title>Thickbox test</title>

<?php
add_filter( 'show_admin_bar', '__return_false' );

$styles = array( 'wp-admin', 'colors-fresh'  );
wp_print_styles( $styles );
?>
	</head>

	<body>

		<div id="editorwrapper">
			<form action="display.php" method="get" target="_blank">
<?php
wp_editor( '<p>Some content</p>', 'editortest' );  //, $settings );
?>
				<input type="submit" value="Submit" />
			</form>
		</div>
<?php
do_action( 'wp_footer' );
?>
	</body>
</html>

Wenn wir dieses Script nun in der Datei wp-content/plugins/editor_popup.php abspeichern, dann können wir sie z.B. mit http://example.com/wp-content/plugins/editor_popup.php?abspath=c:/htdocs/wordpress in einem Ajax-Request aufrufen und z.B. in einer Thickbox darstellen.

Wie man dann den Editor an seine Bedürfnisse anpasst, ist genug Stoff für einen eigenen Artikel. Ich hoffe dem einen oder anderen schon vor Erscheinen von WordPress 3.3 eine kleine Hilfe gegeben zu haben wie man solch ein Problem lösen kann.