Ein paar Basics

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

Hooks

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

Das Setup

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

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

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

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

Fazit

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

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

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

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

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

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

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

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

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

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

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

Das PHP-Manual sagt zum Platzhalter %b folgendes:

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

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

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

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

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

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

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

	default:
		// alle anderen Faelle
	break;
}

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

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

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

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

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

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

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

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

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

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

Und hier das ganze dann  noch mal als komplettes Script:

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

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

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

$bin = '';

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

$dec = bindec( $bin );

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

		self::$die_on_fail = $status;
	}

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

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

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

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

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

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

		return TRUE;
	}

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

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

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

		return TRUE;
	}

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

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

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

		return TRUE;
	}

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

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

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

		return TRUE;
	}

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

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

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

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

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

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

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

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

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

$a->run_all_tests( $v );


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

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

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

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

$r = new stdClass();

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

var_dump( $r );

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

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

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

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

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

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

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

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

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

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

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

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

	<body>

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

	</body>
</html>

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

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

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

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

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

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

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

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

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

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

	<body>

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

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

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

Manchmal bin ich pingelig und mich stört so etwas auch. Logindaten egal welcher Art haben in Links und anderen öffentlich zugänglichen Bereichen einfach nichts zu suchen. Das widerspricht auch der Idee das man neben den Login-Namen auch noch zwei andere Namen in seinem Profil angeben kann und auswählen kann welchen Namen man gerne öffentlich verwenden möchte.

Der Workaround

Um das Problem zu lösen gibt es einen Workaround und eine Möglichkeit mit Filtern zu arbeiten. Zuerst der Workaround. WordPress bietet nämlich die Möglichkeit für jeden Autoren eine eigene Autoren-Seite anzulegen. Dieses Template wird zuerst gezogen bevor das allgemeine Template für alle anderen Autoren verwendet wird. Anders ausgedrückt: Existiert für den Autor X ein spezielles Template, wird dieses verwendet. Existiert kein solches Template, dann wird das allgemeine Template verwendet.
Dabei sucht WordPress in folgender Reihenfolge nach einem passenden Template:

1. author-{autor-name}.php
2. author-{autor-ID}.php
3. author.php

Ist der Login-Name des Autoren z.B. “Klaus” und existiert ein Template author-klaus.php, wird zuerst dieses Template verwendet. Dies hilft uns in diesem Fall jedoch nicht weiter, da weiterhin der Login-Name verwendet wird.
Jedoch kann man auch die ID des Autoren verwenden. Existiert ein Template author-12.php und hat der Autor “Klaus” die ID 12, dann wird dieses Template verwendet. Ändert noch nichts daran das im Link immer noch der Login-Name erscheint.
Um dies zu ändern, greift man in das Template ein in dem die Funktion get_author_posts_url() verwendet wird. Das ist von Theme zu Theme leider immer etwas unterschiedlich, je nach dem wo die Metadaten zum Post ausgegeben werden. Diesen Funktionsaufruf ersetzt man nun mit diesem Monster:

str_replace(
  get_the_author_meta( 'user_nicename' ),
  get_the_author_meta( 'ID' ),
  get_author_posts_url( get_the_author_meta( 'ID' ) )
)

Damit ersetzt man den Login-Namen (user_nicename) durch die ID des Autoren. Nun benötigt man noch ein Template author-xy.php wobei xy die jeweilige ID des Autoren ist.

Das ganze ist ein Workaround der nur sehr begrenzt einsatzfähig ist. Man muss jedes mal am Theme rumfummeln, die ganze Sache ist nicht wirklich übersichtlich und am Ende benötigt man auch noch für jeden Autoren ein eigenes Template. Eignet sich also normalerweise nur für Blogs in denen es 1-2 Autoren gibt und die eher selten ihr Theme wechseln.

Login im Iframe

Im Grunde genommen kann man den ganzen Login-Prozess in einem Iframe ablaufen lassen. Man muss sich dabei lediglich vor Augen halten das ein Iframe mit einem neuen Tab im Browser vergleichbar ist. Dem Server ist es jedoch egal ob man den Login in einem neuen Tab oder Iframe vornimmt. Ob ein Benutzer eingeloggt ist oder nicht, wird in einem Cookie gespeichert. Dadurch ist der “Ort” wo man sich einloggt uninteressant, so lange er vom gleichen Server aus erfolgt.

Fangen wir also gleich damit an die wp-login.php in einem Iframe anzuzeigen. Damit dies ein wenig komfortabler wird, legen wir uns eine Funktion an die wir in der functions.php oder einem Plugin ablegen können.

function my_login_form( $args ){

	extract( $args );

	if( !isset( $width ) ){
		$width = 300;
	}

	if( !isset( $height ) ){
		$height = 300;
	}

	if( !isset( $redirect ) ){
		$redirect = content_url() . '/themes/my_theme/logout.php';
	}

	echo '<iframe src="http://www.example.com/wp-login.php?redirect_to=' . $redirect . '&iframe_mode=true" width="' . $width . '" height="' . $height . '">';
}

Diese Funktion macht eigentlich nichts anderes als ein Iframe anzuzeigen welches als Source die wp-login.php hat. Die Zeilen 3-16 dienen lediglich dazu ein paar Parameter an die Funktion zu übergeben. Im Beispiel oben sind das width (Breite des Iframe), height (Höhe des Iframe) und redirect_to (Ziel-URL zu der nach dem Login umgeleitet werden soll). Diese Parameter werden per Array übergeben:

if( function_exists('my_login_form') ){
	$args = array( 'width'=>300,
		       'height'=>200,
			redirect_to=> content_url().'/themes/my_theme/mylogin_redirect.php' );
	my_login_form( $args );
}

Fügen wir obigen Code-Schnipsel in unser Blog ein, z.B. in der Sidebar, dann fügt die Funktion an dieser Stelle ein Iframe mit der Breite 300px und Höhe 200px ein. Bis hierhin nichts wirklich aufregendes, einzig der Parameter redirect_to tanzt ein wenig aus der Reihe.
Wir erinnern uns, die Anzeige im Iframe ist mit einem neuen Tab vergleichbar. Die Situation ist nun folgende: Innerhalb des Blogs wird die wp-login.php angezeigt, beim Betätigen des  Submit-Buttons leitet die wp-login.php, sofern die Login-Daten korrekt sind, automatisch auf eine andere Seite um. Diese Seite wird dann ebenfalls im Iframe angezeigt! Normalerweise wird auf die Profil-Seite des Benutzers bzw. ins Dashboard umgelietet, in einem kleinen Iframe dargestellt sieht dies eher unbrauchbar aus. Diese Umleitung kann man jedoch beim Aufruf der wp-login.php mit dem Parameter redirect_to beeinflussen.
Dies machen wir uns zu nutzen und zeigen einfach eine eigene Seite an deren Inhalt besser in das Iframe passt. Diese Datei hat noch eine weitere recht wichtige Aufgabe. Denn durch den Aufruf von wp-login.php würden wir eine weitere Instanz von WordPress erzeugen was zu unschönen Nebeneffekten führen könnte. Ich habe hier als Beispiel mal den Benutzernamen und einen Logout-Link ausgegeben. Wichtig ist, dass das Script mit einem exit; beendet wird:

<?php
global $current_user;

echo $current_user->user_name . '<br />';
echo '<a href="' . wp_logout_url( site_url().'/wp-login.php' ) . '" title="Logout">' . __('Logout') . '</a>';
exit;
?>

Durch die Angabe von site_url . '/wp-login.php' wird beim Betätigen des Logout-Links (innerhalb des Iframes) wieder auf die Login-Seite umgeleitet.

Fehlende Optik

Damit haben wir uns bis jetzt ein schönes Karussell gebastelt.  Im Iframe wird die wp-login.php angezeigt, nach einem erfolgreichen Login wird unsere eigene Seite angezeigt und nach dem Ausloggen wieder die wp-login.php.
Jetzt bleibt noch ein kleines aber nicht unbedeutendes Problem übrig. Die wp-login.php würde im Iframe mit dem originalem Stylesheet angezeigt werden, dieses ist aber nicht auf Miniformate wie z.B. 300x200px ausgelegt. Zudem haben wir nun ein paar Elemente drin auf die wir gerne verzichten würden. Ein angepasstes Stylesheet muss also her. Wie man den Login-Screen optisch an seine eigenen Bedürfnisse anpasst, dazu finden sich im Internet massig Anleitungen. Zur Not einfach Bei Frank Bültge vorbei schauen, dort findet sich (fast) immer etwas passendes.
Ein kleines Problem gibt es dabei allerdings. Bei Verwendung des Hooks würde ein Benutzer der die wp-login.php “normal” aufrufen würde (z.B. über ein Bookmark), ebenfalls das angepasste Stylesheet zu sehen bekommen. Es muss also ein Kriterium her anhand dessen man unterscheiden kann ob die wp-login.php im Iframe oder in einem normalen Fenster angezeigt wird. Im Script selber können wir das (leider) nicht überprüfen, deswegen geben wir diese Information beim Aufruf der wp-login.php als GET-Parameter mit: &iframe_mode=true sorgt dafür das wir im Hook überprüfen können ob dieser Parameter gesetzt ist. Ist dem so, dann wird das angepasste Stylesheet geladen, ansonsten passiert nichts.

function check_iframe_mode(){

	if( isset( $_REQUEST['iframe_mode'] ) && true === $_REQUEST['iframe_mode'] ){
		echo '<style type="text/css">
		@import url("' . site_url().'/themes/my_theme/my_login_style.css");
		</style>';
	}

}

add_action( 'login_head', 'check_iframe_mode' );

Das Stylesheet liegt in diesen Beispiel im Themes-Ordner ‘my_theme’ und hat den Namen ‘my_login_style.css’. Man kann das CSS auch direkt ausgeben, jedoch lässt sich eine separate Datei leichter pflegen und anpassen.

Fazit

Mit diesem letzten Schritt wären wir nun am Ziel angekommen. Nun findet der Login-Prozess komplett im Iframe statt. Allerdings hat diese Methode auch ein paar Nachteile die ich hier nicht verschweigen möchte.
Zum einen wird keine Rücksicht auf die Seite genommen in der das Iframe eingebettet ist. Sind hier Elemente vorhanden die vom Login abhängig sind, z.B. Anzeige des Benutzernamens, dann werden diese Elemente erst dann sichtbar bzw. aktualisiert wenn die Seite erneut geladen wird. Diesen Mangel kann man zur Not noch mit etwas zusätzlichem JavaScript beheben indem man einen Reload der Hauptseite erzwingt.
Zum anderen geht diese Methode nicht sehr schonend mit den Resourcen um. Denn alleine durch die Anzeige der wp-login.php werden Datenbankverbindungen aufgebaut, Variablen angelegt und damit letztendlich auch Speicher verbraucht. Für Blogs mit hohen Besucheraufkommen sollte man deswegen besser auf andere Lösungen, sprich komplexere Plugins, zurück greifen.
Für kleinere Blogs und den Hobby-Bastler jedoch eine Anregung für einen weiteren Ausbau. Ein Workaround könnte so aussehen, dass man nach dem Logout nicht direkt wieder auf die wp-login.php umleitet, sondern auf eine dritte “Zwischenseite” die einen Link zur wp-login.php enthält.

Ich hoffe dem einen oder anderem mit diesem Artikel ein paar Anregungen gegeben zu haben und freue mich über etwas Feedback in den Kommentaren.