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

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.

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.

Die Sicherheitslücke

Die Sicherheitslücke bestand darin, dass das Plugin auch relative Verzeichnispfade akzeptierte. So konnte ohne weiteres die „wp-config.php“ Datei angefordert werden. Da hier alle Zugangsdaten in Klartext gespeichert sind und der Blog zusätzlich auch noch für den FTP-Account die gleichen Zugangsdaten nutzte, konnte der Angreifer ohne Probleme eigene Dateien hochladen. Ein böser Hacker hätte das ausnutzen und beliebigen Schadcode ausführen können (allerdings wohl nicht mit Administrationsrechten).

Der Autor des Plugins hat den Fehler mittlerweile behoben. Es gibt aber leider noch sehr viele Blog, die noch die unsichere Version verwenden. Diejenigen von euch, die auch dieses Plugin einsetzen, sollten also sofort auf die neueste Version updaten.

Weitere Beispiele für bekannte Sicherheitslücken

Im August wurde ein Sicherheitsproblem in der Funktion timthumb bekannt. Dabei war es einem Angreifer möglich eine beliebige Datei in ein System einzuschleusen. Damit konnte der Angreifer dann beliebigen Schadcode auf dem infizierten System ausführen. Da die timthumb Funktion von sehr vielen Themes verwendet wird, waren sehr viele Blogs angreifbar. Hier kommt erschwerend hinzu, dass für jedes Theme ein eigenes Sicherheitsupdate notwendig war, da fast alle Themes die Funktion direkt in das Theme integriert haben und somit auch die Sicherheitslücke nicht zentral für alle Themes geschlossen werden konnte. Im WordPress Repository findet man daher das Plugin Timthumb Vulnerability Scanner, mit dem man seinem Blog auf die noch offene Sicherheitslücke hin untersuchen kann. Damals wurde glücklicherweise von WordPress Deutschland Team und auch bei heise.de davon berichtet, so dass viele auf die Sicherheitslücke aufmerksam wurden.

Fazit

Es ist durch Plugins sehr einfach möglich die Funktionalität seines Blogs zu erweitern. Aber es ist leider auch sehr einfach möglich, seinen Blog dadurch einem erhöhten Sicherheitsrisiko auszusetzen. Es sollte nun niemand in Panik verfallen und alle Plugins deinstallieren. Es soll nur ein Appell sein die Updates, die für die diversen Plugins ständig im Backend angeboten werden auch zu installieren. Die meisten Plugin-Autoren pflegen auch ein Changelog, in dem man nachlesen kann, welche Änderungen die neue Version enthält. Aber in der Regel werden dadurch Fehler oder eben Sicherheitslücken geschlossen. Als zusätzliche Maßnahme sollte man eine regelmäßige Sicherung seines Blogs durchführen. Dazu teste ich seit ein paar Wochen BackWPup. Ich werde euch demnächst ausführlich darüber berichten.

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.

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.

Die ersten Sessions

Meine erste besuchte Session hatte das Thema „Ecommerce Lösungen für WordPress“ die ich vor Allem deshalb besucht habe, um mal von Experten zu erfahren, ob es wirklich keine guten Shop-Plugins für WordPress gibt. Diese Annahme wurde im Großen und Ganzen bestätigt, da viele der Plugins einfach nicht optimal an das deutsche Rechtssystem angepasst sind. Aber als Nischenprodukte für Kleinunternehmen war schon was dabei. Ansonsten nutzt man eher eine ausgewachsene Shop-Software und versucht diese einfach soweit es geht an das Layout des eigenen WordPress-Blogs anzupassen.

Anschließend ging es in die Session „Hook me!“ die hoffnungslos überfüllt war. Nicht ganz ohne Grund, stellen doch Filter und Actions die mächtigsten Waffen im Umgang mit WordPress da. Dort wurden auch einige meiner ewig offenen Fragen beantwortet. Aber sehr ins Detail ging er Referent leider nicht um nicht mit einem Beispiel die Verwendungsmöglichkeiten zu stark einzuschränken. Im Grunde kann man mit Hooks (fast) alles anstellen und das konnte er auch gut vermitteln.

Die letzte Session vor der Mittagspause drehte sich um das Thema „Kundenprojekte mit WordPress als CMS“. Dies beinhaltete einen fast einstündigen Vortrag über Projektmanagement und den richtigen Umgang mit Kunden. Aber die Fallbeispiele am Ende der Session haben meine erste Enttäuschung doch noch gemildert.

Mittagspause

Da es vormittags nur Obst und Süßigkeiten gab war ich praktisch ohne echtes Frühstück in den Tag gestartet. Umso schöner war es dann, zum Mittag eine große Auswahl an belegten Brötchen vorzufinden. Jeder, der sich über die 10€ Gebühr aufregt (die komplett an eine gemeinnützige Organisation gespendet werden), der hat wohl spätestens jetzt keine Argumente mehr gefunden. Da das Wetter auch mitspielte machten es sich einige Teilnehmer draußen auf der Wiese bequem. Gut gestärkt konnte ich mich also in die zweite Hälfte des WordCamp stürzen.

Die improvisierte zweite Hälfte

Die erste Session „Formular-Plugins im Vergleich“ war schon eine viertel Stunde vorher sehr gut gefüllt. Leider konnten selbst Suchaufrufe über Twitter den Referenten nicht beibringen. Jeder Teilnehmer der rein kam wurde gleich als möglicher Referent gefeiert. Die Leitung las wohl auch die Twitter Posts und teilte uns dann mit, dass der Referent leider krank sei und nicht abgesagt hatte. Ganz spontan meldete sich dann aber ein Teilnehmer als Moderator für eine offene Diskussion, bei der verschiedene Teilnehmer ihre Erfahrungen zu den diversen Plugins vorstellten. Die Plugins mit cformsII und Formidable Forms bekamen dabei den größten Zuspruch der Teilnehmer. Aber auch Fast Secure Contact Form bekam gute Kritiken, nicht nur als Kontaktformular.

Anschließend besuchte ich die Session „Was kann man mit WordPress machen?“ von den Jungs von inpsyde. Sie stellten ein paar Lösungen vor, die sie mit WordPress umgesetzt haben. Was BuddyPress angeht haben sie echt ein paar super coole Features entwickelt. Bei der Vorstellung einer komplett „ajaxifizierten“ Seite war ich dann aber doch an ein Projekt erinnert, das bei dem ich selbst eine ähnliche oder sogar noch erweiterte Funktion umgesetzt habe. Zuletzt konnte man ihnen Fragen stellen, die einem schon lange im Kopf rumschwirren. Aber auf meine Frage, ob man innerhalb von THE LOOP erkennen könne, den wievielten Post man gerade ausgibt, hatten sie auch nur eine ähnlich unbefriedigende Lösung wie ich selbst parat: Mit einer externen globalen Zählvaribalen.

Im Anschluss an diese sehr interessante Session zog es mich in die „Übersetzerrunde“, die allerdings nur aus vier Personen bestand. Also unterheilten wir uns fast eine Stunde lang um die Problematik der deutschen Community. Zuletzt lernten wir dann aber doch alle noch etwas dazu, und zwar, dass man Übersetzungen auch auf einen Kontext beziehen kann. Das wird in WordPress mit der Funktion _x() realisiert.

Zum Abschluss des WordCamp besuchte ich die Session „Geld verdienen mit WordPress“, die auch wieder zu einer Diskussionsrunde erklärt wurde, da auch hier der Referent nicht anwesend war. Ich habe hier aber einige sehr interessante Möglichkeiten kennengelernt, die mir früher noch nie in den Sinn gekommen sind. So habe ich mich gestern bei der VG Wort angemeldet. Somit erhalte ich bei ausreichend Aufrufen eines Artikels Tantiemen als Autor von der VG Wort. Dass so etwas mit Blogs überhaupt möglich ist und man nur 1500 Aufrufe pro Jahr und Artikel benötigt, hätte ich nicht gedacht. Andere Tipps, abgesehen von klassischer Werbung, waren der Verkauf von Link oder auch Support-Leistungen wie Video-Trainings, Schulungen, Wartung von Blogs und ähnliches. Für den seit einiger Zeit bei mir zu findenden Flattr-Button gab es aber keine Zustimmung. Er scheint wohl im deutschen Markt wirklich noch nicht angekommen zu sein. Daher werde ich ihn wohl bald wieder entfernen und dadurch das Laden meines Blogs wieder beschleunigen.

Fazit

Damit endete dann auch schon das diesjährige WordCamp. Es waren zwar nicht wirklich viele WordPress-Entwickler-Themen dabei, aber so konnten auch Einsteiger oder Blog-Autoren auf einem angenehmen Niveau neues lernen. Ich habe trotzdem einige neue Tricks gelernt und kann damit nur sagen, dass ich auch im nächsten Jahr wieder teilnehmen werde, wenn es sich zeitlich einrichten lässt. Leider wurde noch nicht gesagt, wo es im nächsten Jahr stattfinden wird.

Ich hoffe euch hat die kleine Zusammenfassung einen guten Eindruck zum WordCamp vermitteln können. Wenn ihr zu einer bestimmten Session noch mehr Informationen haben möchtet, dann hinterlasst doch einfach einen kurzen Kommentar.

Ach ja, fast hätte ich es vergessen: Meine Rückfahrt von Köln verlief leider auch nicht wie geplant. Dieses Mal fiel aber gleich der ganze ICE aus, da ein Defekt am Triebwagen vorlag. So kam ich auch bei der Rückfahrt über eine Stunde zu spät in Berlin an. Aber immerhin gab es so insgesamt 25% des Fahrpreises zurückerstattet. Trotzdem hoffe ich, dass es im nächsten Jahr mal wieder reibungslos verläuft

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.

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.

Die Problemstellung

Für den Blog wollten wir den String “Tag Archives:” in “Schlagwort:” übersetzen. Die normale Übersetzung hierfür in Thematic ist “Tag-Archiv:”. Der erste Anstz war wie schon erwähnt das Bearbeiten der originalen Übersetzungsdatei, was aber zu dem beschriebenen Update Problem führt.

Die Lösung

Seit der Einführung von Child-Themes gibt es die Möglichkeit auch eine Übersetzungsdatei für ein Child-Theme zu laden. Dazu wird die Funktion load_child_theme_textdomain() verwendet, die allerdings noch nicht in Codex dokumentiert ist. Als ersten Parameter erwartet die Funktion eine Domain, also einen String, der auch in den Übersetzungsfunktionen verwendet wird. Sehen wir uns dazu folgendes Beispiel an:

$content = __('Tag Archives:', 'thematic');

In diesem Beispiel ist der zu übersetzende String “Tag Archives:” und die Domain ist “thematic”. Normalerweise verwendet man für sein Child-Theme eine eigene Domain, aber man kann auch die Domain “thematic” verwenden. Genau das ist auch der Trick, um eine Übersetzung von Thematic zu überschreiben. Wir verwenden einfach eine eigene Child-Theme Übersetzungsdatei zum überschreiben bestehender Strings.

Der zweite Parameter der Funktion load_child_theme_textdomain() ist optional und gibt den Pfad zur Übersetzungsdatei an. Wenn sich diese direkt in eurem Child-Theme-Ordner befindet, dann müsst ihr ihn nicht angeben. In unserem Blog haben wir aber einen Ordner “languages” erzeugt, in dem die Übersetzungen liegen. Wir müssen daher den absoluten Dateipfad zu diesem Ordner angeben. Den absoluten Pfad zum Child-Theme Ordner liefert uns die Funktion get_stylesheet_directory(). Das einbinden unserer Übersetzungsdatei sieht also wie folgt aus:

load_child_theme_textdomain('thematic', get_stylesheet_directory() . '/languages' );

Das ist auch schon alles. Mit dieser einem Zeile in der Datei “functions.php” eures Child-Themes könnt ihr eure eigene Übersetzungsdatei einbinden. Wie ihr seht verwende ich hier die Domain “thematic” um auch die Übersetzungen von Thematic überschreiben zu können. Ihr müsst dazu auch nicht den gesamten Inhalt der Übersetzungsdatei aus Thematic in eure kopieren. Es reicht aus, wenn ihr nur die zu ändernden Strings einfügt. Ihr könnt selbstverständlich auch eigene Strings einfügen, die ihr eventuell in eurem Child-Theme verwendet. Dabei müsst ihr dann nur in der Übersetzungsfunktion ebenfalls “thematic” als Domain angeben.

Ich hoffe, der Tipp konnte euch zeigen, was man mit Child-Themes alles machen kann und wieso die Verwendung eines Thema-Frameworks die Individualisierung eures Themes nicht unbedingt einschränkt. Mein Blog wir eventuell im Laufe des Jahres auch ein neues Design bekommen und mit den bisher gesammelten Erfahrungen zu Thematic, werde ich wohl auch hierfür auf ein Child-Theme setzen und nicht auf ein komplett eigenes Theme. Über Kritik und Kommentare würde ich mich wie immer sehr freuen.

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.

Die Folgen

Wie bei Golem.de nachzulesen war, wurden die Passwörter zurückgesetzt. Ich ging zuerst davon aus, dass es sich nur auf die Passwörter der drei Plugins bezieht. Bei einer kleinen Überarbeitung einer meiner Plugins musste ich dann aber feststellen, dass die Passwörter aller WordPress Nutzer zurückgesetzt wurden. Ich habe also auch meines zurückgesetzt und dabei auf ein sichereres geändert.

Nachdem ich mit meinen Änderungen fertig war und diese per Commit in das SVN Repository gestellt habe wurde ich dann natürlich erst einmal nach dem neuen Passwort gefragt. Ein paar Sekunden später hatte ich auch schon eine Mail von WordPress in meinem Postfach. Darin war der Commit inklusive des Changelogs zu finden. Mit dieser Maßnahme wird zwar nicht verhindert, dass Schadcode ins Repository eingeschleust wird. Aber da es ca. 10min dauert, bis eine neue Version auch den Nutzern zum Download angeboten wird, sollte es dem Plugin-Autoren möglich sein, den Code wieder raus zu nehmen.

Fazit

Niemand darf blind einem Plugin vertrauen, auch wenn es von einem seriösen Entwickler stammt. Aber es ist vorbildlich, wie WordPress auf diesen “Einbruch” reagiert hat. WordPress ist noch immer eine der sichersten CMS- und Blogging-Systeme, wie verschiedene Test immer wieder zeigen. Auch durch die sehr aktive Community werden solche Sicherheitslücken in Zukunft vermutlich sehr schnell gefunden und behoben.

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.

Der thematic_doctitle Filter

Der Quellcode zum Filter befindet sich in der Datei “wp-content/themes/thematic/library/extensions/header-extensions.php” ab Zeile 26 (in Thematic Version 0.9.6.2). Der interessante Teil sieht wie folgt aus:

	// Filters should return an array
	$elements = apply_filters('thematic_doctitle', $elements);

	// But if they don't, it won't try to implode
	if(is_array($elements)) {
		$doctitle = implode(' ', $elements);
	}
	else {
		$doctitle = $elements;
	}

	$doctitle = "\t" . "<title>" . $doctitle . "</title>" . "\n\n";

	echo $doctitle;

Wie ich also feststellen konnte, kann die Rückgabe eines eigenen Filters entweder ein String oder ein Array sein. Sollte es ein Array sein, werden die einzelnen Elemente mit Hilfe der implode() Funktion zu einem String verbunden. Ich habe zusätzlich den Inhalt des Arrays analysiert. Je nach Seite besteht es nur aus einem einelementigen Array oder aber auch mehreren Teilen, die durch einen “Separator” voneinander getrennt werden.

Den Titel mit einer Funktion erweitern

Im Grunde war es aber für meine Zwecke unerheblich, wie es aussieht, da ich nur etwas hinten anfügen wollte. Also habe ich eine einfache Funktion geschrieben, die den Titel mit Hilfe des Filters erweitert:

function my_doctitle($doctitle) {
	return array_merge($doctitle, array('suffix' => '| example.com'));
}
add_filter('thematic_doctitle','my_doctitle');

Diese kleine Funktion fügt dem Array $doctitle ein Array mit dem Schlüssel “suffix” hinzu. Mit der array_merge() Funktion wird es mit dem originalen Array zu einem neuen “gemerged” und direkt wieder zurückgegeben.

Fazit

Statt also laut dem Beispiel im Guide zum Thematic Theme den Filter thematic_doctitle fast komplett zu kopieren um dann nur einen kleinen String anzuhängen, hat es sich mal wieder ausgezahlt sich mit dem Quellcode zu beschäftigen. So konnten wir in nur vier Zeilen das gewünschte Ergebnis erzielen.

Da ich sehr viele Filter und Action Hooks in meiner functions.php Datei verwende, lohnt es sich umso mehr nachzuschauen, ob es nicht auch einfacher geht. Sonst habe ich nämlich am Ende die Hälfte (oder sogar mehr) der verwendeten Filter aus dem Thematic Theme in meine functions.php kopiert, ohne es wirklich zu müssen.

Ich hoffe ich konnte euch einmal mehr zeigen, dass man sich nicht davor scheuen sollte auch mal den Quellcode eines Produkts zu studieren, das man verwenden und erweitern möchte. Mir hat es nicht nur in diesem Fall viel Arbeit gespart.

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

<?php
/**
 * @package WordPress
 * @subpackage Default_Theme
 */

get_header(); ?>

	<div id="content" class="narrowcolumn" role="main">

	<?php if (have_posts()) : ?>

		<h2 class="pagetitle">Search Results</h2>

		<div class="navigation">
			<div class="alignleft"><?php next_posts_link('&laquo; Older Entries') ?></div>
			<div class="alignright"><?php previous_posts_link('Newer Entries &raquo;') ?></div>
		</div>

		<?php while (have_posts()) : the_post(); ?>

			<div <?php post_class() ?>>
				<h3 id="post-<?php the_ID(); ?>"><a href="<?php the_permalink() ?>" rel="bookmark" title="Permanent Link to <?php the_title_attribute(); ?>"><?php the_title(); ?></a></h3>
				<small><?php the_time('l, F jS, Y') ?></small>

				<p class="postmetadata"><?php the_tags('Tags: ', ', ', '<br />'); ?> Posted in <?php the_category(', ') ?> | <?php edit_post_link('Edit', '', ' | '); ?>  <?php comments_popup_link('No Comments &#187;', '1 Comment &#187;', '% Comments &#187;'); ?></p>
			</div>

		<?php endwhile; ?>

		<div class="navigation">
			<div class="alignleft"><?php next_posts_link('&laquo; Older Entries') ?></div>
			<div class="alignright"><?php previous_posts_link('Newer Entries &raquo;') ?></div>
		</div>

	<?php else : ?>

		<h2 class="center">No posts found. Try a different search?</h2>
		<?php get_search_form(); ?>

	<?php endif; ?>

	</div>

<?php get_sidebar(); ?>

<?php get_footer(); ?>

Hiervon benötitg ihr den teil innerhalb des DIV mit der ID “content”. In der Regel startet die “Search Loop” mit if(have_posts()) und endet mit endif;. Aus dem Beispeil müssen also die Zeilen 11-41 in die Datei “wp-instant-search-template.php” kopiert werden.

Ist dieser Schritt getan, erzeugt die Instant Suche bereits die korrekte Ausgabe. Diese muss aber nun auch noch in das richtige DIV eingefügt werden. Die ID dieses DIV können wir auch recht einfach aus dem Beispiel-Quellcode ablesen. Es handelt sich natürlich um den Wert “content” da wir im vorherigen Schritt den Inhalt eben dieses DIVs kopiert haben. Diese ID wird nun in der Einstellungs-Seite des Plugins eingetragen:

Damit sollte dann die Einstellung des Plugins auch schon abgeschlossen sein. Sollte es bei euch doch nicht funktionieren oder ihr auf Probleme mit eurem Plugin stoßen, dann hinterlasst bitte einfach auf diesem Post oder auf dem Post zu dem Plugin selbst einen Kommentar. Für Anregungen zur Verbesserung des Plugins bin ich natürlich auch offen.

Eine detailiertere Beschreibung zur Einrichtung des Plugins findet ihr hier: Das WP-Instant Plugin für euer Theme anpassen

Installation:

Installation über die WordPress Adminstrator-Seiten:

1. Gehe zur Admin-Seite Plugins -> Installieren
2. Suche nach kau-boy und wähle das Plugin aus
3. Wähle die Aktion Jetzt installieren
4. Klicke auf Jetzt installieren
5. Aktiviere das Plugin über den Plugins Menüpunkt in WordPress
6. Du musst eventuell die Einstellungen anpassen, vor allem den Wert für die “Inhalts Tag ID”
7. Erzeuge eine Datei mit dem Namen “wp-instant-search-template.php” und kopiere die “Search Loop” innerhalb des “Inhalts Tags” hinein

Installation unter Verwendung der WordPress Adminstrator-Seiten:

1. Lade die zip-Datei des Plugins herunter: wp-instant.1.1.zip
2. Gehe zur Admin-Seite Plugins -> Installieren
3. Wähle den Link Hochladen unter Plugins Installieren Überschrift
4. Wähle die zip-Datei aus und klicke Jetzt installieren
5. Aktiviere das Plugin über den Plugins Menüpunkt in WordPress
6. Du musst eventuell die Einstellungen anpassen, vor allem den Wert für die “Inhalts Tag ID”
7. Erzeuge eine Datei mit dem Namen “wp-instant-search-template.php” und kopiere die “Search Loop” innerhalb des “Inhalts Tags” hinein

Installation unter Verwendung von FTP

1. Lade die zip-Datei des Plugins herunter: wp-instant.1.1.zip
2. Entpacke es und lade es in dein /wp-content/plugins/ Verzeichnis hoch
3. Aktiviere das Plugin über den Plugins Menüpunkt in WordPress
4. Du musst eventuell die Einstellungen anpassen, vor allem den Wert für die “Inhalts Tag ID”
5. Erzeuge eine Datei mit dem Namen “wp-instant-search-template.php” und kopiere die “Search Loop” innerhalb des “Inhalts Tags” hinein

Versionsgeschichte:

• 1.1 Fehler mit uninitialisierten Variablen behoben
• 1.0 Einsatz von AJAX, so wie es hier beschrieben wird: http://codex.wordpress.org/AJAX_in_Plugins
• 0.2 Verwendung von STYLESHEETPATH als primärem Ordner für die Suche nach einem Suchtemplate
• 0.1 Erste stabile Version

Wenn dir dieses Plugin gefällt oder dir etwas fehlt, würde ich mich freuen es zu erfahren. Hinterlasse einfach ein Kommentar auf dieser Seiter oder auf meiner WordPress Plugin Seite.

Eine Anleitung zur Migration der Daten ist schon vorhanden. Damit der Einstieg für neue Nutzer von WordPress auch ohne große Frustration abläuft, stellt WordPress.com einige Tutorials und Hilfen bereit.

Ich finde das für die WordPress Community großartig. Eventuell stellen einige Nutzer von “Windows Live Spaces” fest, dass es Dinge gab, die es in WordPress noch nicht gibt und wir bekommen damit eine noch bessere Software. Ich bin auch gespannt, ob die Erstellung von Artikeln mit Office Produkten aus dem Hause Microsoft in Zukunft um Funktionen für WordPress erweitert wird. Ich komme zwar mit WordPress super klar und nutze hier immer den HTML-Modus, aber die Einstiegshürde kann gerade für nicht so internetaffine Benutzer durch eine Integration in bekannt Programme (wie z.B. Microsoft Word) noch verringert werden.

Was haltet ihr von der Ankündigung? Seit ihr vielleicht sogar “Windows Live Spaces” Nutzer und gar nicht froh über diesen Schritt? Ehrliche Kommentare (auch kritische) sind wie immer gern gesehen.

Wartungsmodus vorher

Während des Updates eurer WordPress Installation, eines Themes oder Plugins, bzw. bei der Installation neuer Themes oder Plugins wird WordPress automatisch in einen Wartungsmodus versetzt, damit keine Schäden an eurem Blog auftreten. Dabei wir eurem Benutzer aber eine sehr unschöne Nachricht angezeigt, die wie folgt aussieht:

Ich habe hier den deutschen Text als Screenshot, aber bei meinem zweisprachigen Blog erscheint immer der englische Text, egal welche Sprache der Nutzer verwendet. Aber abgesehen davon ist die Nachricht mit besonders hübsch.

Testen und kontrollieren des Wartungsmodus

Gesteuert wird der Wartungsmodus übrigens über eine Datei mit dem Namen .maintenance die von WordPress bei der Installation mit folgendem Inhalt im ROOT-Verzeichnis eures Blogs abgelegt wird:

<?php $upgrading = 1281043765; ?>

Der Timestamp hier gibt an, wann das Update gestartet wurde. Solltet ihr euren Wartungsmodus einmal testen wollen, könnt ihr einfach eine entsprechende Datei erzeugen und den Timestamp auf den aktuellen Wert setzen. Dazu einfach anstelle einer Zahl die Funktion time() verwenden, es sei denn, eure innere Uhr kennt immer den aktuellen Timestamp Denkt aber daran sie später wieder zu löschen. Ihr solltet auch nach jedem Update kontrollieren, ob euer Blog wieder funktioniert. Wie ich heute auf dem Blog von perun.net nachlesen konnte, ist es schon einigen Blogbesitzern passiert, dass die Datei nach dem Update nicht gelöscht wurde. Das kann schnell mal passieren, wenn man z.B. den Tab mit dem Update aus Versehen löscht. Glücklicherweise wird aber nach 10 Minuten der Blog wieder angezeigt, da WordPress dann davon ausgeht, dass das Löschen der Datei gescheitert ist.

Verschönern des Wartungsmodus

Jetzt aber zum eigentlich interessanten Teil des Artikels. Nachdem ich die Standardmeldung im Quellcode von WordPress ausgemacht hatte, fand ich in dem Kommentar der Funktion auch einen Hinweis darauf, wie man die Anzeige mit sehr einfachen Mitteln verschönern kann. Dazu ist es lediglich notwendig eine Datei mit dem Namen maintenance.php im Ordner wp-content abzulegen. Da man hier auch eine PHP Datei verwenden kann sind, der eigenen Kreativität keine Grenzen gesetzt.

Das Anlegen meiner Seite habe ich wie folgt vorgenommen. Zuerst habe ich eine gewöhnliche WordPress Seite erstellt und mit einem netten Text und einen Comic von xkcd.com gefüllt. Diese Seite habe ich dann kurz freigegeben und nach dem Abmelden vom Admin-Bereich gespeichert, damit auch alle Inhalte zu sehen sind, die ein angemeldeter Besucher nicht sieht. Von dieser Seite habe ich dann den Quellcode gespeichert.

Den Quellcode könnte man nun einfach in die maintenance.php Datei einfügen und im wp-content Ordner ablegen. Da mein Blog aber zweisprachig ist, habe ich zwei HTML-Dateien mit den Namen maintenance-de.htm und maintenance-en.htm und diese beiden im gleichen Ordner abgelegt. Innerhalb der maintenance.php lese ich dann die Sprache des Benutzers aus, und gebe den Inhalt der entsprechenden Datei aus. Wer mal sehen möchte, wie meine Wartungsseite aussieht kann das gerne hier tun: http://kau-boys.de/wp-content/maintenance.php.

Fazit

Der neue Wartungsmodus ist wirklich eine tolle Sache und kann mit sehr wenig Aufwand auch an die eigenen Bedürfnisse angepasst werden. Wer eine statische Kopie einer WordPress Seite verwendet, sollte seine Wartungsseite aber von Zeit zu Zeit aktualisieren, damit sie immer dem aktuellen Layout entspricht.

Ich hoffe, dass der Tipp auch euch weiterhelfen wird und ich würde mich freuen, wenn mir der ein oder andere ebenfalls einen Link zu seiner toll gestalteten Wartungsseite als Kommentar schicken würde.

Jeder Besucher des Blog kann eine Suche zu seinem Browser hinzufügen und so sehr schnell und jeder Zeit nach einem Artikel suchen. Das Plugin muss dabei nicht konfiguriert werden. Einfach installieren und aktivieren.

Installation:

Installation über die WordPress Adminstrator-Seiten:

1. Gehe zur Admin-Seite Plugins -> Installieren
2. Suche nach kau-boy und wähle das Plugin aus
3. Wähle die Aktion Jetzt installieren
4. Klicke auf Jetzt installieren
5. Aktiviere das Plugin über den Plugins Menüpunkt in WordPress

Installation unter Verwendung der WordPress Adminstrator-Seiten:

1. Lade die zip-Datei des Plugins herunter: kau-boys-opensearch.0.1.zip
2. Gehe zur Admin-Seite Plugins -> Installieren
3. Wähle den Link Hochladen unter Plugins Installieren Überschrift
4. Wähle die zip-Datei aus und klicke Jetzt installieren
5. Aktiviere das Plugin über den Plugins Menüpunkt in WordPress

Installation unter Verwendung von FTP

1. Lade die zip-Datei des Plugins herunter: kau-boys-opensearch.0.1.zip
2. Entpacke es und lade es in dein /wp-content/plugins/ Verzeichnis hoch
3. Aktiviere das Plugin über den Plugins Menüpunkt in WordPress

Screenshots:

Screenshot der Autmatischen Erkennung der Suche durch Firefox

Versionsgeschichte:

• 0.1 Erste stabile Version

Wenn dir dieses Plugin gefällt oder dir etwas fehlt, würde ich mich freuen es zu erfahren. Hinterlasse einfach ein Kommentar auf dieser Seiter oder auf meiner WordPress Plugin Seite.

Von Verlauf des WordCamp war ich sehr zufrieden. Meine einzige Vergleichsmöglichkeit war das CakeFest 2009, welches ebenfalls in Berlin stattfand. Im Nachhinein muss ich sagen, dass die Location des CakeFests in der German Language School (GLS) war aber um einiges besser als das betahaus, das zwar einen gewissen Charm hatte, aber dessen Räume doch sehr schlecht für solche Events ausgerüstet waren. Zu allem Überfluss waren die meisten interessanten Sessions im 4.OG und der Aufzug war entweder überfüllt oder jemand hatte mal wieder vergessen, die Tür zu zu machen.

Toll an der Location war dann aber die Übertragung des Viertelfinal-Spiels und die Stimmung, die dabei allgemein herrschte. Aber bei einem 4:0 gegen Argentinien musste die ja auch gut sein. Ich habe mich auch gefreut, dass zu der zeit, als das Spiel stattfand keine Sessions abgehalten wurden. Ärgerlich war es natürlich für alle die nichts mit Fußball anfangen konnten und extra von weit her angereist sind.

Ich hatte ja bereits berichtet, dass ich alle meine Plugins mit den Beta-Versionen und den Release Candidates erfolgreich testen konnte. Nachdem ich eben meinen Blog auf die neue Version aktualisiert habe konnte ich auch mit Freuden feststellen, dass nicht nur meine Plugins, sondern anscheinend auch fast alle Plugins, die ich einsetze mit der neuen Version funktionieren. Einzig qTranslate, das für die Mehrsprachigkeit zuständig ist, wird immer erst mit etwas Verzögerung angepasst.

Nach der Installation konnte ich dann auch gleich mal die neue Update Funktion testen, die nun auch das Aktualisieren von Templates unterstützt. Es ist nun auch nach ganz oben im Menü gewandert und zeigt ähnlich zu der Anzeige für Plugin-Updates eine Gesamtanzahl von verfügbaren Plugins an:

Wie ihr sehen könnte sind einige Punkte noch nicht übersetzt. Aber vermutlich muss ich noch die aktuellen deutschen Sprachdateien für WordPress 3.0 runterladen. Da ich das Theme selbst übersetzt habe, sollten hier alle Texte übersetzt sein.

Ich werde euch natürlich auf dem Laufenden halten, sollten sich Probleme mit einem meiner eigenen Plugins oder mit den Plugins, die ich hier einsetze, ergeben. Falls ihr Probleme findet, würde ich mich natürlich über einen Kommentar in diesem Artikel oder noch besser in den Artikeln zu dem jeweiligen Plugin freuen.

Jetzt bleibt mir nur, uns allen viel Spaß mit dem neuen WordPress zu wünschen.

Last call; final bugs
Itch, scratch, contort; calmly wait
For now: RC3

Gleichzeitig findet sich hier auch die Aufforderung an alle WordPress Plugin Entwickler die eigenen Plugins mit dem Release Candidate 3 von WordPress zu testen. Dem bin ich schon zuvor nachgekommen und kann stolz verkünden, dass ich bisher mit keinem meiner 3 aktuellen Plugins einen Fehler finden konnte.

Da es nur noch 9 aktive offene Tickets gibt bleibt zu hoffen, dass wir bald WordPress 3 auf unseren Blog einsetzen können. Ich bin zumindest schon sehr gespannt darauf.

Da ich mich bei der Entwicklung an bestimmte Standards gehalten habe und keine als DEPRECATED (veraltet) gekennzeichnete Funktion eingesetzt habe, sollten die Plugins dann auch mit der finalen Version von WordPress 3.0 funktionieren. Ich werde aber die NIGHTLY BUILDS in regelmäßigen Abständen testen und eventuell auftretende Fehler noch vor dem Erscheinen der finalen Version von WordPress 3.0 beheben.

Solltet ihr bereits Fehler mit WP 3.0 gefunden haben oder aber einen Fehler mit einer aktuellen Version, dann teilt mir das bitte in einem Kommentar auf den Pluginseiten oder in diesem Post mit.

Ich wünsche uns allen viel Spaß mit den tollen neuen Features von WP 3.0 und hoffe, dass wir sie bald in einer finalen Version genießen können.

Zusätzlich konnte ich auch die Sprachenauswahl auf der Login Seite reparieren. Diese war auch seit irgendeinem Update defekt und man musste dann nachträglich die Sprache innerhalb des Backends wechseln. Das funktioniert jetzt also auch wieder direkt bei der Anmeldung.

Da für WordPress 3.0 schon angekündigt wurde, dass sich für Plugin Entwickler einiges ändern wird hoffe ich, dass meine Mühe nicht umsonst gewesen ist und das Plugin auch mit Version 3.0 noch auf Anhieb funktioniert.

Die neue Version könnt ihr auf meinem Post zum Plugin sowie im Plugin Repository von wordpress.org runterladen. Wer es schon installiert hat kann es wie immer direkt über das Backend komfortabel aktualisieren. Solltet ihr das Plugin bereits vorher verwendet haben, müsst ihr eventuell einmal die Cookies für eure Website löschen, damit das Plugin reibungslos funktioniert.

Danke an dieser Stelle noch einmal an Inaki und Lars für ihre Rückmeldung bezüglich des Fehlers in WordPress MU!

Wer mich also schon immer mal persönlich treffen möchte hat dort die einmalige Gelegenheit dazu. Natürlich lohnt sich ein Besuch des WordCamp auch dann, wenn ihr etwas über die Macher hinter den ganzen Plugins und Themes erfahren möchtet und euch mit Gleichgesinnten austauschen möchtet. Es ist die Gelegenheit eure Fragen und Anregungen mit anderen Nutzern von WordPress zu diskutieren.

Das Programm steht wie immer bei solchen Barcamps im Vorfeld noch nicht fest. Jeder kann auf der Website selbst eine Session zum Programm anmelden. Wenn ihr also ein tolles Thema rund um WordPress habt, dass ihr anderen vorstellen möchtet, dann meldet eure Session an.

Das WordCamp 2010 findet im betahaus statt. Ich finde das die perfekte Location dafür. Es basiert auf dem Prinzip des Coworking. Jeder arbeitet hier zwar für sich, aber statt dich ein eigenes kleines Büro zu mieten und dort alleine und verlassen zu arbeiten, trifft man sich hier mit vielen anderen kreativen Köpfen. Da ich schon immer mal das betahaus besuchen wollte trifft sich das also ganz gut.

Also, wer von euch jetzt Lust bekommen hat auch am WordCamp teilzunehmen sollte sich schnell auf der Website anmelden, da die Teilnehmerzahl auf 200 begrenzt ist. Die Schutzgebühr für das WordCamp beträgt 10€, die aber vollständig an eine gemeinnützige Organisation gespendet werden. Vermutlich ist die Anmeldung nicht kostenlos, damit sich auch nur diejenigen anmelden, die wirklich kommen möchten. Es wäre doch schade, wenn am Ende wie im letzten Jahr ein Viertel von den 200 Angemeldeten nicht kommen.

In diesem Sinne, bis Juli auf dem WordCamp! Und wer mich dann wirklich treffen möchte kann gerne vorher mit mir Kontakt aufnehmen. Am besten hinterlasst ihr hier einen Kommentar