Mein erstes WP Meetup in Potsdam
Wie einige von euch wissen, war ich die letzten beiden Jahre auf den WordCamps in Berlin und Köln. Beide waren sehr unterschiedlich, aber ich habe bei beiden neue Dinge gelernt und nette Leute kennengelernt. Aber was macht man nun die restlichen 11 Monate im Jahr, während man auf das nächste WordCamp wartet? Die Anwort: WP Meetups. Hier trifft man Gleichgesinnte in einer sehr lockeren Atmosphäre und tauscht sich über ein bestimmtes Thema oder allgemein über WordPress aus.
Am Mittwoch hat es mich also vor die Tore der Hauptstadt gezogen und trotz langer Anreise hat es sich gelohnt. Einen Bereicht über die Teilnehmer inkl. Foto findet ihr in dem Beitrag von Caspar, der einer der beiden Initiatoren des Potsdamer WP Meetups ist. Es gibt auch eine Facebook Seite sowie eine Google+ Seite zum Potsdamer WP Meetup. Dort könnt ihr immer nachlesen, wass das nächste WP Meetup stattfindet und was dort als Thema vorgeschlagen wird. Das nächste findet am 14. Februar 2012 statt und so wie es im Moment aussieht werde ich wohl zum Thema “Grundlagen der Plugin-Programmierung” einen kleinen Vortrag halten. Wer mich also mal im “real life” treffen möchte und noch dazu etwas zur Plugin-Programmierung erfahren möchte, der muss nur noch seiner Freundin oder seinem Freund erklären, wieso er am Valentinstag nicht da ist 
Pflege des Backend Localization Plugins
Ich habe mir am Wochenende mal mein Backend Localization Plugin vorgenommen und dieses etwas aktualisiert. Zum einen sah die Sprach-Auswahl im Login-Formular nicht mehr besonders schön aus, da mit WordPress 3 das CSS dazu geändert wurde. Zusätzlich kamen einige neue Sprachen dazu, in die WordPress mittlerweile übersetzt ist (bzw. noch übersetzt wird). Hier mal eine Liste der neu hinzugekommenen Sprachen:
| ISO 639 | Name |
|---|---|
| es_CL | Spanisch (Chile) |
| es_PE | Spanisch (Peru) |
| es_VE | Spanisch (Venezuela) |
| fa_AF | Persisch (Afghanistan) |
| fy | Westfriesisch |
| gd | Schottisch-Gälisch |
| haw_US | Hawaiisch |
| hy | Armenisch |
| is_IS | Isländisch |
| jv_ID | Javanisch |
| kea | Kabuverdianu |
| kk | Kasachisch |
| kn | Kannada |
| li | Limburgisch |
| me_ME | ??? |
| mg_MG | Malagasy |
| mn | Mongolisch |
| ne_NP | Nepali |
| nl_BE | Niederländisch (Belgien) |
| pa_IN | Panjabi |
| sa_IN | Sanskrit |
| so_SO | Somali |
| srd | Sardisch |
| ta_LK | Tamilisch (Sri Lanka) |
| zh_TW | Chinesisch (Taiwan) |
Es ist immer sehr aufwändig diese Liste zu pflegen, da ich erst einmal feststellen muss, was sich hinter dem ISO 639 Code verbirgt. Ich konnte aber bis auf einen Code alle finden. Wenn also jemand von euch weiß, welche Sprache sich hinter me_ME verbirgt, dann würde ich mich über einen Kommentar dazu sehr freuen.
Was man aber auch sehr gut an dieser Liste sehen kann ist die schnelle Verbreitung von WordPress in viele Regionen der Welt. Insgesamt enthält das offizielle Sprachdateien-Repository von WordPress mittlerweile 94 Sprachcodes. Hier ist aber z.B. für Deutschland nur die “Du-Version” enthalten. Die eigentliche Anzahl an unterschiedlichen “Sprachen” liegt also vermutlich noch um einiges höher.
Plugins und Sicherheit: Sicherheitslücke in Filedownload Plugin geschlossen
Aus gegebenem Anlass kommt heute mal ein Artikel zu einem sehr heiklen Thema: Plugins und Sicherheit. Ein mir bekannter Blog wurde letzte Woche gehackt. Anschließend konnte man auf diesem nur noch Space Invaders spielen. Glücklicherweise war es ein sehr netter Hacker, der seine Tat zugab und auch gleich erklärte, was falsch gemacht wurde und wie er damit ohne Probleme den Blog hacken konnte.
Funktion des Plugins
Die Sicherheitslücke steckte in dem Plugin Filedownload. Dieses Plugin wird eingesetzt um eine in WordPress hochgeladene Datei direkt zum Download anzubieten. In der Regel öffnet ein Browser ja eine Datei, die er direkt anzeigen kann, wie z.B. ein Bild oder eine PDF-Datei. Dieses Plugin gibt aber nun die angeforderte Datei so an den Browser zurück, dass dieser das Download-Dialogfenster öffnet und den Benutzer zum Download der Datei auffordert.
Valides XHTML mit dem Google Analytics for WordPress Plugin
Gestern Abend hatte ich mir mal wieder die Zeit genommen meine Startseite auf invaliden Quellcode hin zu untersuchen. Da meine Seite noch XHTML als Doctype verwendet, gab es einige Fehler bzgl. Der “target” Attribute in der Blogroll. Nach langer Recherche konnte ich das sehr beliebte Google Analytics for WordPress Plugin von Joost de Valk als Fehlerquelle ausmachen.
Das Problem
Man kann nun aber dem Plugin nicht wirklich einen Vorwurf machen. Nachdem ich den Quellcode des Plugin sowie die Ausgabe der Blogroll im WordPress Core untersucht habe, konnte ich auch keine bessere Einbindung finden als die im Plugin verwendete. Es fehlt leider ein Filter, mit dem man den Link Tags zusätzliche Attribute anhängen kann. Da aber bei aktivierten Outlink-Tracking noch ein “onclick” Attribut notwendig ist, wurde es vom Plugin-Entwickler eben an das “target” Attribut angehängt. Damit war denn der Inhalt des selbigen nicht mehr leer und es wurde ausgegeben, auch wenn der Link für die Blogroll im Backend auf “none” gestellt war.
Die Lösung
Es gibt glücklicherweise eine recht einfache Lösung für das Problem. Da es einen Filter für die gesamte Ausgabe der Blogroll gibt, können wir hier ansetzen. Wir entfernen einfach sämtliche leere “target” Attribute im Ausgabestring mit folgendem Snippet:
function remove_empty_target($content){
return str_replace('target="" ', '', $content);
} add_action('wp_list_bookmarks', 'remove_empty_target');
Das Snippet fügt ihr einfach in die functions.php Datei eures Themes an einer beliebigen Stelle ein. Wer für seine Seite ein Theme verwendet, das als Doctpye HTML5 nutzt, der kann diesen Tipp getrost ignorieren. Denn in HTML5 ist das “target” Attribut wieder enthalten. Trotzdem halte ich noch immer die Angewohnheit externe Links mit einem target="_blank" in einem neuen Tab/Fenster zu öffnen für eine Todsünde der Usabilty. Aber im Zusammenhang mit Formularen und JavaScript kann ein “target” Attribut durchaus Sinn machen und notwendig sein.
Das WordCamp 2011 in Köln – Mein Rückblick
Um es kurz und knapp auf den Punkt zu bringen: Es hat sich gelohnt. Angefangen hat es schon am Freitag mit einer Zugfahrt von Berlin nach Köln, die so einiges zu bieten hatte. Das Highlight war wohl der Stopp in Hannover, wo ein Wagon aus der Mitte unseres Zugverbands rausgenommen werden musste. Insgesamt hatte ich dann fast zwei Stunden Verspätung bis Köln. Nur gut, dass ich am Freitag und nicht erst Samstagmorgen angereist bin.
Ankunft und Location
Nachdem ich endlich das richtige Gebäude gefunden hatte und mich angemeldet hatte, gab es wie auch im letzten Jahr ein sehr tolles T-Shirt. Vor der ersten Session wollte ich mich noch schnell mit einem Cappuccino stärken. Das hätte ich lieber gelassen, denn er war ein löslicher, der mit viel zu wenig Wasser aufgegossen eigentlich ungenießbar war und mir noch 5 Stunden später einen unangenehmen Nachgeschmack bescherte. Die Räume der Uni, die für das WordCamp gebucht waren, hatten eine recht gute Einrichtung. Nur an die wippenden Stühle konnten sich so manche Teilnehmer nicht gewöhnen. Ich fand sie super bequem.
Auf zum WordCamp 2011 am 24.09.2011 in Köln
Es ist wieder soweit. Morgen findet das diesjährige WordCamp Deutschland in Köln statt. Eigentlich wäre ich dieses Jahr nicht mit dabei gewesen, aber glücklicherweise hat sich dann gestern doch noch die Gelegenheit ergeben. Es waren zwar schon alle Plätze weg, aber fragen kostet ja bekanntlich nichts und so konnte ich den Platz eines Teilnehmers einnehmen, der kurzfristig abgesagt hatte.
Dann ging es nur noch darum eine günstige Verbindung nach Köln zu bekommen. Und nun sitze ich im Zug Richtung Köln und freue mich schon auf viele spannende Themen rund um WordPress.
Sollte wie auch im letzten Jahr der ein oder andere von euch auch mit dabei sein, dann treffen wir uns ja morgen wieder. Alle anderen kann ich nur damit vertrösten, dass ich auch dieses Mal wieder meine Eindrücke mit euch teilen und die besten Tipps nochmals hier vorstellen werde.
Lokalisierung für Child Themes am Beispiel von Thematic
In einem der Blogs, die ich betreue wird Thematic eingesetzt. Vor kurzem wollte ich das Thematic Theme selbst aktualisieren, da es bereits einge Versionen alt war. Wir hatten aber damals den “Core” von Thematic verändert, genauer gesagt die deutsche Überstetzungsdatei. Das war natürlich nicht sehr elegant und es rächt sich, weil man dann nicht gefahrlos ein Update installieren kann. Zuerst sah ich aber keine andere Lösung, als die Übersetzung zu sichern und nach einem Update auf die neue Thematic-Version die geänderte Übersetzungsdatei wieder in die neue Version zu kopieren.
Aber ich war mit dieser Lösung überhaupt nicht zufrieden. Bei meiner Arbeit mit WordPress arbeite ich NIE im Core. Sollte es zu einem Problem mal wirklich keinen HOOK geben, dann versuche ich nach Möglichkeit die Funktionalität aus dem Core zu kopieren um bei einem Update ohne Gefahr dieses einspielen zu können. Bei der Anpassung von Übersetzungen eines Themes ist das aber wieder eine andere Sache. Das geht leider nicht ohne weiteres. Verwendet man allerdings ein Theme-Framework wie Thematic, für das man ein Child-Theme erstellen kann, dann gibt es dazu eine recht einfache Lösung.
Einschleusung von Schadcode in drei beliebte WordPress Plugins und die Folgen
Heute Morgen habe ich nach dem Einloggen ins Backend für meinen Blog wieder die Meldung bekommen, dass unter anderem für das Plugin WPtouch ein Update vorliegt. Ich installiere diese in der Regel immer direkt und prüfe anschließend, ob noch alles wie vorher funktioniert.
Mittags habe ich dann bei Golem.de erfahren, wieso WPtouch aktualisiert wurde. Bei drei bekannten Plugins (neben WPtouch waren es AddThis und W3 Total Cache) wurde Schadcode in das SVN Repository eingeschleust. Wie genau es dazu kam ist nicht bekannt. Es ist aber zu vermuten, dass die Passwörter der Plugin-Autoren geknackt wurden. Details zu den Schäden, die der Schadcode hätte anrichten können, wird zur Zeit vom WordPress Team geprüft.
Seitentitel im Thematic Theme anpassen mit dem thematic_doctitle Filter
Ich nutze für einen Blog das Thematic Theme. Es stellt die Grundlage für eigene sogenannte Child Themes bereits und kann in vielfältiger Weise angepasst werden. Thematic stellt zusätzlich zu den normalen WordPress Actions und Filtern eigene Theme Action Hooks und Theme Filter bereit.
Einige davon sind auch sehr gut dokumentiert oder es gibt Beispiele im Netz dazu. Ich wollte auf dem Blog nun aber einen Text an den Seitentitel (also den Text innerhalb der <title> Tags im <head>) jeder einzelnen Seite anhängen. Zwar wird die Funktion thematic_doctitle() auf der Seite der Theme Filter ausführlich in einem Beispiel behandelt, ich konnte mir aber nicht vorstellen, dass es so kompliziert und mit so vielen Zeilen Quellcode geschrieben werden muss. Daher bin ich mal wieder in den Quellcode eintauchen um die entsprechende Stelle zu finden, an der die Funktion definiert ist.
Das WP-Instant Plugin für euer Theme anpassen
Ihr habt bestimmt alle schon die tolle neue Funktion von Google, die “Instant Suche” ausprobiert oder zumindest davon gehört. Da das wirklich eine tolle Funktion ist, habe ich mich entschlossen ein solches Plugin auch für die WordPress Community zu programmieren. Das ist aber trotz der ernormen Erweiterbarkeit von WordPress garnicht so einfach gewesen. Leider hat es ein Laie, der bisher noch keine Berührung mit Themes hatte, hier wohl auch schwer, das Plugin zum Laufen zu bekommen, da er zumindest zweimal etwas tiefer in den Quellcode einsteigen muss.
Zuerst einmal muss die originale “Search Loop” in eine Datei mit dem Namen wp-instant-search-template.php kopiert werden. Diese Datei muss dann in euer Theme Verzeichnis kopiert werden. Die “Search Loop” findet ihr in aller Regel in einer Datei mit dem Namen search.php in eurem Theme Verzeichnis. Er könnte z.B. wie folgt aussehen (aus dem alten “Default” Theme):
