Bei Updates dieser Größenordnug bin ich immer nervös. Ihnen haftet so etwas endgültiges an. So schluckte ich auch diesmal, als mich der Updater irgendwann im Verlauf der ganzen Aktion darauf hinwies, dass er jetzt gedenkt, die Datenbank zu erneuern.

Gut – ich bin ja auf alles vorbereitet. Habe alles, was nicht Niet- und Nagelsicher war, doppelt abgesichert. Diesmal sogar mit ausführlichen Bildschirmfotos von allen Seiten des Administrationsbereichs, damit ich im Falle des Falles nachvollziehen kann, was ich wo eingetragen hatte.

Wie wird das aber sein, wenn wirklich einmal die Katastrophe eintritt? Rund 150 Artikel zu verlieren, täte mir mittlerweile doch schon sehr weh. Die Seite ist ein Stück von mir geworden.

Um mir es richtig zu geben, habe ich diesmal beschlossen, zusätzlich den Zeichensatz von ISO-8859-1 auf UTF-8 zu wandeln. Für einen Normalsterblichen, wie mich, bedeutet das den Gegenwert einer halben Weltumrundung. Bin ich doch schon froh zu wissen, was so ein Zeichensatz ist. Im Klartext bedeutet dieser Wechsel, dass ich das Zeug da in der Datenbank auch anfassen muss.

Mit spitzen Fingern suche ich bei Google nach Hilfeseiten und bleibe bei einem Script hängen, was die Wandlung leicht und unproblematisch bewerkstelligen soll. Ideal für Nichtprogrammierer, wie man sagt. Einfach hochladen und dann ansurfen. Alles weitere ergibt sich dann.

So harmlos kündigen sich meistens Katastrophen an.

Die aufgerufene Seite blieb leer.

Mein ungutes Gefühl steigerte sich, zumal der Autor des betreffenden Scripts ausdrücklich darum bittet, nur einmal das Ding aufzurufen, weil es sonst zu Fehlern führen wird.

Na toll, was tun? 

Weitere Recherchen im Internet verwirrten mich eher, sodass ich irgendwann auf eine verwegene Idee kam, auf die nur ein Laie, wie ich kommen kann.

Der Ansatz: Was wäre, wenn ich die XML Datei, die ich mir vor dem ganzen Durcheinander als Sicherheitskopie von WordPress ausgeben lies, auf UTF-8 umfrisiere und anschließend wieder frech in das Weblog importiere?

Gesagt – getan.
Ich habe also diese XML Datei mit einem einfachen Texteditor geöffnet und den Eintrag auf der ersten Zeile encoding=”iso-8859-1″ durch ein encoding=”utf-8″ ersetzt.

Mehr nicht.

Jetzt habe ich die Datenbank gelöscht und Kylaloo so neu aufgesetzt, als würde ich ein völlig neues Weblog einrichten. Diesmal allerdings Im UTF-8 Format. Nachdem ich alles andere, wie beispielsweise die Permalinks so eingerichtet habe, wie es vorher einmal war, kam jetzt der spannende Augenblick, die “umfrisierte” XML Datei zu importieren.

Unendlich lange gefühlte 30 Sekunden später meldete sich das Weblog und leitete mich durch den Importvorgang. Dann konnte ich zuschauen, wie das Skript einen Beitrag nach dem anderen wieder zum Vorschein brachte. 

Ich bin ganz aufgeregt – Das Ganze scheint funktioniert zu haben.

Ich klopf mal auf Holz.

Da sag mal einer, ich wäre nicht schnell.
Nur ein paar Stunden nach der Veröffentlichung der 2er Version kloppe ich hier schon die deutsche Fassung vom deutschen WordPress 2.0 heraus. Gut – Die Nacht ist faktisch durchgemacht und so überschwenglich glücklich bin ich jetzt auch nicht mehr. Mir ist es auf Teufel komm raus nicht gelungen, ein paar Ideen, die ich in der letzten Version eingebaut habe, hier wieder herzustellen. Ich wollte zum Beispiel das so wichtige Umlaut-Plugin automatisch aktiviert haben, damit daran keiner mehr denken muß. Geht nicht. Aktiviere ich es per Installationsskript, hagelt es später dumme Fehlermeldungen.

Auch das Datenbankplugin haben sie mit anderen Eigenschaften versehen, sodass jeder dazu gezwungen ist, seinen eigenen Sicherungsordner anzufertigen und an der richtigen Stelle mit den korrekten Rechten zu plazieren. Alles nicht so einfach, für die Anfänger unter uns. Wie gerne hätte ich wenigstens den Sicherungsordner bereits eingebaut gehabt, damit der Benutzer sich nur noch um die leidige Frage nach den Rechten kümmern muß. Immerhin: Ich habe dem Plugin eine kleine Anleitung hinzugefügt, die zu sehen ist, wenn man die Datenbank benutzen möchte. Vielleicht hilft das ja dem einen, oder anderen.

Extrem viel Arbeit hat diesmal auch die Sprachdatei gemacht, die von einst 931 Phrasen auf stattliche 1217 angewachsen ist. Hinzu kamen die (Pi mal Daumen) 250 Ausdrücke, die unter die Kategorie “veraltet” gefallen sind und zusätzlich umgeschrieben werden mussten. Ein großes Stück Schuld an der Größe tragen die jetzt in die Sprachdatei integrierten Plugins und Importierhilfen anderer Weblogsysteme.

Wie immer, so ist auch diesmal das Kubrick-Theme mehr als lausig übersetzt worden. Das würde mich ja nicht weiter stören, wenn die Entwickler von WordPress nicht ausgerechnet dieses Theme zum Standardtemplate gemacht hätten. Zur Strafe habe ich eine Variante davon als Standardtemplate eingerichtet, die darauf hindeuten soll, dass wir alsbald bei WordPress.de im Komplettpaket ein eigenes Layout einbauen werden. So!

Ausserdem kann ich dieses Kubrick langsam sowieso nicht mehr sehen.

Ansonsten stimmt dieses Paket in allen anderen Angelegenheiten mit dem kürzlich erst vorgestelltem WordPress-Teutonicus überein.

Und die Sache mit der liebevollen Kritik dürft ihr jetzt in den Kommentaren üben.

Ryan Boren, ein Entwickler von WordPress, hat in einem Artikel (engl.) einmal genauer erläutert, wie die neuen Benutzerlevels in Zukunft eingesetzt werden. Ich fand diesen Artikel interessant, so dass ich mich mal hingesetzt und das ganze Geraffel übersetzt habe:

Einer, der am meisten kritisierten Aspekte bei WordPress ist das System, mit dem die Benutzerrechte geregelt werden. Bei den Versionen 1.5.x und früher, geschieht das über Benutzer-Level. Jedem Benutzer ist hier ein Level zwischen 0 und 10 zugeordnet, wobei 10 die vollen administrativen Rechte, und Null praktisch keine Befugnisse hat. Die Level sind ausserdem hierarchisch. Der Benutzer eines höheren Levels kann die Beiträge eines Benutzers eines niedrigeren Levels bearbeiten. Das hört sich nach einem guten und einfachen Schema an, aber in der Praxis sorgt es doch für eine Menge Durcheinander. Die mit einem Level verbunden Privilegien sind nämlich alles andere als klar. Was ist der Unterschied zwischen Level Zehn und Level fünf? Wer kann hier wen bearbeiten? Kann ein Level fünf ein anderen Level fünf bearbeiten? Was genau kann jede der elf Level tun?

Für die 2.0er Version haben wir entschieden, dass dieses System einer Überholung bedarf. Nachdem wir einmal nachgeschaut haben, wie andere Weblog- und CMS Applikationen mit den Rechten umgehen, haben wir uns für ein Modell mit Rollen und Befugnissen entschieden. Nach einer Diskussion über den Ablauf, den wir etablieren wollten, begannen wir mit der Kreation von fünf Rollen: Registrierter Leser, Mitarbeiter, Autor, Herausgeber und Administrator. Jede dieser Rollen hat eine Sammlung von verknüpften Befugnissen. Ein registrierter Leser hat sehr begrenzte Befugnisse. Er kann den Tellerrand sehen und sein eigenes Profil bearbeiten. Das ist alles. Ein Mitarbeiter darf Entwürfe herstellen, diese aber nicht veröffentlichen. Ein Autor kann Beiträge veröffentlichen. Ein Herausgeber kann nicht nur die Beiträge anderer bearbeiten, sondern darf auch Kategorien, Linklisten, Kommentare und statische Seiten verwalten. Ein Administrator kann alles machen. Er kann die Themes “umschalten”, Plugins aktivieren, Dateien bearbeiten und Importer einsetzen.

Obwohl diese Rollen hierarchisch zu sein scheinen, sind sie es nicht. Jede Rolle ist einfach nur eine Sammlung von Befugnissen. Die Rollen der Herausgeber und Administratoren haben jetzt auch die Befugnis, Beiträge zu bearbeiten, die nicht von ihnen sind. Sie dürfen in sämtliche Beiträge des Blogs eingreifen. Auch in die, der eigenen Rollen. Für diejenigen, die noch die alte Level-Hierarchie gewohnt sind, mag es merkwürdig sein, Herausgebern und Administratoren das Bearbeiten von Beiträgen zu erlauben. Die Hierarchien zu vermeiden war jedenfalls eine wegweisende Entscheidung. Man hat jetzt entweder die Befugnis andere Beiträge zu bearbeiten, oder nicht. Wir versuchen es einfach zu halten.

Benutzer können eine, oder mehrere Rollen haben und individuelle Befugnisse bekommen, die ihnen auch ausserhalb des Contextes ihrer Rolle zugeordnet werden können. In der Standardeinstellung ist zunächst lediglich eine Rolle für jeden Benutzer vorgesehen. Man wählt eine der fünf Rollen für den Benutzer aus und voilá, das war es dann auch schon. Man kann weder mehrere Rollen vergeben, noch individuelle Befugnisse den Benutzern erteilen.
Es ist eine zweckmäßige Entscheidung mit der Intention die Dinge einfach zu halten. Die Möglichkeit weiterführende Rollen und Befugnisse zu verwalten, wird durch ein Plugin zur Verfügung gestellt werden.

Derzeit sind etwa zwanzig Befugnisse definiert. Im Quelltext sind Befugnisse einfach nur Schlüsselwörter, die Benutzern und Rollen zugewiesen werden können.

Hier nun unser komplette Sammlung an Befugnissen.

• switch_themes
• edit_themes
• activate_plugins
• edit_plugins
• edit_users
• edit_files
• manage_options
• moderate_comments
• manage_categories
• manage_links
• upload_files
• import
• unfiltered_html
• edit_posts
• edit_others_posts
• edit_published_posts
• publish_posts
• edit_pages
• read

Um mit dem bisherigen Benutzerlevel-System kompatibel zu sein, haben wir Befugnisse, die mit den früheren Levels korrespondieren: level_0, level_1, … , level_10.

Ein registrierter Leser hat die level_0 Befugnisse.
Ein Mitarbeiter hat die von level_0 und level_1.
Der Autor wiederum hat die Befugnisse der level_0, level_1, und level_2.
Ein Herausgeber ist mit den Befugnissen von level_0 bis level_7 ausgestattet und
die Befugnisse des Administrators reichen von level_0 bis level_10.

Beim Upgrade von früheren WP-Versionen bekommen alle Benutzer Rollen, die ihren früheren Benutzerleveln entsprechen. Ein Level-7 Benutzer bekommt beispielsweise die Rolle eines Herausgebers.

Für Plugin Autoren ist ein API erhältlich, um Rollen und Befugnisse abrufen und verändern zu können. Ein Plugin kann eine neue Befugnis mit dem Namen “do_foo” herstellen, die dem Administrator mit dem folgenden Code zugeordnet wird:

$role = get_role('administrator');

$role->add_cap('do_foo');

Um herauszufinden, ob der derzeitige Benutzer überhaupt diese Befugnis besitzt, können sich Plugins der current_user_can() Funktion bedienen:

if ( current_user_can('do_foo') ) ...

Um die Befugnisse einer bestimmten Benutzer-ID herauszufinden erstellt man ein WP_User Objekt:

$user_id = 1;

$user = new WP_User($user_id);

if ( $user->has_cap('do_foo') ) ...

Wenn eine völlig neue Rolle erstellt werden soll, kann man das mit add_role() und add_cap() realisieren.

$role = add_role('foo_doer', 'Foo Doer');

$role->add_cap('do_foo');

$role->add_cap('do_bar');

Soviel zu den Grundlagen. Für die komplette API gehe zu der Datei capabilities.php
Am meisten wird bei der API current_user_can() benutzt. Wann immer du bestimmen möchtest, was der angemeldete Benutzer machen darf, benutze current_user_can().

Für weitere Informationen zu den Rollen und Befugnissen, gehe zu Owens Übersicht. Wenn Du ein Plugin Autor bist und Fragen zur API und mehr hast, besuche die Hackers List und wenn Du ein Benutzer bist, der sich gerade fragt, was das alles zu bedeuten hat, besuche die Support Foren.

Die Tage werden kürzer, die Nächte kälter und kein Urlaub weit und breit.

Es gibt da etwas, was ich schon immer mal machen wollte, aber schon auf halber Strecke immer wieder auf die lange Bank geschoben habe. Und ich bin mir ziemlich sicher, dass es jedem herumbosselnden User genauso durch den Kopf gegangen sein muß, seitdem er WordPress benutzt.

Tja, und jetzt ist es passiert.

Die Rede ist hier von einer kompletten deutschsprachigen WordPress-Installation. Eine ohne wenn und aber. Ich habe WordPress für meinen typischen deutschen User einmal zusammengestellt und all das eingebaut, was mir dabei irgendwie wichtig erschien. Es ist mein bescheidener Versuch, den Installationsvorgang einer deutschen WordPress Version (1.5.2) soweit, wie es mir möglich ist, zu automatisieren.

Herausgekommen ist dabei ein Komplettpaket für alle, die entweder zu faul, zu gestresst, oder schlicht zu unbeholfen sind, sich WordPress selbst vernünftig zu installieren und ins Deutsche zu übertragen. Aber keine falschen Hoffnungen: Das Ergebnis ist hier keine aufgeblasene Pimp-, sondern vielmehr eine möglichst fehlerfreie und saubere PureVersion.

Das habe ich gemacht:

• Die Installationsrutine übersetzt (auch die Fehlermeldungen).
• Das Standardtemplate (de) überarbeitet, eingebaut und aktiviert.
• Die deutsche Sprachdatei aktualisiert und eingebettet.
• Die wichtigsten Plugins sind assimiliert und an Ort und Stelle aktiviert.
• Die leidigen Probleme mit dem amerikanischen Datumsformat sind beseitigt.
• Die WordPress Dokumente sind übersetzt und verlinkt.
• Der erste Artikel und der erste Kommentar sind übersetzt.
• Eine (leere) .htaccess Datei der Installation hinzugefügt.
• Deutschsprachige Bestätigungsmail nach der Einrichtung.

Viel muß der Benutzer jetzt nicht mehr tun, damit WordPress zum Leben erweckt werden kann. Nur zwei, drei dumme Dinge bleiben knifflig.

1. Er muß eine Datenbank auf dem Server einrichten und die dazu gehörenden Daten korrekt in die wp-config.php eingeben. Ich bin mir aber ziemlich sicher, dass ihm sein Hoster dabei gerne helfen wird, sodass das halbwegs angenehm über die Bühne gehen kann.
2. Er muß verstehen, wie man die Dateien mit einem FTP Programm auf den Server bringt. Auch hier müsste ihm der Hoster gutgelaunt mit Rat und Tat zur Seite stehen, denn das ist ja schließlich sein Job.
3. Um wenigstens Bilder im Internetcafé hochladen zu können, muß er herausfinden, was “Rechte” sind und wie man sie vergibt. Das gerade erwähnte FTP Programm sollte in der Lage sein, diese Rechte unkompliziert zu vergeben. Wenn nicht, dann wird es Zeit, sich nach einem besseren umzuschauen.

Also gut, kommen wir endlich zur Installation der deutschen WP-Edition. Sie wird grundsätzlich genauso installiert, wie die internationale Version und das kann man einer unkomplizierten Anleitung entnehmen, die bei der deutschen WordPress Community zu finden ist. Das schöne daran: Bei Problemen kann man gerne im Forum vorbeischauen.

Wo wir gerade dabei sind: Ohne die inzwischen tagtäglichen Arbeit aller Mitglieder im Portal und der Dokumentation, wäre dieses Paket sowieso nie denkbar gewesen. Mal eine Zahl als Beispiel: Die Sprachdatei hat die sagenhafte Dimension von 931 Zeichenketten, die alle peinlich genau von Hand übersetzt werden mussten. (Hallo Annette) Wir sammeln und aktualisieren noch heute, die kleinsten Fehlerchen und diverse Formulierungen.

Wie üblich bei solchen Sachen, kann es auch mal sein, dass im ganzen Durcheinander etwas übersehen wurde. Wer etwas erwähnenswertes findet und dazu noch einen sonnigen Tag erwischt hat, sollte sich nicht scheuen, mit mir umgehend Kontakt auzufnehmen. Gut gelaunt fomulierte Fehlermeldungen tun nämlich nur halb so weh, wie besserwisserische, die so auffallend gerne mit ungemütlichem kalten Regen zusammenfallen.

Apropos Kritik.

Die Installation, sowie der Gebrauch und Einsatz geschieht hübsch auf eigene Gefahr.

Im Zeitalter der überzüchteten Glamour-Plugins wollte ich an dieser Stelle einmal erwähnen, welche Helfer für mich die wichtigsten sind. Sie wirken langweilig, verrichten klaglos im Hintergrund ihren Dienst und können meistens nichtmal irgendwo eingestellt werden. Also die klassischen Arbeiterplugins, wenn man so will.

Für mich mit Abstand am wichtigsten, ist Papa Scotts Umlaut Plugin. Die meisten User glauben nämlich auch heute noch, dass WordPress die Umlaute im Titel, selbstverständlich genauso, wie wir, durch Zweierkombinationen ersetzt. Also dass es aus einem ä, ö, ü und ß ein ae, oe, ue und ss macht. Dem ist aber nicht so. WordPress radiert hier lediglich die Pünktchen weg und übersetzt das scharfe “s” mit einem weichen.

Ein Fehler? Nicht ganz. Es ist eine Konvention. Die Amis machen das eben so.

Eine Kuh macht muh. Viele Kuhe machen Muhe.

Hat man dieses Plugin aber gluücklich aktiviert, dann gilt auch in WordPress ab sofort wieder unsere gewohnte Umschreibung. Haken: Kann man die sog. schönen URLs nicht benutzen, dann macht dieses Plugin auch keinen Sinn, denn dann setzt WordPress in den Titel sowieso nur eine kryptische Zahlenkombination.

[Update:]
Gerade eine vielversprechende Steigerung des Plugins über das Forum entdeckt.

Kryptische Zahlenkolonnen kennt man auch von Spam und da sind wir auch schon bei meinem zweitliebsten Pluginkind dem Spam-Nuker von Chris Davis. Das besondere daran ist, dass dieses Werkzeug Spam sichtbar macht (und damit auch löschbar), den wir sonst nicht sehen können. Das liegt daran, dass WordPress merkwürdigerweise Kommentare, die mit dem Attribut Spam gekennzeichnet wurden, zwar von der Bildfläche verschwinden lässt, aber eben nicht löscht. Diese Kommentare lungern dann ziemlich nutzlos in der Datenbank herum. Ich weiß nicht mehr so genau, warum das so ist, habe aber dieses Phänomen schon einmal ausführlich beschrieben. Dieses Plugin habe ich derartig lieb gewonnen, dass ich es nicht nur übersetzt, sondern auch etwas Benutzerfreundlicher umgestellt und aufgeräumt habe.

Die Diskussion über das nofollow Attribut ist kaum abgeebbt, da weiß schon kein Mensch mehr, was das überhaupt ist. Es geht um die vermeintliche Bekämpfung von Spam bei den Suchmaschinen. Man ging davon aus, dass ein Spammer daran interessiert ist, einen möglichst hohen Pagerank bei Google zu erhalten. Man dachte weiter und sah, dass Spamkommentare in Weblogs genau diesen Pagerank in die Höhe treiben könnten.

Hier greift nun das Attribut nofollow, das bei WorfPress, seit der Version 1.5 standardmäßig fest im Programm verankert ist und an jeden Link in den Kommentaren angepappt wird. Trifft also eine Suchmaschine auf dieses Attribut, dann wird der dazugehörige Link als Ranksteigerer ignoriert. Da grundsätzlich alle Links in den Kommentaren davon betroffen sind, werden also auch die “guten” Links gebrandmarkt.

Die Erfahrung hat mittlerweile gezeigt, dass sich die Spammer einen Teufel darum scheren, ob sie ignoriert werden, oder nicht. Die verschicken ihren Müll so oder so. Wirklich erstaunt hat das natürlich niemand, aber es stört auch keinen mehr, dass die guten Kommentare weiterhin nicht so gewürdigt werden, wie es sich eigentlich gehört. Andere mögen diesen Fauxpas stumpf vor sich hin vergessen, genau so, wie sich das die Suchmaschinenbetreiber händereibend wünschen. Mein geliebtes do-follow-Plugin bleibt jedenfalls installiert und ich werde weiterhin jeden Kommentarlink beklatschen, dem es dieses Attribut erfolgreich entzogen hat.

Ich habe mehrere Gründe, warum ich Olafs Update Monitor bei mir einsetze. Zum einen bleibe ich stets auf dem Laufenden, wenn sich bei WordPress etwas neues tut und zum anderen bin ich auch maßlos stolz darauf, was unsere Community alles auf die Beine stellt. Ich bin mir sicher, dass wir da noch mit mancher Überraschung daherkommen werden.

Bis vor ein paar Tagen dachte ich noch, dass dieses Weblog völlig spamfrei sei. Kein Wunder, denn ich kontrolliere nahezu täglich die Kommentare, habe eine ausgeklügelte Grey- und Blackliste und sämtliche Ping- und Trackbacks landen bei mir in der Moderation.
Erwartungsgemäß gab mir dann auch das, was ich zu sehen bekam, das Gefühl alles richtig gemacht zu haben.

Dann kam der Tag, als ich mir dachte, ich sollte mal wieder eine Sicherungskopie meiner Datenbank anfertigen. Nur so für den Fall der Fälle. Und weil ich nicht gerade ein Überflieger in Sachen Datenbank bin, machte ich zur Sicherheit gleich mehrere verschiedene Datensicherungen. Ich nutze dazu eine Software, die mir mein Hoster automatisch dafür installiert hat. Sie heißt PhpMyAdmin und ist laut den MySql-Freaks, die ich so kenne, die gängigste und verständlichste für solche Angelegenheiten.

Als ich eine Kopie der Datenbanksicherung mit einem Texteditor öffnete, traf mich der Schlag: Neben den normalen Einträgen fand ich etwa 6000 Spamkommentare darin aufgezeichnet.

Sechstausend!

Fassungslos fragte ich mich, woher so unanständig viele Kommentare herkommen können. Auf normalem Weg hätte ich eine solche Menge sicher bemerkt, also muß sie sich irgendwie hinter meinem Rücken eingenistet haben. Nur, wie kann das gehen?

Um diese eigenwillige Schwäche bei WordPress zu verstehen, müssen wir mal einen Blick auf die Funktionsweise bestimmter Spamfilter werfen. Oft werden sie auch als “lernfähige” Filter bezeichnet, weil sie zwei, oder mehrere Dateien miteinander vergleichen, um sich anschließend einen Reim daraus zu machen. Wenn wir sie also konkret mit tatsächlichem Spam “füttern”, dann sollen sie zwangsläufig irgendwann in der Lage sein, die anderen Familienmitglieder zu erkennen und herausfiltern zu können.

Sie brauchen sozusagen Spam um Spam erkennen zu können.

Soweit ich das jetzt sehe, geben sich die fest eingebauten WordPress Filter zwar alle Mühe, Spam von Nichtspam zu unterscheiden, kümmern sich aber leider herzlich wenig darum, die mit “Spam” gebrandmarkten auch automatisch zu löschen. Ich weiß nicht warum. Vielleicht war ja den Entwicklern das Risiko einfach zu hoch, korrekte Einträge falsch zu behandeln.

Der “Trick” der Entwickler ist jedenfalls der, dass die als Spam klassifizierten Kommentare, einfach nur aussortiert und für den gewöhnlichen Benutzer unsichtbar in der Datenbank abgelegt werden. Ihr Kalkül dabei: Solange der Benutzer das nicht merkt, wird er sich auch nicht weiter an der wachsenden Größe der Datenbank stören.

Aha. Da ist er nun endlich, der große Unterschied zwischen Spam und Löschen.
Wenn ich im Administrationsbereich bei der Kommentarmoderation “Löschen” auswähle, dann wird der Kommentar tatsächlich gelöscht. Wähle ich dagegen “Spam” aus, dann markiert WordPress diesen Kommentar nur mit dem Attribut “Spam” und legt ihn anschließend in eine unsichtbare Schublade in der Datenbank ab. Das passiert vollautomatisch im Hintergrund und sieht dann für den User fälschlicherweise genauso aus, als hätte er den Kommentar gelöscht.

Also: Benutzt man kein Plugin, dass die so markierten Kommentare löscht, dann wächst die Datenbank und wächst und wächst. Bei mir sind das jetzt ganze 6000 Spam-Kommentare in rund einem halben Jahr gewesen, oder wären gut 12.000 Stück in einem ganzen. Steigerungsraten aufgrund einer möglichen größeren Bekanntheit des Blogs einmal nicht eingerechnet.

Und das soll wirklich keinen Einfluß auf die Datenbank haben, wie die Entwickler uns weismachen wollen?

Na, ich weiß nicht.

Ich will aber nicht ungerecht sein. Schließlich benutzen ja einige der Plugins dann doch diese “intelligenten” Filter und entfernen schön brav die bösen Schmarotzer des Netzes. Man muß sie eben auch finden, installieren und einsetzen können.

Macht man das nicht, weil man das nicht wusste, oder weil das Plugin sich nicht mit einem anderen verträgt, dann gibt es da noch eine Alternative, mit der man zumindest diese unsichtbare Schublade sichtbar machen, und die Einträge darin zum Teufel schicken kann.

Wie lautet der Satz aller Sätze, wenn man WordPress das erste mal installiert? Richtig: “This is your first post. Edit or delete it, then start blogging!” Gibt man ihn bei Google ein, sieht man die beeindruckend wachsende Anhängerschaft. Doch doch, so langsam erobert sich WordPress den Platz an der Sonne im Weblogbusiness….

Seit bei WordPress die neue Runde 1.5 eingeläutet wurde, ist auch eine ganze Menge in Sachen Übersetzung passiert. Mit großen Bemühungen Seitens der Entwickler vergeht kaum ein Tag, an dem sich nicht etwas neues tut. So ist es auch nur noch eine Frage der Zeit, bis das Standard Layout, das Kubrick Template, internationalisiert sein dürfte. Die Übersetzerei hat aber bei so manchem den Nachteil einer lahmeren Performance bewirkt und nicht wenige User kehren aus diesem Grund der Sprachdatei enttäuscht wieder den Rücken zu.

Ich behaupte mal zu Unrecht, denn soeben hat der Entwickler Danilo Segan eine neue Version von PHP-gettext gebastelt. Von Nico Kaiser erhielt er zudem noch ein Patch mit Optimierungen.

Ich habe das einmal ausprobiert und war völlig von den Socken. Der Zuwachs bei der Geschwindigkeit ist zumindest bei mir enorm! Wer das auch mal ausprobieren möchte, dem habe ich die drei Dateien, um die es hier im wesentlichen geht, aus der für mich etwas verwirrenden Originaldatei heausgenommen und hier bereitgestellt.

Installation:
Die Datei wp-turbo.zip entpacken und die drei darin befindlichen Dateien gettext.php, streams.php und wp-l10n.php gegen die, die sich im Ordner wp-includes befinden, austauschen. (Nicht vergessen: Sicherungskopien machen!)

Hinweis:
Ich habe das mit meiner WP Version 1.5 ausprobiert und weiß natürlich jetzt nicht, was diese Dateien mit der alten 1.2er anstellen! Also: Vorsicht ist die Mutter der Porzellankiste.

[Update:] Wer die Kommentare aufmerksam gelesen hat, sieht auch die neue Info von Nico Kaiser mit einer Modifikation in der wp-l10n.php. Ich habe diese Modifikation inzwischen ausgeführt und dem Zip hinzugefügt. Der Text weiter oben im Artikel ist entsprechend aktualisiert.

[Update 2:] Mittlerweile haben die Entwickler, den WP-Turbo auch schon eingebaut. Also: Ab der Version 1.5 ist dieser Turbo eigentlich sinnlos geworden.

Mann mann mann, was für ein Frust. Da installiert man sich noch eben hoffnungsfroh die neueste Version 1.5 “Strayhorn” von WordPress, bettet die frische neue deutsche Sprachdatei dazu und stellt enttäuscht fest, dass eben doch nicht alles so auf deutsch daherkommt, wie man es sich gewünscht hatte. So mancher glaubt jetzt böse, dass gar nur ein kleiner Teil übersetzt wurde.

Stimmt aber nicht.

Der Punkt ist der, dass Michael Heilemann bei der Erstellung dieses Templates verdammt viel Text direkt in die Seiten geschrieben hat und dieser Text leider nicht entsprechend der Konvention für die Übersetzungsprogramme markiert wurde. Oder anders: Das entsprechende Programm kann leider nicht alle Eintragungen zum übersetzen finden. Im deutschen Forum für WordPress wurde inzwischen des öfteren danach gefragt, wo man was, wie verändern muß, damit man eine saubere deutsche Installation vor sich hat. Insbesondere an den Datumsangaben störten sich noch viele.

Ich war mal so bescheuert und habe mir das ganze Geraffel vorgenommen und ins deutsche übertragen.

Funktionieren sollte es nur in Kombination mit der deutschen Sprachdatei von WordPress.de, die man zweckmäßig vorher schon installiert haben sollte. Hat man das gemacht, darf man sich jetzt die deutsche Version des default-Themes (Kubrick) herunterladen, entzippen und neben dem Original auf dem Server schieben. (wp-content/themes/) Aktiviert wird der ganze Spaß nun wie gehabt: Im Adminbereich einfach auf die Themes klicken und dort dann WP-default (German) 1.5 aktivieren.

Fertig.

Mein erster heimlicher Test ist vielversprechend verlaufen. Sollte jemand etwas verbesserungswürdiges finden, so möge er bitte dazu die Kommentarfunktion nutzen.

Die neuste Schrei unter den Spammern ist es, die Weblogs mit Pingbacks und Trackbacks anzugehen. Weil WordPress diese Kanäle bisher anders behandelt, als die normalen Kommentare, kann der Spam (und das macht er auch!) auf diese Weise ungehindert durch die bisherigen Barrieren hindurch schlüpfen. Die Entwickler arbeiten unter Hochdruck daran, diese Lücken so effektiv, wie möglich zu schließen, aber diese Techniken benötigen noch Zeit zum programmieren und zum testen.

Hier also eine erste (Not-) Lösung, die man auf englisch bei Tamba2 nachlesen kann:

Nicht vergessen:
Fertige Kopien von allen Dateien an, die Du verändern willst, bevor Du sie veränderst!

Die folgende erste Lösung stammt von LisaS (engl.)

Versionen:
Die beschriebene Lösung sollte auf den meisten Weblogs der Version 1.2 funktionieren (Für die Version 1.5 bitte ganz unten bei Update schauen) :

Man öffnet die wp-trackback.php mit einem einfachen Texteditor. Dort suchen wir nach folgendem Code:

if(check_comment($author, $email, $url, $comment, $user_ip)) {
$approved = 1;
} else {
$approved = 0;
}

Das sind die Zeilen 69 -73 in der Originaldatei. Jetzt schauen wir genauer hin und suchen darin den Ausdruck $approved = 1; Diesen Wert setzen wir nun genauso, wie es zwei Zeilen tiefer steht, auf Null. Der ganze Block müsste jetzt in etwa so aussehen:

if(check_comment($author, $email, $url, $comment, $user_ip)) {
$approved = 0;
} else {
$approved = 0;
}

Anmerkung: Die ganz normalen Kommentare bleiben davon völlig unberührt. Lediglich alle eintrudelnden Trackbacks müssen ab sofort vom Weblogbetreiber freigeschaltet werden, bevor sie veröffentlicht werden.

Komplett entfernen.
Manch einer hat jetzt die Nase von dem ganzen Spamkram bereits so voll, dass er die Trackbacks komplett deaktivieren möchte. Hier geht man man besten so vor: Wir suchen in der in der gleichen Datei (wp-trackback.php) nach folgender Zeile:

$pingstatus = $wpdb->get_var(“SELECT ping_status FROM $tableposts WHERE ID = $tb_id”);

Diese Zeile müssen wir auskommentieren.
Wie das geht? Einfach zwei Slashes an den Anfang der Zeile stellen. Fertig.
Direkt eine Zeile tiefer trägt man $pingstatus = ‘closed’; ein.
Die Zeilen 31 und 32 sollten jetzt folgendermaßen aussehen:

//$pingstatus = $wpdb->get_var(“SELECT ping_status FROM $tableposts WHERE ID = $tb_id”);
$pingstatus = ‘closed’;

Anmerkung: Die ganz normalen Kommentare bleiben davon völlig unberührt. Lediglich alle Trackbacks werden ab sofort ignoriert.

Siehe auch: Original Forumsbeitrag (engl.)

Man kann sich auch von drdave das Spam Karma Plugin
einmal näher anschauen. Es enthält bereits Elemente, die gegen den Trackbackspam eingesetzt werden können. Diejenigen, die es schon länger benutzen sollten übrigens unbedingt das Plugin updaten.

[Update:]
Leider funktioniert der oben beschriebene Lösungsweg nicht bei der neuen WordPress 1.5 Version. Völlig hilflos müssen wir uns aber dennoch nicht fühlen. Die von Herbert in den Kommentaren bereits erwähnte Lösung, bietet ein komfotables Plugin an, das man mittlerweile auch für die Version 1.5 haben kann.

Tipp: Der von der Wirkung dem Trackback recht ähnliche Pingback funktioniert zwar technisch etwas anders, sollte bei der Gelegenheit aber auch mit der entsprechenden Plugin-Lösung belegt werden.