Zum Glück ist das Programmieren nicht meine Lebensgrundlage, ansonsten wäre ich einige Monate lang berufsunfähig gewesen. So konnte ich mir den Luxus einer langen Auszeit gönnen und habe mich rein gar nicht mehr mit WordPress, PHP oder verwandten Themen befasst.
Andere Dinge rückten in den Mittelpunkt und das war gut so. Ich habe den nötigen Abstand gewonnen um wieder klar denken zu können. Den nötigen Abstand um Projekte, die ich begonnen hatte, wieder mit der nötigen Distanz und Kritikfähigkeit betrachten zu können. Abstand der es mir ermöglichte Wichtiges von Unwichtigen zu trennen.

Bei vielen reicht dafür ein Urlaub. Urlaub bedeutet bei mir jedoch oftmals Zeit zum Coden. Und das war dann wohl auch der Fehler den ich gemacht hatte, weswegen meine Auszeit etwas länger ausfiel.
Dadurch das ich mir Zeit für mich selber und andere Dinge genommen hatte – eher nehmen musste – konnte ich den Akku wieder aufladen. Jetzt macht mir das Coden wieder Spaß, die Zeilen flutschen nur so auf den Bildschirm und ich verbeisse mich nicht mehr an unwichtigen Details.
Viele Projekte habe ich auf Eis gelegt oder gleich ganz aufgegeben, ansonsten hätte ich das Coden wahrscheinlich aus lauter Frust komplett an den Nagel gehängt.
Zu den jetzigen Neuanfang gehört auch ein kleines Plugin, welches ich ohne durch Altlasten aufgehalten zu werden, in den letzten vier Tagen umgesetzt habe.

Entstanden ist das Plugin durch die Beschäftigung mit Menschen die es schon als große Leistung ansehen Facebook zu starten. Denn es kann durchaus hinderlich sein wenn man ständig von Menschen umgeben ist die sich auskennen. Man verliert sehr schnell den Blick dafür was diejenigen benötigen (könnten), die sich weniger bis gar nicht auskennen. Raus aus den Elefenbeinturm ist hier die Devise gewesen.
Und so ist in den letzten Tagen Password Change Reminder (PwCR) entstanden. Bei einer schnellen Recherche konnte ich kein Plugin finden welches den Benutzer daran erinnert regelmäßig sein Passwort zu ändern. PwCR macht genau das. Nicht mehr und nicht weniger.
Das Plugin ist, wie so häufig bei mir, in einem sehr früher Stadium. Da können noch ein paar Fehler dabei sein, die (englischen) Texte sind alle noch etwas schief, Übersetzungsarbeit ist zu leisten und natürlich Dokumentation. Genaueres zu dem Plugin werde ich in eine  seperaten Artikel schreiben. Bis dahin kann jeder der möchte es schon mal ausprobieren.

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.

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

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.

Meistens ist ein Aufruf a lá http://www.example.com/wp-content/plugins/a-plugin/conection_data.php eher harmlos, da versucht wird das Script auszuführen anstatt es anzuzeigen. Nicht zuletzt bleibt aber jedoch die Möglichkeit via include(_once) und require(_once) das Script auch von entfernten Servern aus einzubinden und auszuführen.
Wie dem auch sei, ein mulmiges Gefühl bleibt immer zurück wenn jeder auf alle möglichen Dateien einfach per Browser oder PHP-Funktion zugreifen kann. Daher ist es bereits jetzt Best Practice seine Scripte und Dateien mit einer Kontrolle vor solch ungewollten Zugriffe zu schützen.

In vielen Plugins sieht man solchen und vergleichbaren Code

<?php 
  if ( ! defined( 'My_PLUGIN_VAR' ) ) 
    die( 'No direct script access allowed' );
?>

In der Plugin-Datei wird eine Konstante definiert (MY_PLUGIN_VAR) und in allen anderen Dateien wird abgefragt ob diese Konstante definiert ist. Ist sie es nicht, wurde womöglich direkt auf diese Datei zugegriffen was unerwünscht ist. Es gibt hier verschiedene Techniken diese Kontrolle durchzuführen.
Und die Plugin-Datei selber will ja auch noch davor geschützt sein direkt aufgerufen zu werden:

<?php 
  if ( ! function_exists( 'add_action' ) ) 
    die( 'No direct script access allowed' );
?>

Falls die Funktion add_action nicht definiert wurde, was darauf schließen lässt das WordPress nicht gestartet wurde, kann man von einem direkten Zugriff auf die Plugin-Datei ausgehen. Auch hier gibt es verschiedene Wege um zu prüfen ob WordPress bereits gestartet wurde oder nicht.

Das ist alles schön und gut, aber auch aufwendig und fehleranfällig. Stellen wir uns mal ein Plugin mit mehreren Unterverzeichnissen und in jedem Unterverzeichnis wiederum mehreren Dateien vor. Arbeitet man alleine an dem Plugin, ist es schon schwer den Überblick zu behalten ob man wirklich jede Datei geschützt hat. Bei einem Projekt an denen mehrere Personen mitarbeiten ist die Gefahr um so größer das einer der Mitarbeiter vergisst einen entsprechenden Schutz einzubauen. Und so wie Murphy es will, ist es ausgerechnet die Datei, mit den größten Schwachstellen die niemand kontrolliert hat.
Hinzu kommt das man mit diesen Techniken unter Umständen nicht jede Datei schützen kann. In JavaScript-Dateien wird es schon schwer mit diesen Techniken einen unerwünschten Zugriff zu verhindern. Spätestens bei CSS-Dateien müsste man gänzlich aufgeben.

Besser wäre es wenn man zentral regeln könnte auf welche Dateien zugegriffen werden darf und welche nicht. Der Apache Webserver bietet uns solch eine Möglichkeit in Form von .htaccess. Dazu benötigen wir im Grunde genommen nur zwei Regeln. Eine die die erlaubten Zugriffe beinhaltet und eine die die unerlaubten Zugriffe beinhaltet.

<FilesMatch "\.(php|xml)$">
    Order allow,deny
    Deny from all
</FilesMatch>

<FilesMatch "(\.txt|\.htm?l|index\.php)$">
  Order allow,deny
  Allow from all
</FilesMatch>

Im ersten Block verbieten wir sämtliche Zugriffe auf alle PHP- und XML-Dateien. Die Liste kann man noch um weitere Dateitypen erweitern, je nach Bedarf. Da wir aber nicht alle Zugriffe grundsätzlich sperren wollen, heisst ja readme.txt und nicht readme_not.txt, erlauben wir im zweiten Block den Zugriff auf bestimmte Dateitypen (.txt und .htm[l]), sowie auf die index.php. Auch hier kann man je nach Bedarf bestimmte Dateitypen und Dateien hinzufügen bzw. entfernen.
Das Beste an der Sache ist aber, es wirkt sich auch auf alle Unterverzeichnisse aus, wir müssen uns also keine Gedanken darüber machen ob nicht zufällig die eine Datei, die die Schwachstelle im System darstellt, nicht geschützt ist.

Wo viel Licht ist, ist natürlich auch viel Schatten. Denn auf anderen Webservern als den Apache (z.B. lighttpd, IIS, usw.) funktioniert das natürlich nicht. Entweder man legt für jeden Webserver dann entsprechende Konfigurations-Dateien an, sofern möglich, prüft auf die Server-Software und verweigert den Dienst oder nutzt diese Technik nur zusätzlich um auf Nummer sicher zu gehen.

Blick über den Tellerrand

Für mich ist das keine provokante These mehr, sondern ignorieren der Realität. Schauen wir uns doch einfach mal ein paar Berufe an in denen es die reine Selbstverständlichkeit ist das man “kostenlos” arbeitet.
Da hätten wir zum Beispiel die Architekten. Bei größeren Projekten werden gerne so genannte “Wettbewerbe” ausgeschrieben. Um an den Wettbewerb teilnehmen zu dürfen, müssen die Architekten einen kompletten Entwurf inkl. Modell abliefern. In seltenen Fällen bekommen die zweit- und drittplatzierten noch ein kleines Honorar für ihre Arbeit. Alle anderen hingegen gehen leer aus. Das sind einige hundert Arbeitsstunden die Architekten unbezahlt leisten um an einen Auftrag zu kommen. Und dies vollkommen selbstverständlich und ohne großes Murren.
Bleiben wir in der Baubranche, denn es geht auch eine Nummer kleiner. In der Baubranche werden Aufträge normalerweise ausgeschrieben. Es gibt ein Leistungsverzeichnis das der Bewerber mit Preisen auszufüllen hat. Derjenige der die entsprechende Eignung hat und den günstigsten Preis abliefert bekommt den Zuschlag. Alle anderen gehen leer aus. Die Abgabe eines Angebotes wird in keinster Weise vergütet. Dabei ist so ein Leistungsverzeichnis je nach Größe des Projektes zwischen 10 und mehreren tausend Seiten stark. Selbst wenn es nur wenige Positionen umfasst, verbringt man als Unternehmer etliche Stunden damit Preise zu kalkulieren, Preise für Materialen anzufordern und Angebote zu schreiben. Im Laufe eines Jahres kommen so auch etliche hunderte Stunden zusammen die in keinster Weise bezahlt werden.
Aber natürlich gibt es auch Arbeiten die für uns mittlerweile so selbstverständlich sind, dass wir sie schon gar nicht mehr als solche erkennen. Ich kenne keine Metzgerei in der halbe Schweine oder ganze Kühe auf dem Tresen landen und wo ich mir das Kotelette selber raus schneiden muss. Auch im Supermarkt stehen keine Kühe an denen ich mir die Milch selber zapfen muss. Metzger und Supermarkt müssen Waren einkaufen, sie lagern, transportieren, in Regale und Theken einräumen und wenn sie nicht verkauft werden, wieder ausräumen und entsorgen. Dabei ist der Arbeitsaufwand manchmal noch nicht einmal das große Problem, sondern der Wareneinsatz. Denn für nicht verkaufte Ware bekommen weder Metzger noch Supermarkt von irgendjemanden Geld. Das sind Verluste die der Unternehmer selber zu tragen hat. So etwas fällt unter den Begriff Unternehmerisches Risiko.

Kostenlos ist nicht umsonst

So gesehen sind digitale Unternehmer, wie z.B. Texter, wirklich gut dran. Denn sie investieren lediglich etwas Zeit und haben so gut wie keinen Wareneinsatz. Die Verluste sind also überschaubar. Verluste, sei es durch unverkäufliche Ware oder nicht bezahlte Arbeit, gehören zum Geschäftsalltag unabwendbar hinzu. Das ist nun einmal das Risiko das man als Unternehmer eingeht und das den selbstständigen Unternehmer vom Angestellten, der normalerweise seine komplette Zeit bezahlt bekommt, unterscheidet. Die Frage kann also nicht sein wie man unbezahlte Arbeit vermeidet, sondern wie man Risiken, die das Geschäftsleben mit sich bringt, kalkuliert und wie man mit ihnen umgeht.
Probearbeiten und Referenzen sind Teil des Grundkapitals. Eine Tatsache die viele Jungunternehmer entweder gar nicht begreifen oder schlichtweg ignorieren. So wie man ein Startkapital in Form von Finanzen und eine Grundausstattung in Form von Hard- und Software, Büroausstattung, usw. benötigt, benötigt man ebenso Schaustücke die man dem Kunden präsentieren kann.
Im besten Fall sind es Referenzen die man vorzeigen kann. Denn bei Referenzen handelt es sich in der Regel um Projekte für die man bereits Geld bekommen hat, die Schaustücke sind also bereits bezahlt. Allerdings stellt sich hier die Frage wie man an Referenzen kommen soll. Denn auch eine Referenz ist ja schließlich ein Auftrag der erst einmal erteilt und durchgeführt werden will.
Wenn man also (noch) keine Referenzen hat, dann muss man entweder Zeit in Schaustücke investieren oder mit (kostenlosen) Probearbeiten den Kunden überzeugen.

Investition in die Zukunft

Für Programmierer wäre es z.B. eine Möglichkeit Open Source Software zu veröffentlichen. Texter hätten z.B. die Möglichkeit über einen Blog ihre Fähigkeiten und Talente zu präsentieren. Webdesigner können z.B. für gemeinnützige Vereine Webseiten erstellen, usw. Dies alles ist zwar erst einmal “unbezahlte” Arbeit, jedoch sollte man es als Investition betrachten die sich vielleicht erst viele Jahre später auszahlt. Denn im Grunde genommen geht es doch darum sich einen Namen zu machen und sich zu präsentieren. Da ist es wahrscheinlich sehr suboptimal wenn die Open Source Software “Pimpernelli – Das lustige Puffspiel” heißt, der Blog nur so vor bissigen und sarkastischen Beiträgen strotzt, die “gemeinnützige Organisation” für die man Webseiten erstellt sich als Webseite mit sehr vielen nackten Frauenkörpern heraus stellt.
Hier bewahrheitet sich der Grundsatz privates und geschäftliches tunlichst voneinander zu trennen. Es gibt sicherlich den einen oder anderen bei dem der Mix aus Privat und Geschäftlich funktioniert weil er privat genauso professionell ist wie geschäftlich. Wer aber gerne mal seine Meinung sagen möchte, sollte beides trennen. Denn im Geschäftsleben hat die eigene Meinung nur sehr geringen Stellenwert.

Hat man erst einmal ordentlich Zeit in Referenzen und andere Arbeiten investiert, hat man sich also einen Namen gemacht und kann was vorzeigen, kann man langsam mal dazu übergehen etwas zu verlangen. Wenn dem Kunden die bisherigen Referenzen nicht ausreichen und er eine speziell auf sich zugeschnittene Probearbeit sehen will, so sollte man sich diese Arbeit auch bezahlen lassen. Dabei sollte man aber nicht zu gierig sein, auch hier geht man ein gewisses unternehmerisches Risiko ein. Zu hohe Preise verscheuchen die potentiellen Kunden, zu niedrige Preise erhöhen die Verluste.
Ein Kostenvoranschlag für eine Reparatur kostet in einer Autowerkstatt oft so um die 30 Euro. Damit deckt die Werkstatt aber in den seltensten Fällen alle tatsächlich angefallenen Kosten. Diese liegen meistens um das zwei- bis dreifache darüber. Den Fehlbetrag holen sich die Werkstätten jedoch bei einem späteren Reparaturauftrag über die Preise für die einzelnen Positionen wieder rein. Das der Kostenvoranschlag, respektive die bezahlte Probearbeit, einen Nebeneffekt hat, ist mehr gewollt als Zufall. Denn welcher Kunde holt sich 5, 10 oder mehr Kostenvoranschläge rein wenn er die alle bezahlen muss? Und zudem setzt hier ein psychologischer Effekt ein. Wenn der Kunde eh schon etwas gezahlt hat, dann ist er eher bereit den Auftrag zu vergeben wenn er die Kosten mit dem Auftrag verrechnet bekommt. So hat der Kunde zumindest nicht den Eindruck er hätte Geld verschenkt.

Die falsche Kundschaft

Ich sehe schon wie viele sich jetzt sagen “Aber meine Kunden würden niemals für eine Probearbeit bezahlen…“. Gut, dann sage ich: Du hast die falschen Kunden.
Kunden die bereits an diesen Punkt zu geizig sind die Probearbeit zu bezahlen, machen oft auch bei der Endabrechnung Schwierigkeiten. Man tut sich demnach also kein Gefallen damit monatelang für potentielle Kunden Arbeiten zu erstellen die dann am Ende ohnehin nicht in einem Auftrag enden oder, wenn es doch zu einem Auftrag kommt, endlose Diskussionen über Preise und Leistungen nach sich ziehen. Denn auch der Kampf um das wohlverdiente Geld ist kostenlose Arbeit die nicht bezahlt wird!

Gefragt ist also ein gutes Risikomanagement. Man muss sich bei jeden Kunden aufs Neue fragen wie viel Zeit und damit Geld man in diesen Kunden investieren will. Und wie hoch man das Risiko einschätzt das diese Zeit und damit das Geld verloren gehen kann.
Ich habe oft genug für Kunden stundenlang umsonst gearbeitet, erst vor kurzem war es eine Position von ungefähr 20 Stunden. Dabei hatte ich die ersten 10 Stunden selber zu verschulden weil ich die Situation falsch eingeschätzt hatte. Die Frage ob ich weiterhin Zeit (und Geld) in diesen Kunden investieren will, beantwortete ich für mich mit Ja. Denn zum einen wollte ich den Kunden halten, zum anderen sah ich keine größeren Probleme für zukünftige Aufträge und Zusammenarbeit. Diese 20 Stunden die ich bisher “umsonst” gearbeitet habe, sehe ich also nicht als Verlust, sondern als Investition an. Ich konnte dem Kunden so eine Arbeit präsentieren die ihn qualitativ überzeugte und ihn durch diesen “kostenlosen” Einsatz von der Leistungsbereitschaft überzeugen. Es ist also eine Investition die man nicht in Heller und Pfennig aufrechnen kann, genauso wenig wie man einen guten Ruf in Euro und Cent umrechnen kann.
Natürlich besteht ein gewisses Risiko das keine weiteren Aufträge kommen oder das sich die spätere Zusammenarbeit sehr schwierig gestaltet. Aber dieses Risiko habe ich als sehr niedrig eingeschätzt.
Es gab aber natürlich auch schon die krassen Gegensätze. Kunden die ich bei den kleinsten Schwierigkeiten habe fallen lassen oder die ich erst gar nicht angenommen habe. Dies ist eine Sache von Bauchgefühl und Erfahrung. Denn aus der wirtschaftlichen Sicht heraus muss man es so sehen: Eine Probearbeit ist eine überschaubare Sache. Ich weiß ich werde x Stunden, oder umgerechnet y Euro, in die Probearbeit investieren. Das Verlustrisiko steht im schlimmsten Fall bei 50%. Entweder man bekommt den Auftrag oder nicht. Dieses Risiko kann man oft genug noch weiter minimieren indem man sich z.B. die Arbeit teilweise bezahlen lässt. Hierdurch steigen die Chancen den Auftrag zu bekommen und das Verlustrisiko sinkt.
Ärger bei der Abrechnung oder bei der Durchführung ist ein unkalkulierbares Risiko. Weder weiß man welche Leistungen noch zusätzlich kommen (meistens sind es dann Sachen die der Kunde in einem Nebensatz nachts um 3 am Telefon erwähnt hat und bei denen der Kunde sich 100%ig sicher ist das dies von Anfang an vereinbart war), man weiß nicht ob und wann das Geld kommt und ob man um die Bezahlung der Position x kämpfen muss. Und vor allem weiß man nicht ob nach so einem Theater noch Folgeaufträge kommen oder ob man überhaupt noch mal Lust hat für diesen Kunden zu arbeiten. Schwierige Kunden sind für mich immer ein 80-100%iges Verlustrisiko. Denn die Zeit die man sich mit ihnen rum ärgert bezahlt einen niemand.

Fazit

Probearbeiten und Referenzen gehören zum Geschäftsleben dazu und man kommt um sie nicht herum. Sie sind aber keine Plage die unvorhergesehen über einen herein bricht, sondern in erster Linie eine Investition mit einem gewissen Verlustrisiko. Und selbst dieses Verlustrisiko ist mit etwas Erfahrung überschau- und berechenbar.
Wer ständig mit kostenlosen Probearbeiten konfrontiert wird und häufiger keine Aufträge daraus generieren kann, muss die Verluste auf seine Preise umlegen. Das macht der Metzger genauso wie der Architekt. Nicht umsonst sind die Besten oft die teuersten. Denn sie haben bereits ihr Lehrgeld bezahlt und fahren jetzt die Zinsen ein.
Wenn man jedoch ständig nur zur Probe arbeitet und durch Umlage die Preise in exorbitante Höhe steigen, dann liegt das aller Wahrscheinlichkeit nicht am System, sondern an anderen Faktor. In solch einem Fall sollte man sich fragen ob z.B. die eigene Qualität stimmt oder ob man vielleicht in einem Marktsegment tätig ist das vollkommen überlaufen ist. Unter Umständen hat man aber auch eine Nische besetzt die nicht so ertragreich ist wie man sich erhofft hat.

Im Grunde genommen ist die Grundaussage des Textes, dass man nicht für umsonst arbeiten könne, richtig. Ich denke und hoffe das dies auch niemand macht. Auf der anderen Seite sind Probearbeiten und Referenzen wirklich nichts mit dem man niemals im Berufsleben hätte rechnen können. Dies trifft nicht nur auf Kreative und Webworker zu, sondern auf so ziemlich jeden herstellenden Beruf.
Nehmen wir einmal den Metzger aus Daniela Warndorfs ersten Beispiel. Probieren geht über studieren, dass wussten Metzger und Wurstfachverkaufskräfte schon bevor es Internet gab. Wer kennt es nicht, dass kleine Stückchen Fleischwurst das über die Theke gereicht wird. Oder die kleinen Probierhappen, die oft in jeder guten Metzgerei auf dem Tresen ausliegen. Warndorfs Beispiel ist völlig daneben gegriffen. Zum einen gibt es Proben beim Metzger, zum andern ist ein Steak nicht mit einem Text oder einem anderen digitalen Produkt vergleichbar. Schneidet man von einem Steak ein Stück ab damit der Kunde es probieren kann, ist das Steak irgendwann weg. Einen Text oder ein digitales Produkt wie z.B. ein Stück PHP-Code kann man unendlich oft kopieren und verteilen ohne das seine Qualität leidet oder das es weniger wird. Der Vergleich Texter mit Metzger hinkt also nicht nur, er ist schlichtweg falsch.

Ihr nächstes Beispiel ist da schon etwas besser. Die “kostenlose” Reparatur im Autohaus. Sicherlich erhofft sich der eine oder andere Kunde das quasi als Serviceleistung kleinere Mängel gleich mit abgestellt werden. Die Werkstätten haben jedoch schon vor langer Zeit die Situation erkannt und entsprechend gehandelt. Kostenvoranschläge nur gegen Bezahlung und jede Reparatur wird in Rechnung gestellt. Es tat zwar weh als ich mal für den Austausch einer Sicherung im Wert von 75 Cent 20 Euro bezahlt habe, es war aber gerechtfertigt. Denn bezahlt habe ich nicht die Sicherung, die gab es gratis. Bezahlt habe ich den Zeitaufwand der Werkstatt.

Warndorfs letztes Beispiel ist leider wieder völlig daneben. Denn auch die Milch verbraucht sich, genauso wie ein Steak. Und tatsächlich ist es, juristisch gesehen, das Risiko des Supermarktes die Waren zur Selbstbedienung im Regal anzubieten. Alternativ könnten sie, wie im guten alten Tante Emma-Laden, die Waren in einem Lager deponieren und dem Kunden nur die Waren aushändigen, die er kaufen möchte. Es ist also, wie man als Programmierer sagen würde, ein Designfehler des Supermarktes.

Warenproben, Probearbeiten und Referenzen gehören zum Berufsalltag genauso dazu wie Kunden die Aufträge geben. Ich denke Daniela Warndorf wird sicherlich auch schon mal eine Probefahrt mit dem Auto gemacht haben das sie kaufen wollte. Ich gehe aber nicht davon aus das sie dem Verkäufer deswegen gleich mal 30 Euro für Sprit und Abnutzung des Autos gezahlt hat. Oder? Und wer kennt sie nicht, Kunden die sich im Fachmarkt beraten lassen und dann billig im Internet bestellen?
Natürlich will man ein Produkt erst einmal testen bevor man es kauft. Kann man dies nicht, weil es sich z.B. um ein Steak oder ein Liter Milch handelt, will man als Kunde Referenzen sehen. Also z.B. andere Kunden die mit diesen Produkt zufrieden waren.

Wie eingangs erwähnt, höre oder lese ich immer wieder vor allem von Selbstständigen das sie vollends darüber frustriert sind wenn sie “kostenlos” arbeiten sollen. Dabei drängt sich der Ausspruch “Wasser predigen – Wein saufen” jedes mal aufs neue auf. Denn auf der einen Seite würden sie selber niemals etwas kaufen was sie nicht ausgiebig getestet haben oder was zumindest über ausreichend gute Referenzen verfügt. Auf der anderen Seite wollen sie ihre Produkte weder zum Testen noch irgendwelche Referenzen anbieten. Aus diesen Frust heraus werden dann haarsträubende Beispiele konstruiert die nicht einmal ansatzweise das Problem darstellen. Geschweige denn mal Lösungsansätze wie man mit dem Problem “kostenlose Arbeit” umgehen soll. Das dieses Problem immer wieder auftaucht, kann leider nicht abgestritten werden.

Auf das Problem “kostenlose Arbeiten” gehe ich in einen anderen Artikel mal näher ein, es würde ansonsten den Rahmen sprengen. Es ist jedoch immer wieder schade anzusehen wie hilflos, verzweifelt und unkreativ angeblich selbstständige mit solchen Problemstellungen umgehen. Das da meist nur Jammern übrig bleibt, ist mehr als bedauerlich.

Weniger ruhig geht es bei WordPress-Deutschland zu. Die verbuchten dieser Tage den 1 millionsten Download der DE-Version von WordPress. Alle Achtung, dass ist nicht gerade wenig.
Zu solch einem Jubiläum gibt es natürlich auch eine Kleinigkeit zu gewinnen. Einen USB-Stick mit 4GB Speicher, WP-Deutschland Gravur und Flaschenöffner. Ich hoffe ich muss nicht erwähnen das es mir bei der Teilnahme an dem Gewinnspiel weder um den 4GB USB-Stick noch um die Lasergravur geht, ich aber scharf auf den Flaschenöffner bin. Kann man immer gebaruchen, genauso wie ein funktionierendes WordPress.

Im Grunde genommen bedeutet hier aber, dass es nur auf den ersten Blick so einfach zu sein scheint. Wer sich schon mal mit den Thema Übersetzung von Plugins oder Themes beschäftigt hat, der wird früher oder später die vielen kleinen Haken zu spüren bekommen. Einer dieser kleinen Haken ist der, dass WordPress einen grundlegenden Unterschied bei der Einbindung von Übersetzungen macht. load_theme_textdomain() ist, wie der Name vermuten lässt, für Themes zuständig, während load_plugin_textdomain() für Plugins zuständig ist. Es ist schon mal auffällig das es für die gleiche Aufgabe zwei verschiedene Funktionen gibt. Also schauen wir doch mal in die Core-Datei wo der Unterschied bei diesen beiden Funktionen liegt.

Beide Funktionen finden wir in wp-includes/l10n.php. Beide Funktionen erwarten bei ihren Aufruf die Übergabe einer Domain und eines Pfades. Im Falle von load_plugin_textdomain() können sogar zwei verschiedenen Arten von Pfaden angegeben werden, wobei der absolute relative Pfad veraltet ist und nicht mehr verwendet werden sollte.
Bei genauerer Betrachtung fällt aber auf, dass load_theme_textdomain() bei der Pfadangabe deutlich toleranter ist als load_plugin_textdomain(). Ist kein Pafd angegeben, so verwendet load_theme_textdomain() das Verzeichnis des aktuellen Templates als Pfad. Ansonsten könnte man den Pfad auch sonstwohin zeigen lassen, es würde noch funktionieren.
load_plugin_textdomain() ist da etwas strikter. Egal ob man einen Pfad angibt oder nicht, es wird auf jeden Fall WP_PLUGIN_DIR, also der Pfad zum Plugin-Verzeichnis, im Pfad eingefügt.
Mit load_theme_textdomain() könnte man also auch eine Sprachdatei benutzen die in wp-content steht. Mit load_plugin_textdomain() wäre dies unmöglich.

Nun sind Pfadangaben in WordPress eine Sache für sich an die man sich gewöhnen und mit denen man umzugehen lernen kann. Deutlich mehr Kopfschmerzen bereitete mir in der Vergangenheit ein Umstand, den ich irgendwie nicht verstehe. Und zwar das Format nach dem die Sprachdateien benannt werden müssen.
load_theme_textdomain() erwartet das die Sprachdatei lediglich aus der Locale und der Endung .mo besteht. Also z.B. de_DE.mo oder en_EN.mo. load_plugin_textdomain() hingegen erwartet zu der Locale noch zusätzlich die Domaine als Teil des Dateinamens. Die Datei muss also das Format domain-locale.mo haben.
Für mich recht unverständlich und letzten Endes kann dies auch zu Problemen führen. Denn ändert sich im Plugin die Domaine, z.B. nach einem Update, dann können auch die (alten) Sprachdateien nicht mehr geladen werden. Man müsste also entweder alle Domainen im Plugin ändern oder alle Sprachdateien umbennenen.

Aber man sollte auch immer die Vorteile im Auge behalten. Durch die Verwendung der Domaine im Dateinamen der Sprachdatei kann man auf recht einfache Weise z.B. zwischen der Du- und der Sie-Form wechseln. Etwas was für deutsche Übersetzungen ja nicht ganz unerheblich ist.
Dazu legt man einfach z.B. eine Sprachdatei mit den Namen pluginname_du_form-de_DE.mo und eine mit den Dateinamen pluginname_sie_form-de_DE.mo an. Im Plugin selber kann man mittels define('MeinePluginDomain', 'plugin_xx_form'); eine Konstante definieren die dann in den Übersetzungsfunktionen verwendet wird (z.B. __('This example text', MeinePluginDomain)). Je nachdem ob xx nun ‘du’ oder ‘sie’ ist, schaltet man zwischen Du- und Sie-Form um.

Jetzt hat man aber ein Problem mit Sprachen die nicht zwischen Du und Sie unterscheiden. Mit Englisch zum Beispiel. Denn man müsste nun für jede Sprache zwei Sprachdateien anfertigen. Einmal plugin_du_form-en_EN.mo und einmal plugin_sie_form-en_EN.mo.
Das ganze gestaltet sich an diesen Punkt als etwas zu aufwendig um schön zu sein. Es gibt aber auch eine Lösung für das Problem. Wir benötigen ja eigentlich nur eine Funktion die in einem Verzeichnis nachschaut ob es eine Sprachdatei nach dem Format domaine-locale.mo gibt und diese lädt. Gibt es eine solche Sprachdatei nicht, wird halt eine Sprachdatei nach den Format locale.mo geladen. Gibt es diese auch nicht, wird halt nichts übersetzt.
Nebenbei erledigt sich mit solch einer Funktion das leidige Pfad-Problem. Die Sprachdateien können nun quasi an einen beliebigen Ort abgelegt werden. Ob dies Sinn macht, sei an dieser Stelle mal dahin gestellt.

Hier erst einmal die Funktion:

function flexible_loadtextdomain( $path = false, $domain = 'default' ){

  if( ! $path || ! is_dir( $path ) )

    return false;

  global $l10n;

  $local = get_locale();

  $mofile = $path . $domain . '-' . $local . '.mo';

  // try to find a matching translation

  // first try domain-locale.mo

    if( ! file_exists( $mofile ) ){

    // if not found, try only locale.mo

    $mofile = str_replace( $domain . '-', '', $mofile );

      if( ! file_exists( $mofile ) ){

        // if even this failed, throw an error or do something wired

        return false;

      }

    }

  load_textdomain( $domain, $mofile );

  return isset( $l10n[ $domain ] );

}

Die Funktion erwartet zwei Parameter. Zum einen eine Pfadangabe und zum anderen den Namen der Domain. Die erste If-Abfrage sorgt dafür das überhaupt ein Pfad übergeben wird und das es auch ein Verzeichnis ist. Anstatt einfach nur false zurück zu geben, kann man hier natürlich noch weitere Spielereien unter bringen indem man z.B. einen Pfad vorgibt (WP_PLUGIN_DIR oder get_template_directory).
Der Rest ist das was ich oben schon beschrieben habe. Erst domain-locale.mo suchen, wenn nicht gefunden locale.mo suchen, wenn das auch nicht gefunden irgendwas verrücktes machen, zum Beispiel false zurück geben.
In der letzten Zeile wird dann noch geprüft ob die Domain erfolgreich geladen wurde. Ab WP 3.0 kann man dies durch return load_textdomain(...) abkürzen. In älteren Versionen muss man diesen kleinen Umweg gehen da load_textdomain keine Erfolgsmeldung zurück gibt.

Der Code der Funktion ist ein wenig abgespeckt. Will man es ganz sauber programmieren, dann würde man noch ein paar Sachen anders machen, z.B. nicht $locale = get_locale(); verwenden, sondern $locale = apply_filters( 'xyz', get_locale(), $domain ); (xyz = theme_locale oder plugin_locale, je nachdem ob man die Funktion in einem Theme oder Plugin verwendet).

Vielleicht ist dieser Beitrag ja eine kleine Anregung für alle die Themes oder Plugins schreiben.

Der Codex schweigt sich allerdings ein wenig darüber aus wie man es hin bekommt den ersten Menüpunkt anders zu benennen. Anscheinend gibt es auch keinen “offiziellen” Weg um dies zu bewerkstelligen. Mit einen kleinen Kniff geht es dennoch.
Dazu muss man die Variable $submenu global verfügbar machen und kann dann darüber seine Menüpunkte beeinflussen:

global $submenu;
add_menu_page( $page_title, $menu_title, $capability, $menu_slug, [...] );
$submenu[$menu_slug][0][0] = 'My first Menuoption';

$submenu ist ein Array in dem verschiedene Informationen über das Menü gespeichert sind. Es lohnt sich dieses Array mal ausgeben zu lassen und zu schauen welche Informationen man darin findet.

In Bezug auf die Menüs ist $menu ein weiteres interessantes Array. Bei der Masse an Plugins die im Umlauf sind, kommt es nicht selten vor das auch dementsprechend viele Plugins ein zusätzliches Menü einrichten. Da möchte man vielleicht sein eigenes Menü ein wenig von den anderen abgrenzen. Nichts leichter als das, sogar mit Zusatzwert. Man fügt einfach einen Menü-Seperator ein:

global $menu;
$menu[] = array( '', 'read', '', '', 'wp-menu-separator' );

Damit wird ein Seperator eingefügt mit dem man die Menüleiste auf- und zuklappen kann. Steht der Code vor add_menu_page(), wird der Seperator vor dem eigenen Menü eingefügt. Steht er dahinter, wird der Seperator dementsprechend dahinter eingefügt.
Mit count($menü) lässt sich recht einfach feststellen wie viele Menüs bereits existieren und ggf. ein Seperator einfügen. Allerdings werden auch sämtliche bereits vorhandenen Seperatoren mitgezählt, dies sollte man beachten und diese ggf. raus rechnen.
Mit 'wp-menu-separator-last' erzeugt man übrigens einen “leeren” Seperator, also einen Seperator ohne Pfeil wie am Ende des Standard-Menüs von WordPress zu finden ist.