WordPress 3.0 beta

Nachtrag: Ich habe gerade einen Test gemacht, und die Integration mit bbPress, die ich im folgenden (zu Archivzwecken unverändert belassenen) Artikel fraglich fand, funktioniert überraschend reibungslos. Das ist eine richtig gute Nachricht. Nun aber weiter mit dem ursprünglichen Text:

it’s like the unofficial WP slogan: we suck less with every release

Matt Mullenweg im bbPress-Chat

Da durchaus die Gefahr besteht, dass ich mich schon in ein paar Tagen oder Wochen mit der Release herumschlagen muss, weil die gegenwärtige WordPress-Version 2.9.2 ein ernsthaftes Problem geworden ist, habe ich mir die frisch veröffentlichte, frühe Beta von WordPress 3.0 heruntergeladen (Hier die Ankündigung bei der deutschen WordPress-Community). Da es sich um eine sehr frühe Beta-Version handelt, ist hier natürlich kein so strenger Maßstab anzulegen. Das neue WordPress muss erst noch fehlerfrei und reif werden, deshalb wird ja auch eine Beta veröffentlicht. Wer nicht gerade irre ist oder ganz genau weiß, was er tut, sollte die Beta nicht für ein richtiges Internet-Projekt einsetzen.

Meinen erster Blick auf die Beta habe ich mit einem lokal installierten Webserver auf einer Ubuntu Karmic Koala geworfen. (Übrigens fühlt sich Ubuntu für mich an wie Debian auf Weichspüler, aber das ist etwas ganz anderes…)

Den Code habe ich mir noch nicht angeschaut.

Installation

Also flugs eine neue MySQL-Datenbank angelegt und einen neuen MySQL-Benutzer eingerichtet, der nur Rechte auf dieser Datenbank hat. Bei einem Datenbankserver und einem Webserver, die beide auch über das große Netz zu erreichen sind, mag ich es einfach nicht, wenn in einer Konfigurationsdatei für eine Internet-Anwendung ein Benutzerkonto mit weitgehenden Rechten verwendet wird. Im Zweifelsfall geht alles schief, und an manchen Daten hänge ich einfach…

mysql> create database "wptest";
mysql> grant all on wptest.* to "brur" identified by "x93Wlq";

Wer diese Zugangsdaten wirklich benutzt, kann sich von mir eine kostenlose Ohrfeige abholen. Bei mir sehen sie natürlich anders aus

Und dann flugs die Konfigurationsdatei editieren. Holla, erste Überraschung:

Wer diese »Geheimschlüssel« wirklich benutzt, kann sich von mir kostenlos zu Tode ohrfeigen lassen…

An Stelle der bisherigen vier Anmeldeschlüssel für die Authentifizierung über das Anmeldecookie gibt es nunmehr acht. Vermutlich ist das Verfahren intern verändert worden, was Bloggern mit einer Cookie-integrierten bbPress-Forensite vorerst solange den Upgrade verbietet, bis auf Seiten von bbPress eine Anpassung an das neue Schema der Cookie-Authentifizierung erfolgt ist.

Nachdem die Konfiguration erstellt wurde, kann endlich die unschlagbar simple Installation im Browser aufgerufen werden. Und diese kommt mit einer kleinen Verbesserung daher, die sicherlich für viele eine Erleichterung ist und die zudem ein Fortschritt für die Blogsicherheit sein kann, wenn sie klug verwendet wird.

Passwortwahl

Bei der Installation wird nicht mehr automatisch der Benutzername »admin« zusammen mit einem generierten Passwort vergeben, sondern es können gleich die Anmeldedaten für den administrativen Zugang vorgegeben werden. Auch, wenn das bisherige automatische Passwort sehr trickreich konstruiert wurde, ist es doch, sollte sich darin jemals eine Sicherheitsschwäche zeigen, schwach, weil das administrative Benutzerkonto mit dem Usernamen »admin« auf einer erheblichen Anzahl von Blogs existieren dürfte. Auf diese Weise würde – sollte sich das automatische Passwort jemals als schwach erweisen – massenhaftes skriptgesteuertes Ownen von WordPress-Blogs ermöglicht. Aus dieser Erwägung heraus habe ich den initial angelegten Admin-Zugang immer nur dazu verwendet, einen weiteren Benutzer mit administrativen Rechten anzulegen und es anschließend gelöscht. Dieser lästige Arbeitsschritt bleibt nun erspart.

Aber es ist natürlich auch eine Gefahr in der neuen Möglichkeit. Wenn Elke Sorglos oder Hans Unbedarft dort einfach ihren Vornamen eingeben und – es ist ja nur ein kleines persönliches Blog, wer sollte das cracken wollen – ein leicht erratbares Passwort wählen, denn könnten in Zukunft die Blogs zunehmen, die mit einer Wörterbuchattacke übernommen werden. Auch ist es grundsätzlich unsicher, bei verschiedenen Websites und Web-2.0-Diensten das gleiche Passwort zu verwenden, da dann eine Sicherheitslücke in einer Vielzahl von verschiedenen Anwendungen schnell zur Einladung wird, auch die anderen, meist mit einer gezielten Google-Suche zu findenden Sites zu übernehmen. Von eBay und PayPal will ich gar nicht erst reden…

Also bitte etwas nachdenken bei der Wahl des Passwortes. Und zwar immer.

Das »neue« Dashboard

Obwohl sich »unter der Motorhaube« einiges getan hat, sieht es »im Cockpit« zwar etwas heller, aber noch erfreulich vertraut aus. Das recht gute Dashboard der neueren WordPress-Versionen wurde in keiner Weise »verschlimmbessert« und ein Blogger muss nicht umlernen.

Was sich unter der Motorhaube getan hat? Nun, WordPress ist jetzt mit WordPress MU, der Multi-User-Version von WordPress, zusammengewachsen und teilt die gleiche Codebasis. Im Dashboard ist davon nichts zu bemerken. Es ist nicht, wie bei MU, möglich, weitere Blogs anzulegen, und die ganzen damit verbundenen Einstellungen für mehrfache Blogs bleiben für Otto Normalblogger vollständig unsichtbar. Wer sie sehen möchte, muss in die wp-config.php nur eine Zeile einfügen:

define ("WP_ALLOW_MULTISITE", true);

Wer das tut, sollte sowieso wissen, was er tut. Das Feature ist zurzeit auch als »beta« klassifiziert und sollte noch nicht auf »richtigen« Websites verwendet werden. Bis zur Veröffentlichung von WP 3.0 kann es sich allerdings nur noch um wenige Wochen handeln, und wer es »eilig« hat, kann den gegenwärtigen Stand von WordPress MU verwenden.

Immerhin, an einer Stelle zeigt sich deutlich, dass die Entwickler WordPress mittlerweile für ein größeres Produkt als ein simples Blogsystem halten. Früher wurde bei der Installation standardmäßig als Tagline »Just another WordPress blog« eingefügt, nun heißt es »Just another WordPress site«.

Kubrick ist tot

Das neue Standard-Theme ist nicht mehr Kubrick, sondern Twenty Ten. Es handelt sich um ein sehr aufgeräumtes und ästhetisch ansprechendes Theme mit breitem Anzeigebereich:

Dieses Theme ist – im Gegensatz zu Kubrick – leicht zu personalisieren. Im WordPress-Dashboard kann eine andere Headergrafik und ein Hintergrund (auch als Grafik) für die Ansichtsbereiche außerhalb des Textes und der Navigation vergeben werden, was für viele Einsatzzwecke hinreichend sein dürfte und die Installation oder Entwicklung eines eigenen Themes oft entbehrlich macht.

So schlicht das neue Standard-Theme auf dem ersten Blick auch aussieht, es ist sehr flexibel. Die WordPress-Entwickler haben ganz offenbar mitbekommen, dass immer mehr Blogfunktionalität in Widgets untergebracht wird, unter denen eine »klassische« Sidebar geradezu zu explodieren droht, und deshalb gibt es nun sehr viele Stellen, an denen die Widgets auch verwendet werden können:

Übrigens werden nun bei der Installation die Standardelemente der Widget-Bereiche als Widgets gesetzt und nicht mehr im Theme hardgecodet. Für den Blogger, der nur »mal eben schnell« die Anordnung ändern will oder ein Widget hinzuziehen will, bedeutet dies, dass er die Sidebar nicht mehr in der Widget-Verwaltung nachbauen muss, sondern einfach loslegen kann.

Ich persönlich würde mir bei so einem Standardtheme, wenn es schon so flexibel sein soll, wünschen, dass es auch eine Einstellmöglichkeit für die verwendeten Fonts und ihre Farben und Größen auf einer Theme-Optionsseite gibt. Damit bestünde wohl häufig gar kein Bedarf mehr nach einem anderen Theme. Allerdings ist die jetzige Vorgabe in diesen Punkten sehr ausgewogen und neutral.

Und wo ich schon bei Wünschen für das neue Theme bin: Es wäre doch hübsch, wenn die neue WordPress-Funktionalität »Featured image«…

…auch vom neuen WordPress-Standardtheme unterstützt würde. Aber es ist ja noch eine Beta, und ich vermute, dass das spätestens in der Release kommt.

Subjektiver Eindruck

So weit zu meinen ersten Eindrücken von WordPress 3.0 – einen weiteren Eindruck will ich auch nicht verschweigen, obwohl er recht subjektiv ist. Insgesamt fühlt sich WP 3.0 ein bisschen flotter an als WP 2.9.x auf dem gleichen Server. Sollten sich die Entwickler die verbreitete Kritik an der »Bloatware WordPress« einmal zu Herzen genommen haben und auf ein bisschen mehr Performance geachtet haben? Bei mir ist dieser Eindruck jedenfalls entstanden. Dennoch benötigt die Erzeugung der dynamischen Seitenansichten immer noch mehr Zeit und Ressourcen als bei dem ungleich mächtigeren CMS Joomla (ebenfalls auf dem gleichen Rechner), und das ist erschreckend. Auch das kommende WordPress 3.0 könnte für ein Blog, das auch (viele) Leser hat, ohne zusätzliches Caching unbrauchbar sein.

Fazit

Der Sprung in der Versionsnummer ist allein schon wegen der nunmehr integrierten Multi-Blog-Fähigkeiten von WordPress berechtigt. Er spiegelt sich zum Glück diesmal nicht in fragwürdigen Experimenten an der Benutzerführung wider, so dass ein WordPress-Blogger keine neuen »Reflexe« beim Bloggen lernen muss.

Schon die Beta wirkt erstaunlich reif und erweckt den Eindruck, eine tragfähige technische Grundlage für die kommenden WordPress-Versionen zu sein. Besonders erfreulich finde ich neben dem frischen und flexiblen Standardtheme die subjektiv spürbare Verbesserung der Geschwindigkeit. Diese geht übrigens auch mit einer deutlichen Redukion der in JavaScript gecodeten Zeilenanzahl einher:

$ find wp3.0beta -name \*.js | xargs cat | wc -l
30951
$ find wp2.9.2 -name \*.js | xargs cat | wc -l
32811

Immerhin sind dies über fünf Prozent weniger JavaScript-Codezeilen, von denen sich der arme Browser oft erstmal erholen muss, bevor er das Arbeiten möglich macht. (Ja, ich weiß, wie oberflächlich diese Form von »Analyse« ist, aber sie gibt einen Anhaltspunkt. In Bytes betrachtet ist der Unterschied auch nur marginal. Aber es ist in der Geschichte von WordPress die erste »messbare« Schrumpfung von JavaScript-Code.)

Ich habe von den WordPress-Entwicklern in der Vergangenheit schon viel Mist gesehen (und einiges davon ist immer noch im Code), und ich durfte eine bemerkenswerte Ignoranz gegenüber Performance-Erwägungen schmecken. Nach allen diesen Jahren freue ich mich darüber, dass eine andere Richtung eingeschlagen wird. Nun muss nur noch in diese Richtung gegangen werden…

Wer ein WordPress mit einem Cookie-integrierten bbPress betreibt, sollte zunächst Abstand nehmen, bis auf Seiten von bbPress eine gangbare Lösung für die neuen Mechanismen entwickelt wurde. Ein Blick auf den Bugtracker für bbPress 1.0.3 zeigt ja, dass auch die neue bbPress-Version (endlich) vor der Tür steht, und diese wird sich gewiss in ein aktuelles WordPress integrieren lassen. Bis es so weit ist, ist allerdings Warten angesagt, wenn nicht gerade ein schweres Sicherheitsproblem auf Seiten von WordPress bekannt werden sollte.