Der Normalfall sieht immer noch so aus, dass einfach abgefragt wird ob in $_GET, $_POST oder $_REQUEST ein Schlüssel vorhanden ist und dann der entsprechende Wert verwendet wird. Leider viel zu oft sieht man auch, dass erst gar nicht geprüft wird ob der Schlüssel vorhanden ist und einfach davon ausgegangen wird das dieser vorhanden ist und verwendet werden kann. Das ist nicht nur schlechter Stil, sondern eröffnet auch eine Sicherheitslücke. Denn die superglobalen Arrays $_GET, $_POST und $_REQUEST sind keine Einbahnstraße, man kann aus ihnen lesen und in sie hinein schreiben. Schauen wir uns das mal etwas näher an.

$_REQUEST lassen wir in der in diesem Artikel mal außen vor da es noch nicht von den Filter-Funktionen unterstützt wird. Zudem sollte man auf $_REQUEST auch nur in Ausnahmefällen zugreifen. $_REQUEST Enthält die Daten von $_GET und $_POST. Die Verwendung von $_REQUEST deutet also darauf hin, dass man nicht so wirklich weiß was man tut und einfach auf gut Glück auf ein superglobales Array zugreift in der Hoffnung die gesuchten Daten seien schon irgendwie da.
Es gibt einige wenige Fälle wo der Zugriff auf $_REQUEST sinnvoll sein kann, man sollte sich jedoch im klaren darüber sein das der Zugriff auf $_REQUEST eben nicht so sicher ist als wenn man $_GET und $_POST mit den Filter-Funktionen abfragt.

$_GET und $_POST sind keine Einbahnstraße

Das man auf die superglobalen Arrays $_GET und $_POST nicht nur lesend, sondern auch schreibend zugreifen kann, ist anscheinend nicht allen klar. Schauen wir uns dazu mal dieses Script an

$_POST['nonce'] = 'badnonce';
echo 'Was the nonce send with a POST request?<br>';
echo 'With <code>isset()</code>: ' . ( isset( $_POST['nonce'] ) ? 'yes' : 'no' ) . '<br>';
echo 'With <code>filter_has_var()</code>' . ( filter_has_var( INPUT_POST, 'nonce' ) ? 'yes' : 'no' ) . '<br>';
echo 'Value of <code>nonce</code> with <code>$_POST[\'nonce\']</code>: ' . $_POST['nonce'] . '<br>';
echo 'Value of <code>nonce</code> with <code>filter_input( INPUT_POST, \'nonce\' )</code>:' . filter_input( INPUT_POST, 'nonce' ) . '<br>';

echo '<hr>';

$_GET['nonce'] = 'badnonce';
echo 'Was the nonce send with a GET request?<br>';
echo 'With <code>isset()</code>: ' . ( isset( $_GET['nonce'] ) ? 'yes' : 'no' ) . '<br>';
echo 'With <code>filter_has_var()</code>' . ( filter_has_var( INPUT_GET, 'nonce' ) ? 'yes' : 'no' ) . '<br>';
echo 'Value of <code>nonce</code> with <code>$_GET[\'nonce\']</code>: ' . $_GET['nonce'] . '<br>';
echo 'Value of <code>nonce</code> with <code>filter_input( INPUT_GET, \'nonce\' )</code>:' . filter_input( INPUT_GET, 'nonce' ) . '<br>';

Die nonces sind in WordPress ein Sicherheitsmechanismus mit dem man prüfen kann ob eine Anfrage tatsächlich von dort kommt, von wo man sie erwartet. Verlassen wir uns darauf das der Schlüssel nonce vorhanden ist und verwenden diesen, gehen wir das Risiko ein das er an einer anderen Stelle einfach überschrieben wurde.

Das man die Werte der superglobalen Arrays einfach überschreiben kann, lässt sich recht einfach mit vielen WordPress Funktionen testen die Werte aus den superglobalen Arrays $_GET, $_POST und/oder $_REQUEST verwenden.

add_action(
	'admin_init',
	function(){
		if (
			( isset( $_GET['action'] ) && 'delete-comment' == $_GET['action'] )
			||
			( isset( $_GET['action'] ) && 'trash' == $_GET['action'] )
		) {
			$_GET['action'] = $_POST['action'] = $_REQUEST['action'] = 'not-now';
		}
	}
);

Einfach mal diesen Code-Schnipsel in die functions.php einfügen und dann im Backend die Kommentarübersicht aufrufen. Dort dann wahllos ein paar Kommentare löschen. Entweder über die Checkboxen und eines der Bulk-Menüs oder über den Link der erscheint wenn man mit der Maus auf einen Kommentar zeigt.
Nutzt man die Checkboxen und das Bulk-Menü, passiert gar nichts. Beim Löschen über den Link verschwindet zwar der Kommentar und der Zähler hinter “Papierkorb” geht hoch, ein Klick auf “Alle Kommentare” genügt um die vermeintlich gelöschten Kommentare wieder anzuzeigen.

Es geht aber deutlich böser

add_action(
	'admin_init',
	function(){
		if (
			( isset( $_GET['action'] ) && 'delete-comment' == $_GET['action'] )
			||
			( isset( $_GET['action'] ) && 'trash' == $_GET['action'] )
		) {
			$a = array_fill( 0, 5, 0 );
			array_walk( $a, function( &$e ){ $e = rand( 1,999 ); } );
			$_GET['delete_comments'] = $_POST['delete_comments'] = $_REQUEST['delete_comments'] = $a;
			$_GET['c'] = $_POST['c'] = $_REQUEST['c'] = rand( 1, 999 );
		}
	}
);

Dieser Code überschreibt nicht einfach die action, sondern ersetzt die ausgewählten Kommentare durch zufällige Werte. Egal was man auswählt, welche Kommentaren gelöscht werden ist reiner Zufall. Im besten Fall passiert nichts, da die zufällig ausgewählten IDs nicht existieren. Im schlimmsten Fall werden ganz andere Kommentare gelöscht als ausgewählt. Man könnte auch über eine SQL-Abfrage alle vorhandenen Kommentar-IDS abfragen und dann zufällig IDs auswählen, dass ist dann richtig böse aber ein anderes Thema.

Mit filter_input() wäre dies nicht möglich, da filter_input() nur die Werte berücksichtigt, die auch tatsächlich über einen Request abgeschickt wurden (siehe erstes Beispiel). Nun fragt man sich vielleicht warum WordPress etwas so dummes macht wenn es doch eine solch einfache Lösung für das Problem gibt.
Nun die Antwort liegt in meinen ersten Satz dieses Artkels. Die Filter-Funktionen sind erst ab PHP5.2 verfügbar, WordPress wurde jedoch zu PHP4 Zeiten entwickelt und enthält auch noch unendlich viel PHP4-Code. Wer das ändern möchte, kann gerne mal eine Suche nach $_GET, $_POST und $_REQUEST über die WordPress Dateien laufen lassen und die entsprechenden Stellen anpassen. Die Suche nach $_GET liefert aktuell 594 Treffer in 104 Dateien. Soviel zu diesen Thema.

Ich hoffe es ist klar geworden warum es nicht ganz unerheblich ist seinen Code mindestens auf PHP5.2 Niveau zu bringen und warum man in seinen Themes und Plugins unbedingt auf die Filter-Funktionen setzen sollte anstatt direkt auf die superglobalen Arrays $_GET, $_POST und $_REQUEST zuzugreifen.

Zum Schluss noch etwas Mehrwert. Manchmal kann es vorkommen das Werte sowohl per GET als auch POST Request übergeben werden (meist im Zusammenhang mit Ajax Requests), in diesen Fall greift man gerne auf $_REQUEST zurück. Da die Filter-Funktionen von PHP $_REQUEST (noch) nicht unterstützen, müsste man jedes mal umständlich $_GET und $_POST abfragen ob der benötigte Schlüssel vorhanden ist. Das kann man sich mit einer kleinen Funktion vereinfachen und den Mangel von PHP gleich etwas ausbügeln.

function read_superglobals( $vars ) {
	
	if ( is_string( $vars ) )
		$vars = (array) $vars;
	
	$return = array();
	
	foreach ( $vars as $variable_name ) {
		if ( ! filter_has_var( INPUT_POST, $variable_name ) ) {
			if ( ! filter_has_var( INPUT_GET, $variable_name ) ) {
				$return[$variable_name] = '';
			} else {
				$return[$variable_name] = filter_input( INPUT_GET, $variable_name );
			}
		} else {
			$return[$variable_name] = filter_input( INPUT_GET, $variable_name );
		}
	}

	return $return;
}

Die Funktion erwartet als Parameter ein Array oder einen String mit den jeweiligen Schlüssel(n) den/die man abfragen möchte. Die Funktion prüft dann mit filter_input() ob in $_GET oder $_POST der Schlüssel vorhanden ist. Ist er vorhanden, kopiert sie den Wert mit den zugehörigen Schlüssel in ein Array und gibt anschließend das Array zurück. Die Funktion arbeitet in etwa so wie wp_reset_var(), jedoch mit den Unterschied das sie keine globalen Variablen erzeugt und ausschließlich die Schlüssel zurück gibt, die auch tatsächlich mittels eines GET oder POST Requests abgesendet wurden.
Natürlich kann man die Funktion auch dann verwenden, wenn man genau weiß ob die Werte mittels GET oder POST Request gesendet wurden. Dann bekommt man ein Array zurück mit exakt den Schlüssel-Werte Paaren die man benötigt.

Oft schreibt man Funktionen oder Methoden und macht sich nur wenig Gedanken über den Rückgabewert im Fehlerfall, also dann, wenn die Funktion nicht die Aktion durchführen konnte wofür sie geschrieben wurde. Ich selber habe es bisher auch so gehandhabt das ich im Fehlerfall einen boolschen Wert oder vergleichbares zurück gegeben habe. Das Ergebnis ist, ich muss bei jeden Funktionsaufruf prüfen ob auch der Variablen-Typ zurück kommt den ich erwarte. Erwarte ich z.B. ein Array, kommt im Fehlkerfall aber ein boolsches False zurück, muss ich das abfangen.

Warum? Weil es ansonsten unter Umständen Fehlermeldungen hagelt und das Script abbricht. Im Backend kann man es noch verschmerzen, ich nenne das immer den “Weisste bescheid” Zustand. Im Frontend ist es aber mehr als peinlich und sogar kontraproduktiv wenn der Seitenaufbau nach dem Blogheader mit einer Fehlermeldung abbricht.

Stellen wir uns mal vor wir schreiben ein Widget für die Sidebar. Im Code für das Widget sind folgende zwei Funktionen:

/**
 * Create a ordered- or unordered list from values
 *
 * @param	string	$type	ol for ordered lists or ul for unordered list
 * @param	array	$values	Array with list items
 * @return	string			HTML list
 */
function get_list( $type = 'ol', $values = array() ) {

	$type = ( in_array( $type, array( 'ol', 'ul' ) ) ) ?
		$type : 'ol';

	foreach ( $values as &$val )
		$val .= ' item';

	$format = "<{$type}>" . str_repeat( '<li>%s</li>', sizeof( $values ) ) . "</{$type}>";

	return vsprintf( $format, $values );

}

/**
 * Returns an array or boolean depending on parameter
 *
 * @param	boolean	$fail	Returns an array if set to true, else returns boolean false.
 * @return Ambigous <boolean, multitype:string >
 */
function get_list_values( $fail = false ) {

	return ( true == $fail ) ?
		false : array( 'A', 'B', 'C' );

}

Die eine Funktion (get_list_values()) erzeugt ein Array mit Elementen, die andere Funktion (get_list()) erzeugt aus einem Array mit Werten eine HTML-Liste. Der Aufruf beider Funktionen könnte exemplarisch so aussehen:

$vals = get_list_values();
$list = get_list( 'ol', $vals );

echo $list;

Soweit funktioniert das ganze recht ordentlich. Nun provozieren wir jedoch mal einen Fehler und rufen die Funktion get_list_values() mit den Parameter 1 auf. Jetzt werden wir mit einen Warning: Invalid argument supplied for foreach() in ... begrüßt und das Script bricht an dieser Stelle ab.

Um solche Fehlermeldungen zu vermeiden, hätte ich vorher prüfen müssen ob $vals ein Array ist.

$vals = get_list_values(1);

if ( is_array( $vals ) ) {
  $list = get_list( 'ol', $vals );
  echo $list;
} else {
  // do some error handling
}

Das erscheint bisher alles recht logisch. Die frage ist nur, was soll man an dieser Stelle für ein Error-Handling machen? Einen Log-Eintrag? Eine eigene Fehlermeldung ausgeben? Nichts?
Nichts scheint mir eigentlich die beste Lösung zu sein. Mit einer eigenen Fehlermeldung kann der Besucher nichts anfangen.Und ein Log-Eintrag hilft dem Besucher auch nicht weiter. Ein Log-Eintrag hilft dem Programmierer bzw. den Admin an dieser Stelle ebenso wenig, da es unklar ist warum die Funktion get_list_values() gescheitert ist. Das kann uns nur die Funktion selber sagen, daher wäre ein Log-Eintrag innerhalb der Funktion sinnvoller untergebracht.

function get_list_values( $fail = false ) {

	if ( true == $fail ) {
		write_to_error_log( sprintf( 'Function %s was called with parameter $fail set to %s', __FUNCTION__, $fail ) );
		return false;
	}

	return array( 'A', 'B', 'C' );

}

Dadurch sind wir schon mal einen kleinen Schritt weiter. Der Fehler wird da geloggt, wo er tatsächlich auftritt, nicht da wo er zu einen weiteren Fehler führt. Das eigentliche Problem besteht jedoch weiterhin. Denn die Funktion gibt ja noch einen boolschen Wert zurück. Wir müssen also weiterhin prüfen ob das Ergebnis des Funktionsaufrufes tatsächlich von den erwarteten Typs ist. Das ist hinderlich, denn dadurch ist folgendes Konstrukt nicht möglich:

echo get_list( 'ol', get_list_values( 1 ) );

Würde die Funktion nun einen Wert vom erwarteten Typ zurück geben, könnten wir obiges Konstrukt ohne weiteres verwenden. Im Fehlerfall erhalten wir dann anstatt einer Liste lediglich ein leeres Ergebnis. Also ändern wir die Funktion ein klein wenig:

function get_list_values( $fail = false ) {

	if ( true == $fail ) {
		write_to_error_log( sprintf( 'Function %s was called with parameter $fail set to %s', __FUNCTION__, $fail ) );
		return array();
	}

	return array( 'A', 'B', 'C' );

}

Das Logging des Fehlers bleibt, er geht also nicht verloren. Dafür haben wir im Frontend keine Fehlermeldung mehr und der Seitenaufbau bricht auch nicht mehr ab.

Dies können wir nun auf alle Funktionen übertragen. Wenn die Funktion im Erfolgsfall ein Array zurück gibt, sollte sie dies auch im Fehlerfall machen, dann halt ein leeres Array. Erwarten wir ein Objekt als Rückgabewert, so sollte im Fehlerfall ein leeres Objekt zurück kommen. Allerdings sollte man speziell bei Objekten die Eigenschaften vorbelegen und nicht einfach nur ein leeres Objekt zurück geben da oft direkt auf die Objekteigenschaften zugegriffen wird und man, anders als bei Arrays, nicht mit empty() prüfen kann ob das Objekt überhaupt irgendwelche Eigenschaften enthält. Eine Abfrage mit empty() liefert bei Objekten immer false zurück, da ein Objekt niemals “leer” ist.

function get_some_object( $fail = false ) {

	$object = new stdClass();
	$object->foo = false;
	$object->bar = '';
	$object->baz = null;

	if ( true == $fail )
		return $object;

	$object->foo = true;
	$object->bar = 'FooBarBaz';
	$object->baz = $object;

	return $object;

}
$objects = array();
var_dump( $objects );

$objects[] = get_some_object();
$objects[] = get_some_object( true );
$objects[] = new stdClass();

array_walk( $objects, function( $object ) { var_dump( empty( $object ) ); } );

/*
Ausgabe:
array (size=0)
  empty

boolean false
boolean false
boolean false
*/

Der Grund warum man sich damit beschäftigen sollte ist jedoch nicht nur eine saubere Ausgabe im Frontend, sondern auch das Debuggen. Im ersten Beispiel wurde der Fehler nämlich still und heimlich an einen ganz anderen Ort verlagert. Obwohl er in der Funktion get_list_values() aufgetreten ist, wird er erst in get_list() beim Aufruf der foreach-Schleife wirksam. In Beispielen ist es immer einfach den Fehler zu finden. Sie sind von Natur aus kurz und übersichtlich. In größeren und längeren Scripten ist es jedoch oft nicht so einfach heraus zu finden wann und wo eine Variable durch einen Funktionsaufruf einen Wert zugewiesen bekommen hat. Liegen zwischen der Wertzuweisung und der Verarbeitung des Wertes noch andere Zwischenschritte in der der fehlerhafte Wert nicht zu einen Fehler führt, wird die Suche noch umständlicher.
Deshalb sollte man Fehlerfälle immer sofort dort behandeln, wo sie auftreten anstatt sie in einen Pseudozustand umzuwandeln und sie ggf. auch noch als Rückgabewert zurück zu geben.

Ich suchte eine Möglichkeit wie ich die Thickbox in ihrer Größe ändern kann, darüber hinaus mir aber keine Gedanken mehr machen muss wie groß ich sie dimensionieren soll. Die Thickbox sollte sich in ihrer Größe immer schön am dargestellten Inhalt ausrichten. Nach etlichen rumprobieren und etwas suchen, kam ich dann auf folgende Lösung:

jQuery(document).ready(
	function($){

		resize_thickbox_iframe();
/*
 *
 * some other jQuery code
 *
 */

		function resize_thickbox_iframe(){

			//padding
			var pad = 50;

			// give the body a height
			$( 'body' ).css( 'height', 'auto' );

			// read the bodys height and add some padding
			var mh = parseInt( $( 'body' ).height() ) + pad;

			var max_height = mh + 'px';

			// get the parent window dimensions
			var parent = $( window.parent.document );
			var ph = parent.height();

			// get the ID of this iframe and the iframe itself
			frame_id = frameElement.id;
			frame = $( '#'+frame_id, window.parent.document );

			// get the id of the overlay-div and the overlay-div itself
			div_id = frame.parent().attr( 'id' );
			div = $( '#'+div_id, window.parent.document );

			// first set the hight for the frame, than set the hight for the overlay-div
			frame.css( 'height', max_height );
			div.css( 'height', max_height );

			// calculate the new top position
			var tb = Math.round( ( ( ph - mh ) / 2 ) - pad ) + 'px';

			// set the new top position
			frame.css( 'top', tb );
			div.css( 'top', tb );

		}

	}
);

Das Script setzt die Höhe des body-Tags im iFrame zuerst auf ‘auto’ damit dieser eine Höhe bekommt (für den Fall das der body-Tag noch keine Höhe besitzt). Danach wird das iFrame aus dem Eltern-Dokument gefischt und seine Höhe angepasst. Da sich das iFrame allerdings innerhalb eines Overlay-Divs befindet, muss dieser ebenfalls aus dem DOM gefischt und angepasst werden. Zum Schluss werden Overlay-Div und iFrame neu ausgerichtet.

Das Script gehört in das iFrame hinein! Dementsprechend muss im iFrame auch noch jQuery geladen werden. Wer im iFrame auf jQuery verzichten kann, muss sihc die Funktion auf pures JavaScript umschreiben (ist auch nicht sooo schwer).

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

Das Pferd von hinten aufgezäumt

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

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

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

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

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

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

		} else {

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

		}

	}

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

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

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

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

		return $templates;

	}

}

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

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

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

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

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

	}

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

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

	}

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

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

	}

}

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

Die Templates verarbeiten

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

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

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

		$this->templates_object = &$templates;

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

	}

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

		// error message
		$err_msg = '';

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

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

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

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

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

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

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

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

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

			 }

		}

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

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

		}

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

	}

}

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

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

		parent::__construct( $templates );

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

	}

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

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

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

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

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

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

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

		}

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

	}

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

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

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

	}

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

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

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

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

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

	}

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

		echo $this->get_headline( $text );

	}

}

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

Lose koppeln anstatt fest verdrahten

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

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

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

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

// more code
echo $list;

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

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

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

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

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

	}

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

		$template_engine = strtolower( $template_engine );

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

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

		);

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

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

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

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

			} else {

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

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

			}

		}

		return self::$template_engine->$template_engine;

	} 

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

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

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

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

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

	}

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

		// html is build in

	}

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

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

	}

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

		return array(

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

		);

	}

	public function set_feed(){

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

	}

	public function add_feed( $template_engines ){

		$feed_engines = array(

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

		);

		return array_merge( $template_engines, $feed_engines );

	}

}

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

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

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

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

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

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.

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.

Der folgende Artikel wird etwas länger, deshalb habe ich ihn auf mehrere Seiten aufgeteilt. Diejenigen die sich mit WordPress auskennen, können den Artikel quer lesen da ich auch Grundlagen beschreibe. Interessante Sachen werden dann auf den letzten Seiten zu lesen sein. Diejenigen die sich nicht so gut mit WordPress auskennen, sollten zumindest die Grundlagen von WordPress und guter Programmierung beherrschen. Ich werde nicht jedes mal darauf hinweisen das man normalerweise definitiv nicht echo $_GET['blah']; schreibt, sondern alles auf seine Richtigkeit und Gültigkeit in prüft. Dann mal los…

Inhalt

1. Die Vorraussetzungen
2. Eleganter mit GET
3. JavaScript mal ganz objektiv
4. Mein Freund Jason
5. Da gibt es doch bestimmt eine App für…?
6. DIY – Jsonifice
7. Und Action!
8. Letzte Anmerkungen