Eigentlich wollte ich hier nur einen kurzen Post über mein neu entdecktes WordPress-Plugin schreiben: Broken Link Checker. Damit kann man alle Links auf seiner Seite durchscannen und testen lassen. Anschließend kann man sich in einer Liste ansehen, welche Links überhaupt nicht mehr funktionieren und welche inzwischen zu einer anderen Adresse weitergeleitet werden. Da das Internet ein recht lebendiges Medium ist, bleibt nicht jeder Link für immer erhalten, und somit ist dies ein sehr empfehlenswertes Plugin für jeden, der tote Links genauso haßt wie ich.

Nun ja, aber während ich diesen Post schrieb, kam mir der Gedanke, daß ich ja einfach mal alle meine Plugins auflisten könnte für jeden, den es interessiert. Bei der Wahl meiner Plugins folge ich zwei Grundregeln, die auch in vielen anderen Bereichen meines Lebens Anwendung finden:

1. „Je spezialisierter, desto besser.“ – Ein Plugin soll immer nur exakt die Lücke füllen, wegen der ich es installiere. Es soll keine Zusatzfunktionen haben, die ich dann nie nutze. Das wäre – wenn auch nur in sehr geringem Maße – Ressourcenverschwendung.
2. „Je weniger, desto besser.“ – Weniger Plugins bedeuten neben einer allgemein besseren Übersicht auch weniger mögliche Fehlerquellen (bzw. im Falle eines Fehlers weniger Orte, an denen man suchen muß).

Ich habe schon ziemlich kleine und „unprofessionelle“ Blogs gesehen, die 50 bis 60 Plugins verwenden, oft für so sinnlose Dinge wie die Anzeige des Wetters im Heimatort. Sicher, Blogs sind zu einem gewissen Teil auch Selbstdarstellung – aber mal ehrlich: Wen interessiert es, ob es bei mir gerade regnet? (Andererseits kommt gleich sicher der Einwand: „Wen interessiert es, was du liest?“ Aber Ihr wißt schon, was ich meine.) Hier nun meine Plugins:

• Akismet – standardmäßig bei WordPress mit dabei; filtert Spam-Kommentare recht effektiv heraus.
• All in One SEO Pack – übernimmt zahlreiche lästige Aufgaben zur Suchmaschinenoptimierung
• Archives for a category – zeigt das Archiv für nur eine einzige Kategorie an; benötige ich für meine WoW-Kategorie
• AWStats Script – dient der Einbindung von AWStats
• Follow-URL (angepasst von Elias Schwerdtfeger) – entfernt das nofollow-Attribut, das WordPress an Links in Kommentaren anhängt
• Get Recent Comments – zeigt die neusten Kommentare und/oder Trackbacks an
• Google XML Sitemaps – generiert bei jedem neuen Post automatisch eine XML-Sitemap und benachrichtigt die größten Suchmaschinen
• HTML Purified – erhöhte Kontrolle über erlaubte und verbotene HTML-Tags in Kommentaren; erlaubt außerdem das Posten von Codeschnipseln zwischen `Backticks` in Kommentaren
• I am reading – zeigt, welches Buch man gerade liest; dieses Plugin wurde einst von mir repariert, als es kaputt war, was schließlich den Anstoß zu einer vollständigen Wiederbelebung gab.
• Lightbox 2 – fügt das Lightbox-Script in das Blog ein und gruppiert automatisch alle Bilder in einem Beitrag zu einer Slideshow
• Linknotes – ein uraltes Plugin, das aber immer noch hervorragend funktioniert und zum Einfügen von „Link-Fußnoten“ dient, beispielsweise um Links als Quellenangaben unter den Post zu setzen; hier ein Artikel, bei dem ich es eingesetzt habe
• NextGEN Gallery – einfache Erstellung und Verwaltung ganzer Bildergalerien
• No Widget Category Cloud – benötige ich, um die hübsche und gut konfigurierbare Kategoriewolke zu erstellen, die man im Archiv sehen kann
• o42-clean-umlauts – ebenfalls ein sehr altes Plugin, das aber nach wie vor einwandfrei funktioniert und Umlaute in Permalinks durch ihre korrekten deutschen Entsprechungen ersetzt. Beispiel: WordPress macht aus „Schöner Titel“ in der URL „schoner-titel“; mit diesem Plugin wird daraus: „schoener-titel“
• qTranslate – ein unglaublich gutes (und wie ich es einschätze auch sehr aufwendiges) Plugin, für das ich dem Autor extrem dankbar bin! Hiermit kann man sein Blog in beliebig viele Sprachen übersetzen.
• WoW Armory (modified) – von mir für einen Privatserver modifizierte Version des Plugins „WoW Armory“, das in meiner WoW-Kategorie zum Einsatz kommt. (Das Original wird leider nicht weiterentwickelt und zeigt daher im Modelviewer alle Charaktere nackt an. Andererseits ist es inzwischen sowieso überflüssig, da das Blizzard Armory nun selbst eine solche Funktion anbietet.)
• Smilies Themer – Wenn man die Standard-WordPress-Smileys nicht mag bzw. sie einfach nicht zum Theme passen, kann man sie hiermit durch vorgefertigte oder selbsterstellte Smiley-Sets ersetzen.
• Text Control – ein Plugin, das wohl nur fortgeschrittene Anwender benötigen; man kann damit die Art, wie WordPress Texte formatiert, verändern oder ganz ausschalten. Ein Beispiel (und einer der Gründe, weshalb ich es installierte): WordPress macht selbst im HTML-Editor aus jedem Zeilenumbruch bzw. jeder Leerzeile automatisch einen Absatz (<p>...</p>). Durch das Deaktivieren des Filters wpautop mithilfe dieses Plugins geschieht das nicht.
• Typographical Improvements – wichtig, wenn man Wert auf Typografie und gute Lesbarkeit legt; wandelt zahlreiche Zeichen in ihre typografisch korrekten Entsprechungen um, z. B. „Anführungszeichen“ statt "Anführungszeichen", lange Gedankenstriche: – statt Minuszeichen: -
  Da die Homepage und somit die Entwicklung des Plugins offenbar eingestellt wurde, zeigt der Download-Link auf meine Version hier auf dem Server.
• WordPress.com Stats – ein von den WordPress-Entwicklern selbst herausgegebenes Plugin, das im Admin-Bereich die meistgelesenen Posts anzeigt, woher die Besucher kamen und über welche Links sie die Seite wieder verlassen
• WordPress Related Posts – zeigt unter einem Post Links zu passenden ähnlichen Posts an
• wordTube – vom selben Autor wie die „NextGEN Gallery“; dient dem Einfügen von Musik, Videos oder Flash bzw. ganzer Playlisten in einen Post
• WP-SpamFree – eins meiner wichtigsten Plugins überhaupt! Akismet allein läßt immer noch massenhaft Spam durch und legt ihn in einem Spam-Ordner ab, den man dann zur Sicherheit noch einmal von Hand komplett durchsehen muß, damit man keine „false positives“ löscht. Dieses Plugin dagegen hindert Spambots bereits am Posten. Auf diese Weise bekomme ich statt über 1000 jetzt weniger als 1 Spam-Kommentar im Monat.
• WP-Syntax – zum hübsch formatierten Posten von Quellcodes mit Syntax-Highlighting; unterstützt zahreiche Programmiersprachen

Hier sind noch zwei weitere Plugins, die zwar nicht auf dieser Seite eingesetzt werden, mir aber auf einigen anderen schon von großem Nutzen waren:

• Contact Form 7 – zur Erstellung beliebig vieler Kontaktformulare, sehr gut anpaßbar an jedes Design, benutzerdefinierte Eingabefelder möglich
• TinyMCE Advanced – benötige ich selbst nicht, da ich ausschließlich im HTML-Editor arbeite, ist aber für alle, die kein HTML beherrschen, fast unverzichtbar! Das Plugin erweitert den visuellen Editor um einige Möglichkeiten, die einem Laien ansonsten verwehrt bleiben würden (Beispiel: Tabellen).

Doch wie immer dachte ich mir: „Mensch, das muß doch auch so gehen!“ Und das tut es auch! Mit ein paar wenigen Codezeilen kann man seine Top-Posts vom WordPress-Stats-Plugin an jeder beliebigen Stelle seines Templates einbinden, ganz ohne irgendein zusätzliches Plugin!

Und so geht’s:

1
2
3
4
5
6
7
8
9
10
11
12

<?php if(function_exists('stats_get_csv')) : ?>
	<h3>Beliebte Artikel</h3>
	<ul id="popularposts">
	<?php
		$top_posts = stats_get_csv('postviews', 'days=-1&limit=5');
		foreach($top_posts as $post) {
			if(!get_post($post['post_id']) || empty($post['post_id'])) continue;
			echo '<li><a href="'.get_permalink($post['post_id']).'">'.get_the_title($post['post_id']).'</a><div class="commentsnumber">('.get_comments_number($post['post_id']).' Kommentare)</div></li>';
		}
	?>
	</ul>
<?php endif; ?>

Kurze Erläuterung

• Zeile 1: Die ganze Liste wird nur erstellt, wenn das WordPress-Stats-Plugin installiert und aktiviert ist.
• Zeile 5: Hier wird definiert, welche bzw. wie viele Posts angezeigt werden sollen. Stellt man „days“ auf –1, bekommt man die Top-Posts der gesamten Zeit, in der das Stats-Plugin Daten gesammelt hat. Stellt man es aber z. B. auf 7, bekommt man die Top-Posts der letzten sieben Tage. Der Wert „limit“ gibt an, wie viele Posts man anzeigen möchte. In dem Beispiel werden also die fünf beliebtesten Posts angezeigt.
• Zeile 8: Hier erfolgt die Ausgabe des Links mit Anzahl der Kommentare. Natürlich kann man das HTML je nach Bedarf noch anpassen.

<?php if(function_exists('stats_get_csv')) : ?>
	<h3>Beliebte Artikel</h3>
	<ul id="popularposts">
	<?php
		$top_posts = stats_get_csv('postviews', 'days=-1&limit=10');
		$i = 0;
		foreach($top_posts as $post) {
			if(!get_post($post['post_id']) || empty($post['post_id']) || in_array($post['post_id'], array(1, 17, 25, 39))) continue;
			echo '<li><a href="'.get_permalink($post['post_id']).'">'.get_the_title($post['post_id']).'</a><div class="commentsnumber">('.get_comments_number($post['post_id']).' Kommentare)</div></li>';
			$i++;
			if($i >= 5) break;
		}
	?>
	</ul>
<?php endif; ?>

Das Problem bestand darin, daß im Kommentar-Formular ein versteckter Input fehlte, der bei WordPress aber immer vorhanden sein muß:

<input type="hidden" name="comment_post_ID" value="<?php echo $post->ID; ?>" />

Wenn man also nach dem Abschicken eines Kommentars andauernd eine weiße Seite bekommt, sollte man mal nachsehen, ob man in seinem Kommentar-Template (normalerweise ist das die Datei comments.php im Verzeichnis des betreffenden Themes) diese Zeile evtl. vergessen oder an einer falschen Stelle eingefügt hat.

In meinem Fall war es z. B. so, daß ich die Zeile an einer falschen Stelle innerhalb einer if-Abfrage eingefügt hatte:

<?php if ( $user_ID ) : ?>
	<p>Du bist eingeloggt als ...</p>
<?php else : ?>
	[Formularfelder für Name, E-Mail usw.]
	<input type="hidden" name="comment_post_ID" value="<?php echo $post->ID; ?>" />
<?php endif; ?>

Dadurch war die Zeile also für nicht eingeloggte Besucher (Gäste) vorhanden, sodaß sie problemlos kommentieren konnten. War man aber eingeloggt (was ich selbst als Admin natürlich immer war), dann fehlte die Zeile, und wenn die fehlt, dann bricht WordPress sein Kommentar-Script eben kommentarlos (haha!) mit einer weißen Seite ab.
Richtig muß es natürlich so lauten:

<?php if ( $user_ID ) : ?>
	<p>Du bist eingeloggt als ...</p>
<?php else : ?>
	[Formularfelder für Name, E-Mail usw.]
<?php endif; ?>
<input type="hidden" name="comment_post_ID" value="<?php echo $post->ID; ?>" />

So wird die Zeile in allen Fällen ausgegeben, und dann klappt es auch als Admin!

Beispiel-Ausgabe

Ich will mal zeigen, wie ich für diese Seite hier vorgegangen bin. Zuerst habe ich in den erweiterten qTranslate-Optionen den Haken bei „Benutze emulierte date Funktion“ gesetzt. Das bedeutet, daß man in seinem Template nun wie gewohnt the_date() benutzen kann, qTranslate aber automatisch so Dinge wie Wochentage oder Monatsnamen auf die jeweilige Sprache umstellt. Man braucht also nicht wie früher die qTranslate-Funktion qtrans_formatPostDateTime() zu benutzen! Diese Einstellung empfinde ich von allen als die komfortabelste.

Eine ganz einfache Datumsanzeige ohne Zusatztext (etwa „Sonntag, 19. April 2009“) könnte dann z. B. so aussehen:

the_date('l, j. F Y');

Für diese Seite wollte ich gerne eine Anzeige haben wie „19. Apr 2009“. Das geht wie folgt:

the_date('j. M Y');

Dazwischen habe ich anschließend noch jeweils einen Zeilenumbruch eingefügt:

the_date('j.<b\r />M<b\r />Y');

Das „r“ muß man in diesem Fall mit einem Backslash schützen, da es von der date()-Funktion bereits belegt ist. Überhaupt muß man bei allem zusätzlichen Text, den man in sein Datum einbauen möchte, aufpassen, ob er Buchstaben enthält, die von der Funktion als Formatparameter erkannt werden. Diese muß man dann alle escapen. Beispiel:

the_date('l, j. F Y \u\m G:i \U\h\r');

In einem solchen Fall muß man sämtliche Buchstaben der Wörter „um“ und „Uhr“ escapen, weil sie sonst alle von der date()-Funktion interpretiert werden und irgendein Murks herauskommt:

Sonntag, 2. November 2008 00000011 7:04 122560586907Sun, 02 Nov 2008 07:04:29 +0100

Wenn man nun gerne auf deutsch die Worte „um“ und „Uhr“ in seinem Datum haben möchte, auf englisch jedoch „at“ und „am“/„pm“, dann kann man dank der (relativ) neuen qTranslate‑Quicktags jetzt einfach zwei verschiedene Formate angeben:

the_date('[:de]l, j. F Y \u\m G:i \U\h\r[:en]l, jS F Y \a\t g:i a');

Dieses Beispiel würde auf deutsch so etwas ausgeben wie „Sonntag, 19. April 2009 um 4:18 Uhr“ und auf englisch entsprechend „Sunday, 19th April 2009 at 4:18 am“.

Eine Auflistung aller Parameter für die date()-Funktion findet man auf php.net.

comment_date('[:de]j. F Y[:en]jS F, Y');

Ging es Dir genauso, als Du heute diese Seite betratst? Wenn ja: Gratulation, Du hast eine außerordentlich gute Wahrnehmungsfähigkeit!
Wie man sieht, habe ich es nach über einem Jahr endlich mal geschafft, ein richtig eigenes WordPress-Theme zu erstellen. Die vorherigen Varianten waren immer nur Abwandlungen eines anderen Themes, das mir ganz gut gefallen hatte. Jetzt aber erstrahlt die Seite zum ersten mal im Glanze meines persönlichen Stils, ja, das Design trägt im wahrsten Sinne des Wortes meine Handschrift!

Begonnen habe ich mit diesem Theme schon vor etwa einem halben Jahr – unter dem Arbeitstitel „Ginchen altmodisch“. Für die erste Datei „schreibtisch.psd“ bezeugt der Windows-Explorer den 4. Oktober 2008 als Erstellungsdatum. Aber Ihr wißt ja, wie das ist… *hust*
Inzwischen nenne ich das Theme schlicht „Ginchen classic“, und es ist mein ganzer Stolz. Alles ist genau nach meinem Geschmack, und jeder Pixel hat hier einen Sinn. Natürlich ist es sehr grafiklastig: Bei jedem Seitenaufruf muß über 1 MB an Grafiken geladen werden, und das, obwohl ich mir schon große Mühe gegeben habe, alles so klein wie möglich zu halten. Aber da dies eine private Seite ist, deren Besucher noch dazu wahrscheinlich hauptsächlich Leute mit relativ schneller Verbindung sind, kann ich darüber guten Gewissens hinwegsehen. Außerdem habe ich die Ladezeit mal bei Pingdom getestet mit einem Ergebnis von 7,2 Sekunden. Das ist zwar schon viel, aber andererseits auch nicht so viel, daß ich mir den Kopf darüber zerbrechen muß. Wenn ich mich erinnere, wie lange eine Seite mit ein paar animierten GIFs vor zehn Jahren zum Laden brauchte …

Ein Großteil der Bilder, die ich verwendet habe, stammen von Wikipedia. Ein paar sind freie Grafiken aus anderen Quellen, und wieder andere habe ich selbst fotografiert oder gemalt und eingescannt. Ich schätze, ich muß mir noch die Arbeit machen und die Quellen hier irgendwo notieren, wie es die Lizenzen vorsehen. Aber erstmal brauche ich eine Verschnaufpause.

Alles in allem hoffe ich, daß mein Theme gefällt. Weitergeben werde ich es aber nicht!
Hier noch ein paar Impressionen aus der Entwicklungsphase:

P.S.: Gerade sehe ich, daß mein Google-PageRank, der Ende letzten Jahres noch bei 1 lag, inzwischen auf 3 geklettert ist. Das ist doch schon ganz ordentlich!

FireStats

Eigentlich wollte ich dazu gar nichts schreiben, aber nun habe ich gesehen, daß einige Leute dieselbe Fehlermeldung, die auch ich neulich von FireStats vorgesetzt bekam, bei Google eingegeben haben:

Wrong parameter count for debug_backtrace()

Offensichtlich hat Google genau zu dem Zeitpunkt das letzte mal meine Seite durchkämmt, als sie gerade von eben dieser unschönen Fehlermeldung übersät war, und dadurch landeten wohl einige Suchende hier – die dann vermutlich gleich wieder abzogen, weil hier ja in Wirklichkeit gar nichts zu dem Thema zu finden war.
Um zukünftige Gäste also nicht zu enttäuschen, will ich schnell erklären, wie ich den Fehler wieder losgeworden bin.

Ganz am Ende der Datei firestats/php/utils.php befindet sich folgende Funktion:

1040
1041
1042
1043
1044
1045
1046
1047
1048
1049

function fs_called_by($function)
{
	$bt = debug_backtrace(false);
	for($i = count($bt)-1;$i >= 0;$i--)
	{
		$frame = $bt[$i];
		if ($frame['function'] == $function) return true;
	}
	return false;
}

Die Funktion debug_backtrace() hatte ursprünglich gar keine Parameter. Erst seit PHP 5.2.5 ist es möglich, der Funktion einen Boolean-Wert, also true oder false, zu übergeben^[1] . Wenn man nun aber auf seinem Server ein älteres PHP laufen hat als Version 5.2.5 – was heutzutage durchaus noch oft vorkommt – dann kennt er natürlich nur eine Funktion debug_backtrace() ohne Parameter. Und deshalb streikt er dann auch, wenn FireStats versucht, der Funktion einen Wert zu übergeben.

Die Lösung ist simpel, man muß den Parameter einfach löschen – ich weiß gar nicht, warum er da überhaupt steht, er wird ja sowieso nicht gebraucht. Also einfach Zeile 1042 ändern in:

1042

$bt = debug_backtrace();

/* ]]> */

plötzlich folgendes:

/* ]]> */

Schuld daran ist eine Zeile in der Datei wp-includes/post-template.php, die da lautet:

165

$content = str_replace(']]>', ']]>', $content);

Wozu diese Zeile überhaupt jemals gut sein soll, ist mir ein Rätsel. Warum das Ganze nicht als Filter umgesetzt wurde, den man bei Bedarf auch mal abschalten kann, ist mir ebenfalls ein Rätsel. Schon seit zwei Jahren bitten etliche Leute darum, diese Zeile abzuschaffen oder irgendwie anders zu realisieren. Da bleibt nur warten und hoffen, daß es eines fernen Tages in einer kommenden WordPress-Version geändert wird.

In der Zwischenzeit aber bleibt einem wohl nichts anderes übrig, als die oben zitierte Zeile einfach auszukommentieren – auch wenn ich solche Lösungen, die ein Rumpfuschen im Quellcode erfordern, nicht so gerne habe. Dann klappt’s auch mit den CDATA-Blöcken – oder zumindest schonmal mit deren Definition.

Nun fügt man so einen CDATA-Block ja eigentlich nur aus einem Grund ein, nämlich damit man auch Zeichen wie <, > usw. verwenden kann, ohne sie in HTML-Entities umwandeln zu müssen. So kann man dann beispielsweise auch innerhalb eines JavaScripts HTML notieren, ohne daß der Browser davon irritiert wird.
WordPress aber wandelt alle betreffenden Zeichen innerhalb des CDATA-Blocks trotzdem in HTML-Entities um. Das liegt an der Funktion wpautop(), die uns normalerweise das Leben sehr erleichtert, indem sie alle Sonderzeichen in Posts für uns in HTML-Entities umwandelt. In diesem speziellen Fall aber wollen wir ja gar nicht, daß sie umgewandelt werden! Wir müssen also den Filter wpautop() irgendwie abschalten.

Aber zum Glück gibt es ja für fast alles ein Plugin – so auch hierfür. „TextControl“ heißt es und ist hier erhätlich. Übrigens wird es zur Verwendung von JavaScript in WordPress-Posts sogar von offizieller Seite empfohlen. Mit diesem Plugin kann man für jeden Post einzeln oder aber auch blogweit die automatische Formatierung deaktivieren. Um die Umwandlung von Sonderzeichen abzuschalten, genügt es, im zweiten Dropdown-Menü „No Character Encoding“ anstatt „Default (wptexturize)“ auszuwählen.

<li class="comment<?php if($comment->user_id == 1) echo ' admincomment'; ?>">

Mir gefällt das so nicht. Was ist, wenn eine Seite mehrere Schreiber hat und man gerne die Kommentare aller Mitwirkenden hervorheben möchte? Soll das dann etwa so aussehen?

<li class="comment<?php if($comment->user_id == 1 || $comment->user_id == 3 || $comment->user_id == 13 || $comment->user_id == 753) echo ' admincomment'; ?>">

Ich glaube, da sind wir uns alle einig, daß das nicht so schön ist. Außerdem müßte man dann jedesmal, wenn man ein neues Mitglied in seine „Redaktion“ aufnimmt, wieder im Template rumfummeln, um dessen User-ID dort einzutragen.
Nein, nein, so macht man das nicht. Viel besser wäre es doch, wenn man einfach das User-Level des Kommentators prüft, denn sobald dieses höher als 0 ist, weiß man, daß es sich um einen „Mitarbeiter“ der Seite handelt.

Das sieht dann so aus:

<? $userdata = get_userdata($comment->user_id); ?>
<li class="comment<?php if($userdata->user_level > 0) echo ' admincomment'; ?>">

So bekommen alle Kommentare von „Contributors“ (Level 1), Autoren (Level 2–4), Editoren (Level 5–7) und Admins (Level 8–10) ein anderes Aussehen. Natürlich kann man anhand dieser Levels das Ganze noch verfeinern, wenn man z. B. nur Kommentare von Admins und Editoren anders darstellen will, nicht aber die von Autoren und „Contributors“.

Jetzt aber zeigt WordPress im Backend zwar an, wenn neue Updates für Plugins verfügbar sind, jedoch gibt es dort keinen direkten Downloadlink zur .zip-Datei mehr. Das hätte also bedeutet, daß ich jedes Plugin selbst auf wordpress.org hätte suchen müssen bzw. jedesmal die Homepage des Autoren hätte besuchen müssen, um dort die aktuelle Version als .zip-Datei herunterzuladen. Extrem nervig! Das gab mir also Anlaß, mich noch einmal auf die Suche nach einer Lösung zu machen, und siehe da, ich fand eine, die ich für WordPress 2.7 nur ganz leicht abwandeln mußte.^[1]

define('ABSPATH', dirname(__FILE__).'/');

putenv("TMPDIR=" . ABSPATH . "wp-content/upgrade");
define('WP_TEMP_DIR', ABSPATH . "wp-content/upgrade");

<? echo dirname(__FILE__); ?>

define('WP_TEMP_DIR', ini_get('upload_tmp_dir'));

define('WP_TEMP_DIR', '/tmp');

/* That's all, stop editing! Happy blogging. */)

628

if ( getmyuid() == fileowner($temp_file) )

628

if ( posix_getuid() == fileowner($temp_file) )