Das erste plugin das erwähnt wird ist meine Bessere Tag Wolke, der Artike betont ihre leichte Bedienbarkeit: Um Tag Wolken kreativ einzusetzen muss man ein plugin benutzen. Die Bessere Tag Wolke bietet einige einfache aber zweifellos effektive Lösungen. [...] Die Einstellungsseite ist einfach und intuitiv, Benutzer können einen Titel auswählen, die größte und kleinste Schriftgröße bestimmen, die Anzahl der angezeigten tags begrenzen und die Art wie sie angeordnet werden sollen einstellen. Hier ein Beispiel:

Das zweite plugin dass in dem Artikel erwähnt wird ist mein Theme Vorschau und Umschalter plugin: Ein im Blog eingesetztes theme zu modifizieren kann eine stress- und schmerzvolle Erfahrung sein. Allerding erlaubt dieses plugin Besuchern eine Vorschau eines themes zu sehen, ohne dass man sich die Mühe machen muss das theme zu aktivieren und dann in einem neuen Fenster oder Tab anschauen. Der Artikel beschränkt sich auf den Einsatz als Werkzeug für WordPress theme Entwickler obwohl das plugin mittlerweile noch viel mehr kann. Es kann beispielsweise eine Theme-Woke zum Umschalten anzeigen:

Dank an Kerry Webster der mich darauf aufmerksam gemacht hat und ein PDF des englischen Originalartikels zum herunterladen anbietet.

Wer WordPress plugins schreibt und sie auf der WordPress.org Seite für plugins veröffentlicht sehen möchte muss svn benutzen. Dies kann etwas frustrierend sein wenn man erst einmal die Fäigkeiten von git kennen gelernt hat.

Zum Glück kann git auch mit svn kommunizieren, hierfür gibt es git-svn. Hier ist eine Liste von Befehlen die man einsetzen kann.

git svn init -s http://svn.wp-plugins.org/Ihr_plugin

Hiermit wird ein lokales git Repository kreiert. Innerhalb des Repositorys kann man folgende Befehle benutzen:

git svn fetch
git gc
git branch -a

Das erste Kommando wird einige Minuten dauern und alle tags und Zweige herunterladen. Der zweite Befehl räumt im lokalen Repository auf und komprimiert Dateien. Dies wird den Festplattenverbrauch deutlich verringern. Der letzte Befehl listet alle Entwicklungszweige auf, lokal und auf dem svn server. Um einem dieser entfernten Zweige lokal zu folgen gibt es den Befehl

git checkout -b svn-trunk trunk

svn-trunk ist in diesem Beispiel der Name des neuen lokalen Zweigs, der Name ist frei wählbar.

Ein normaler Arbeitsablauf kann so aussehen:

git checkout -b neuerzweig # lokal einen neuen Zweig erstellen
... bearbeiten ...
git commit -m "Tolles neues Feature erstellt" -a
git checkout svn-trunk
git merge neuerzweig
git svn dcommit

Diese Befehle erzeugen einen lokalen Entwicklungszweig in dem man neue Dinge ausprobieren kann. Der commit-Befehl fügt die Änderungen dem lokalen Repository hinzu. Das dritte Kommando wechselt zum lokalen Zweig, der dem entfernten trunk entspricht. Der vierte Befehl integriert die Änderungen aus neuerzweig. Abschließend wird der neue Programmcode auf den svn-Server hoch geladen.

Gerade wenn man mit dem WordPress-Server interagiert muss man gelegentlich tags anlegen. Das geht mit foldendem Befehl:

git svn tag version

Hiermit wird ein tag im entfernten svn Repository erstellt. Hierfür scheint mindestens git 1.6.1 nötig zu sein. Benutzer von Debian Lenny müssen git von backports.org herunterladen.

Mit diesen Beispielen sollten die ersten Schritte mit git für die WordPress plugin Entwicklung leichter fallen. Bitte lesen Sie auf jeden Fall die git Dokumentation für weitere Informationen. git-svn unterliegt einigen Beschränkungen: Der beschriebene Arbeitsablauf sollte nur benutzt werden wenn man der einzige Entwickler ist und nur ein git Repository hat.

Und das ist nicht gut so. Jquery ist durchaus klein, CSS Stile normalerweise auch. Aber das ist kein Grund sie jedem Besucher beim Aufruf irgend einer beliebigen Seite aufzuzwingen. Ein paar weitere Nachforschungen haben keine einfache Lösung ergeben, also habe ich meine eigene geschrieben.

Normalerweise bindet ein plugin seine Dateien über die wp_print_styles oder wp_print_scripts Aktionen ein:

add_action( 'wp_print_styles', 'deinplugin_css_einbinden' );
 
function deinplugin_css_einbinden() {
    echo $csslink;
}

Nimm statt dessen etwas wie folgendes:

add_action( 'wp_print_styles', 'deinplugin_css_einbinden' );
 
function deinplugin_css_einbinden() {
    // Prüfen ob der shortcode im Inhalt der Seite vorkommt
    global $post;
    if ( strstr( $post->post_content, '[deinshortcode]' ) ) {
        echo $csslink;
    }
}

Das ist schon alles. Bitte fügt eure CSS- und JavaScript-Dateien nicht jeder Seite meines Blogs hinzu.

Update: Dieser exzellente Artikel stellt eine verbesserte Lösung dieses Problems dar.

Update 2: Die bisher beste Lösung um JavaScript zu laden