Wordpress Archive

Wer in den letzten Tagen die WordPress-Version 2.1.1 von wordpress.org heruntergeladen hat, tut gut daran raschmöglichst auf die neue Version 2.1.2 upzudaten:

Es wurde festgestellt, das sich ein Cracker Zugriff auf einen der “wordpress.org”-Server verschafft hatte und diesen Zugriff dazu benutzt hat die Downloaddatei zu verändern. Der betroffene Server wurde für weitere Untersuchungen heruntergefahren und es stellte sich heraus, daß die Downloaddatei der Version 2.1.1 (als einzige) von diesem Angriff betroffen war. Es wurden zwei WP-Dateien dahingehend verändert, daß sie Code enthielten, der die externe Ausführung von PHP-Code ermöglicht.

Dieser Vorfall bringt mich gerade wieder mal zum nachdenken, denn eigentlich bewegen wir uns alle auf ziemlich dünnem Eis. Haben wir erst einmal Vertrauen zu einer Anwendung wie WordPress gefunden, installieren wir (mehr oder weniger) blind jedes Update, ohne uns eigentlich über alle (versteckten) Funktionen im Klaren zu sein. Allerdings, und das ist auch klar, wäre es auch fast unmöglich, jedes Softwarepaket so intensiv zu testen, dass ungewollte Veränderungen sofort auffallen würden.

Wichtig zu wissen ist aber, dass nur das Installationspaket von wordpress.org betroffen ist. Die Downloaddateien von wordpress-deutschland.org sind davon nicht betroffen. Trotzdem empfehlen die WordPress-Entwickler das sofortige Update auf die Version 2.1.2.

(via S-O-S SEO Blog)

Wenn der WYSIWYG-Editor in WordPress trotz der nötigen Einstellungen in der Administration einfach nicht angzeigt wird, kann das auch am Webserver liegen. Das musste ich heute morgen bei einem Blogprojekt, welches ich technisch betreue, staunend zur Kenntnis nehmen. Offensichtlich gibt es nämlich Schwierigkeiten mit dem Editor, wenn auf dem Webserver kein gzip installiert ist, was sich in JavaScript-Fehlern wie

tinyMCE is not defined

äussert.

Ein kleiner Hack in der Datei ‚tiny_mce_gzip.php‘ im Ordner ‚/wp-includes/js/tinymce/‘ sorgte dann aber für Abhilfe. Dazu müssen in der genannten Datei die folgenden Zeilen (Zeile 132 – 142 in WordPress 2.1.1) auskommentiert oder gelöscht werden (Backup nicht vergessen!):

$enc = in_array('x-gzip', $encodings) ? "x-gzip" : "gzip";

if (!$diskCache)
ob_start("ob_gzhandler");


Wer es einfacher haben will, kopiert einfach die aktualisierte Datei tiny_mce_gzip.php vom WordPress Bug-Tracking Server, wo das Problem bereits bekannt ist.

Nach einem Leeren des Browser-Caches funktionierte der Editor dann (endlich) wie gewohnt.

Steve Smith hat Version 3.0 seines bekannten WordPress Administrations-Themes WP Tiger Admin veröffentlicht:

A complete redesign has pushed WordPress Tiger Admin into version 3. It boasts a more streamlined design, better plugin compatibility, and general all-around goodness. […] I’m very happy with the changes that were made. It’s taking on much more of my style, while leaving in a little OS X feel to it.

WP Tiger Admin benutze ich schon seit meinen Blog-Anfangszeiten, denn es ist einfach viel angenehmer zu bedienen, als die Original WordPress-Gestaltung. Und die neue Version 3.0 hat auch designmässig wieder zugelegt, wie ich finde.

Einziger Wermutstropfen für IE-User: Das Admin-Theme funktioniert, wie bereits die früheren Versionen, nicht mit dem Internet Explorer:

IE (7 or otherwise) doesn’t follow the more advanced CSS2 methods, so it get’s left out of the party.

(via Blogging Pro)

Eigentlich hatte ich mir die visuelle Trennung von Kommentaren und Trackbacks bzw. Pings schon vor langer Zeit vorgenommen. Gerrit hat das Thema vor einigen Tagen wieder aufgenommen und dadurch eine kleine Flut von Veröffentlichungen zum Thema lanciert. Grund genug, das auch hier endlich in die Tat umzusetzen und Kommentare und Trackbacks bzw. Pings getrennt aufzulisten.

Als Vorlage dazu diente mir das Listing von macx, welches ich natürlich noch entsprechend anpassen musste, aber wichtige Inputs leistete, um das Ganze hier im Blog zu nutzen. Sicher werde ich in den nächsten Tagen noch einige kleine Änderungen an der Darstellung vornehmen, aber fürs erste bin ich doch schon mal recht zufrieden…

Die von Google bereits seit einiger Zeit genutzte Technik, XML-Sitemaps zur Indexierung von Websites zu berücksichtigen, wollen nun auch Yahoo und Microsoft einsetzen. Wie Techcrunch schreibt, haben dies die drei Firmen gemeinsam bekanntgegeben.

Sitemaps sind ein XML-Dialekt zur Zusammenfassung von Informationen über eine Website, die für Webcrawler relevant sind. Für jede URL können „Hinweise“ wie das Datum der letzten Änderung und die Änderungshäufigkeit angegeben werden. Sitemaps wurde unter einer Attribution-ShareAlike Creative Commons License freigegeben und kann somit grundsätzlich von jeder Suchmaschine zur Indexierung genutzt werden.

Für die automatische Erstellung einer Sitemap unter WordPress kann ich das Plugin von Arne Brachthold nur empfehlen. Es tut seinen Dienst hier seit Juni 2005 in den verschiedensten Versionen problemlos…

Nachdem es am letzten Wochenende jemandem gelungen war, das offizielle Google Blog zu hacken und einen Post darauf zu plazieren (Screenshots und mehr Infos dazu bei Google Blogoscoped) berichtet nun auch golem.de darüber:

Schuld an dem falschen Beitrag sei ein Fehler in Googles eigener Blog-Plattform Blogger durch den ein Unbekannter unerlaubt einen Beitrag im offiziellen Google-Blog veröffentlichen konnte. Google behob den Fehler nach eigenen Angaben schnell und auch der Beitrag wurde gelöscht, was zunächst aber einige Spekulationen auslöste.

Ob der Fehler aber nur auf Googles Blogger-Plattform auftritt, darf unterdessen bezweifelt werden. Offenbar ist der Hack auf jedem Blog reproduzierbar, das über RSS und die MetaWeblogAPI verfügt. Damit dürfte eine ziemlich grosse Anzahl von Blogplattformen (wie z.B. auch WordPress) betroffen sein, denn die MetaWeblogAPI ist weitverbreitet.

Wie Randy Charles auf seinem Blog berichtet, liegt das Problem an einem Buffer Overflow:

Basically, Jason took advantage of an RSS unchecked buffer problem to post to my blog using MetaWeblogAPI. You can do the same by simply finding out what IP address a subscriber of yours is using and stuffing the buffer overflow code into your own RSS feed. When the subscribers native RSS reader polls your feed, the buffer overflow code causes blog entries to be posted on his blog. I’m not going to give specific samples because I don’t want people exploiting this problem, which exist on any desktop with Firefox, IE7 or other native RSS reader.

Auf den Seiten von WordPress herrscht dazu noch Funkstille, Jason Schramm hat hingegen bereits ein WordPress Patch gegen die Host Overflow Application Exception als Plugin veröffentlicht. Das Plugin ist jedoch verschlüsselt, um, wie Jason schreibt, Nachahmern nicht zuviele Anhaltspunkte zu geben. Allerdings weiss man so auch nicht, was das Plugin mit dem eigenen Blog wirklich anstellt. Vorsicht ist also angebracht.

Obwohl die Host Overflow Application Exception bereits seit Anfang Monat bekannt ist, scheint sich bisher wenig zu tun, bzw. liest man praktisch nichts darüber. Allerdings waren von dieser Sicherheitslücke bisher auch erst ganz wenige Blogs betroffen.

[Update]
Ääääärger! Das war wohl nix und ich bin hier einem Hoax aufgesessen, wie Dominik in den Kommentaren passend schreibt. Tja, aehm… kann in den besten Familien mal vorkommen. Hätte ich mir das Plugin wirklich runtergeladen und es mir mal angesehen, dann hätte das auch mir auffallen können. Tja, also Kommando zurück und den Post gleich wieder vergessen…

Nach den Problemen mit dem Gravatar-Server der letzten Tage hatte ich ja einige Plugins mit Cache-Funktion gefunden und habe nun das Plugin Gravatars2 von ZenPax installiert. Gravatars2 ist eine Erweiterung von Skippys Gravatars und speichert die Avatar-Bilder lokal auf dem Server. Es kümmert sich auch um die Aktualisierung der Bilder und bietet auch sonst noch das eine oder andere (konfigurierbare) Zückerchen.

Die Installation ist nicht weiter schwierig und nach der Aktivierung funktioniert das Plugin, wie es scheint, problemlos. Auch die Probleme von Michael konnte ich hier nicht nachvollziehen. Gespannt bin ich nun aber darauf, ob und wie sich die Performance des Blogs ändert, wenn der Gravatar-Server mal wieder offline ist. Dummerweise (zumindest für meinen Test) ist der Service ja derzeit wieder verfügbar.

Apropos Gravatar: „Was zum Geier sind Gravatare?“ wollte M.M. in den Kommentaren wissen. Stimmt, das sollte eigentlich auch noch kurz erklärt werden, wenn hier schon ständig davon die Rede ist. Gravatare sind die kleinen Bilder die neben einem Kommentar hier (und in vielen anderen Blogs) angezeigt werden. Wer sich auch ein solches Bild zulegen will, erstellt sich auf Gravatar.com ganz einfach ein Konto, lädt das gewünschte Bild hoch und kommentiert schon bald mit eigenem Bild…

Avatare sind (eigentlich) eine gute Sache, der Wiedererkennungswert von Kommentierenden steigt beim Überfliegen ungemein und zudem sieht man manchmal ja noch etwas vom Autor selbst. Mühsam wird das Ganze aber, wenn der Gravatar-Server langsam oder aber gar nicht erreichbar ist. Dann nämlich ist der Seitenaufbau ungemein langsamer, da der Browser stets das Bild vom Gravatar-Server laden will.

Da mich das gerade ziemlich nervt, habe ich mich nach einer Lösung umgesehen und bin dabei auf WordPress-Plugins gestossen, die die Gravatar-Bilder lokal in einem Cache lagern. Das erhöht zwar minim den Speicherbedarf und den Traffic auf dem eigenen Server, würde allerdings im Gegenzug um etwas mehr Unabhängigkeit von der Verfügbarkeit des Gravatar-Servers sorgen.

Hat irgend jemand eines der Plugins Gravatar-Cache, Gravatars oder Generic Gravatar Cache bereits im Einsatz und kann etwas zur tatsächlichen Verfügbarkeit der Gravatars sagen?

Gestylte Blogseiten sind zwar auf dem Computer nett anzusehen, auf einem PDA führt der ganze Schnickschnack aber nur zu einer grösseren Datenmenge, längeren Ladezeiten und zweitweise zu einem unmöglichen Layout. Die Lösung sind abgespeckte Layouts, die nur gerade das wichtigste anzeigen.
Das PDA Plugin von Imthiaz entscheidet aufgrund des UserAgent-Strings, ob der User nun via PDA, Mobiltelefon oder „normal“ via Computer surft und zeigt das Blog im entsprechenden Layout.

Damit funktioniert das Surfen auf meinem Blog sogar mit dem Display meines Samsung D500, das trotz installiertem Opera Mini bisher nicht wirklich zum surfen brauchbar war…

Da hätte ich ja noch stundenlang rumprobieren können: Will die Einbindung der deutschen Sprachdatei in eine WordPress-Installation einfach nicht funktionieren, könnte das daran liegen, dass der Webserver ein 64bit-System ist. Dann nämlich braucht es eine kleine Änderung in der Datei gettext.php (im Verzeichnis /wp-includes), ab Zeile 105:


// Caching can be turned off
$this->enable_cache = $enable_cache;

// $MAGIC1 = (int)0x950412de; //bug in PHP 5
$MAGIC1 = (int) - 1794895138;
// $MAGIC2 = (int)0xde120495; //bug
$MAGIC2 = (int) - 569244523;
$MAGIC3 = (int) 2500072158; // < - 64 BIT FIX: ZEILE HINZUFÜGEN! $this->STREAM = $Reader;
$magic = $this->readint();
if ($magic == $MAGIC1 || $magic == $MAGIC3) { // < - 64 BIT FIX: ZEILE ÄNDERN! $this->BYTEORDER = 0;
} elseif ($magic == $MAGIC2) {
$this->BYTEORDER = 1;
} else {
$this->error = 1; // not MO file
return false;
}

Danke an Marco Neuber für den Tipp!