Sperrobjekt Weblog

Nachdem Ende letzter Woche das Leistungsschutzrecht für Presseverleger im Bundestag verabschiedet wurde, spülte meine Timeline das Wordpress-Plugin vom D64 Zentrum für Digitalen Fortschritt wieder in meine Aufmerksamkeit. Das Plugin lädt eine Blacklist aus dem Netz, in der die Domains von Verlagen gesammelt werden, die das LSR unterstützen. Mittels dieser Liste lenkt es Links zu den Verlagsseiten, die in Blogartikeln enthalten sind, auf eine Hinweisseite zum LSR um:

Coole Idee. Ein kurzer Blick auf GitHub sagte mir, dass es nicht schwer sein würde, das Plugin für Serendipity zu adaptieren. Gesagt, getan.

"Leistungsschutzrechtprotestplugin" vollständig lesen

Geben wir es ruhig zu, der PHP-Code von Serendipity ist nicht mehr State of the Art, sondern zum großen Teil noch auf dem Stand von PHP 4. Dass dieser Code immer noch sehr zuverlässig funktioniert, und ob und wie mit dem aktuellen Stand umzugehen ist, soll hier nicht das Thema sein. Ich möchte hier auf die Entwicklung von Serendipity-Plugins eingehen, die nicht umsonst in einem eigenen Repository leben. Deren Qualität lässt sich mithilfe von Unit Tests sicherstellen.

PHPUnit für Plugins

Auch wenn die Grundfunktionalität von Serendipity durch Unit Tests abgedeckt ist: Die Plugin-Entwicklung ist bisher nicht so einfach zu testen. In meinen letzten Projekten waren Unit Tests mit PHPUnit ein zunehmend zentraler Bestandteil der Entwicklung. Entweder damit ich nachträglich sicherstellen konnte, dass Klassen und Methoden bei Veränderungen und Refactoring noch taten, was sie tun sollten; oder weil ich testgetrieben entwickelte, das heißt zuerst die Unit Tests und dann erst den zu testenden Code schrieb. Dieses Vorgehen möchte ich nicht mehr missen, und es hat mich gestört, dass es bei der Entwicklung von Serendipity-Plugins nicht ohne Weiteres möglich war.

Daher habe ich mich hingesetzt und PHPUnit so in meine lokale Serendipity-Installation, die ich zum Entwickeln verwende, integriert, dass ich einzelne (Event-)Plugins separat testen kann. Die spezifischen Herausforderungen ließen sich recht schnell überwinden:

• In Serendipity werden Plugins stark getrennt vom Core über Event-Hooks ausgeführt. Diese Hooks müssen natürlich einzeln getestet werden können.
• Viele Variablen sind als global deklariert oder werden per Referenz "herumgereicht". Das erfordert einige Workarounds, die heute dank Dependency Injection und ähnlichen Entwurfsmustern zum Glück überflüssig sind.
• Data Fixtures: Um Serendipity für die Tests "hochzufahren", wird eine Datenbankverbindung benötigt. Mir ist es bisher nicht gelungen, eine der unter Database Testing aufgeführten Methoden umzusetzen. Besser gesagt: Ich war einfach zu faul und habe die nötigen Daten in einer SQLite-Datenbank hinterlegt.

"PHPUnit für die Entwicklung von Serendipity-Plugins" vollständig lesen

Das Geotag-Plugin für Serendipity zeichnet Blogartikel auf Landkarten unterhalb des Beitrags oder in der Seitenleiste ein. Beim Verfassen kann ein Blogger einen Artikel mit den Geo-Koordinaten seines Aufenthaltsortes versehen (so genanntes Geotaggen). Diese Position wird anschließend auf einer kleinen Karte angezeigt. Nützlich ist diese Funktion ist beispielsweise für Reiseblogs.

Weniger Fehler, mehr Funktionen

Leider hatte das Plugin zuletzt einige Bugs, die zum Teil aus Schnittstellenänderungen von Google Maps resultierten. Grischa hat sich das Plugin vorgenommen und vorgestern eine neue Version eingecheckt, die die meisten Bugs behebt und sogar tolle neue Features mitbringt.

Allerdings berichtete Grischa von Problemen mit der Kartendarstellung in der Seitenleiste. In den Kommentaren zu seinem Artikel kam außerdem der Wunsch auf, neben Google Maps auch Karten von Openstreetmap einzubinden. Zum einen unterliegen letztere einer Creative Commons-Lizenz, zum anderen hat Google vor kurzem Zugriffsbeschränkungen für seine Kartenschnittstelle eingeführt. Leichtfertig kommentierte ich, dass ich mir das ja mal ansehen könnte. Als passionierter Openstreetmapper und Geocacher liegt mir das Thema eben am Herzen

Gesagt, getan. Der Aufwand war allerdings größer, als ich erwartet hatte. Zum einen lief das Plugin noch mit dem Google Map Javascript API in Version 2, die aber schon sein 1,5 Jahren als deprecated eingestuft ist und in absehbarer Zeit abgeschaltet werden wird; also habe ich den Code auf Version 3 umgestellt. Zum anderen habe ich Openstreetmap mithilfe der OpenLayers-Bibliothek eingebunden, die nicht gerade simpel zu benutzen ist. Sie ist andererseits zwar sehr mächtig, aber ich habe für das Plugin nur einen kleinen Teil ihrer Fähigkeiten benötigt. Doch nun ist es geschafft: Meine aktualisierte Version 1.26 habe ich gerade hochgeladen, sie dürfte in Kürze für alle verfügbar sein.

"Geotag-Plugin für Serendipity überarbeitet" vollständig lesen

Hohe Code-Qualität ist nicht nur in großen Projekten wichtig, an denen mehrere Programmierer sitzen. Auch im Kleinen hilft die Einhaltung formaler Richtlinien (Coding Standards), Fehler zu vermeiden und den Quellcode wartbar zu halten. Mittlerweile existieren auch für PHP diverse Tools, die den Programmierer beim Coden unterstützen. Zwei davon, Code-Sniffer und Mess Detector, bemängeln automatisch anhand definierter Regeln auch kleine Unachtsamkeiten wie fehlende Kommentare, ungenutzte Variablen oder übermäßig komplizierten Code. Diese lassen sich recht einfach auch in IDEs wie Netbeans integrieren, wie ich im folgenden kurz zeige.

PEAR-Pakete downloaden

Voraussetzung sind die PEAR-Pakete PHP_CodeSniffer, das von Greg Sherwood betreut wird, und PHP_MD (PHP Mess Detector von Manuel Pichler). Die Links verweisen auf Installationsanleitungen. In der Regel lassen sich die Pakete mit PEAR-Bordmitteln installieren.

Unter Linux werden unter /usr/bin die beiden Batchfiles phpcs bzw. phpmd installiert, die zum Ausführen der Tools verwendet werden sollten, weil sie Prüfungen vornehmen und benötigte Klassen importieren.

Netbeans-Plugin installieren

Bei der Suche nach entsprechenden CodeSniffer-Plugins für Netbeans habe ich zwei Projekte gefunden. Das Plugin von Benjamin Eberlei wurde im April 2010 zum letzten Mal aktualisiert und hat bei mir nicht richtig funktioniert (YMMV). Das PHP CodeSniffer Netbeans Plugin (Download für Netbeans 6.9.1) lief auf Anhieb und hat auch die Unterstützung für PHP_MD bereits integriert. Zur Installation ladet ihr die *.nbm-Datei herunter und installiert das Plugin in Netbeans unter "Extras → Plugins → Heruntergeladen → Plugins hinzufügen …". Gegebenenfalls ist jetzt ein Neustart von Netbeans nötig.

Tools konfigurieren

Unter "Extras → Optionen → PHP → phpMD bzw. phpCodeSniffer" können nun globale Einstellungen vorgenommen werden. In der Regel müssen zunächst die jeweiligen Batch-Dateien (/usr/bin/phpmd und /usr/bin/phpcs) angegeben werden. Außerdem kann ein Coding-Standard, z.B. "Zend" eingetragen werden (mehr Infos dazu in der Dokumentation). Über die Schaltfläche "Test Settings" lässt sich überprüfen, dass die Batch-Dateien korrekt angegeben wurden.

Wird jetzt eine PHP-Datei im Netbeans-Editor geöffnet, parsen die Tools den Dateiinhalt und geben ihre Ergebnisse im "Aufgaben"-Fenster aus. Dort lassen sich die Resultate auch gruppieren und filtern. Diese variieren natürlich je nach Coding Standard und werden jeweils beim Speichern einer Datei neu ermittelt.

Projektspezifische Einstellungen

Wer möchte, kann sich auch eigene, so genannte "Sniffs" programmieren, also eigene Validierungsregeln aufstellen. Sollen diese allerdings nicht global für alle Projekte gelten, sondern nur für einzelne, ist etwas Handarbeit gefragt. Im Netbeans-Projektverzeichnis, also im Verzeichnis nbprojects, muss eine Datei codesniffer.properties angelegt werden, die projektspezifische Settings beinhaltet. Dort können verschiedene Optionen gesetzt werden, allerdings bin ich mir nicht sicher, ob alle möglichen Kommandozeilenargumente auch dort gesetzt werden können. Soll ein eigenes Ruleset definiert werden kann man darauf verweisen:

phpcs.standard=/pfad/zum/eigenen/ruleset.xml

Es sind im Endeffekt nur kleine Helferlein, aber sie erledigen nützliche Arbeit im Hintergrund. Und sie machen sich nach einer Weile fast selbst überflüssig, wenn man als Programmierer darauf achtet, nicht immer wieder die gleichen Fehler "vorgehalten" zu bekommen.

Selenium-Tests können elegant direkt in NetBeans für PHP erstellt und aus NetBeans heraus ausgeführt werden. Leider funktioniert das unter bestimmten Umständen nicht out-of-the-box, sondern macht einige Kniffe notwendig.

NetBeans-Plugin installieren

Ich gehe davon aus, dass ihr alles notwendige für die PHP-Entwicklung installiert habt. Das schließt PHPUnit ein, auf das die Selenium-Tests zurückgreifen. Wie man Selenium in PHPUnit integriert, wird hier ausführlich beschrieben.

Auf meinem Ubuntu-Rechner mit NetBeans 6.9.1 und Firefox 3.6.12 lässt sich das Selenium Module for PHP aus dem NetBeans Beta-Repository einfach installieren: Unter "Extras > Plugins > Einstellungen" das Häkchen bei "NetBeans Beta" setzen, dann steht das Selenium-Modul zur Auswahl und kann installiert werden. Anschließend lässt sich nach Rechtsklick auf das Projekt im Projektmanager der Punkt "Run Selenium Tests" aus dem Kontextmenü auswählen. Zunächst muss ein Verzeichnis ausgewählt werden, in dem die Testdateien abgelegt werden. Ich habe den Ordner selenium direkt neben nbprojects in meinem Projektverzeichnis angelegt und als Testverzeichnis ausgewählt.

Da wir noch keine Testdateien erstellt haben, wird auch noch nichts ausgeführt, aber das Verzeichnis wird als Selenium Test Files aufgeführt. Wiederum über das "Kontextmenü > Neu" kann jetzt ein "Selenium Test Case for PHP" erstellt werden. Dabei legt NetBeans freundlicherweise schon das Code-Gerüst für den neuen Test-Case an. Natürlich kann, wer möchte, auch manuell Test-Cases im Test-Verzeichnis anlegen oder den PHP-Code aus der Selenium IDE (= Firefox-Extension) herausgenerieren lassen. Die NetBeans-Vorlage sieht etwa wie folgt aus.

require_once 'PHPUnit/Extensions/SeleniumTestCase.php';

class newSeleneseTest extends PHPUnit_Extensions_SeleniumTestCase
{
    protected function setUp()
    {
        $this->setBrowser("*chrome");
        $this->setBrowserUrl("http://change-this-to-the-site-you-are-testing/");
    }

    public function testMyTestCase()
    {
        
    }
}

Unabhängig davon, welchen Test man in testMyTestCase() implementieren möchte, gilt es jetzt noch einige Stolpersteine aus dem Weg zu räumen.

"Selenium Tests mit NetBeans und PHP" vollständig lesen