Die WordPress-Dramen und der admin-Benutzer.

Fassen wir einfach mal zusammen, dass der 2.8-Versionsstrang von WordPress offenbar unter einem nicht sehr guten Stern steht. Nicht alles kann auch im besten Projektmanagement immer rund laufen und Sicherheitsprobleme mit Software wird es so lange geben, wie Menschen, die die Software schreiben. Jammern ist also eher nicht angebracht, denn niemand hat gesagt, dass WordPress von Hause aus fehlerfrei ist. Bei WordPress ist es mindestens genauso wichtig, die Installation aktuell zu halten, wie sie überhaupt einmal zu installieren.

Andererseits: Das Sicherheitsproblem in der Version 2.8.3 beruht darauf, dass ein Außenstehender das Passwort für den admin-Benutzer löschen kann. Würden bitte die Leute, die tatsächlich nur mit diesem admin-Benutzer ihr Blog verwalten, bitte verstehen, dass man mit einem admin-Benutzer gefälligst nichts anderes tun sollte, als lediglich die zentralen Blog-Einstellungen einzustellen und einen weiteren, normalen Benutzer einzurichten, mit dem dann ausschließlich gearbeitet werden sollte?

Niemand, wirklich niemand muss mit dem admin-Benutzer arbeiten. Richtet euch also bitte in WordPress und gern auch in jeder anderen CMS-Installation, die eine Mehrbenutzerverwaltung hat, gefälligst einen eigenen Benutzer ein, gebt dem meinetwegen administrative Rechte, wenn es euch schöner macht und arbeitet ausschließlich mit dem, ihr Affen!

“netplanet 4G.”

Ein alter Projektname für ein neues Ding. Der letzte netplanet-Relaunch aus dem Jahr 2003 lief unter dem Projektnamen “netplanet 3G” und irgendwie hören sich solche Projektkennzeichnungen so richtig professionell an, weshalb ein EDV-Projekt immer zuerst mit der Auswahl des Projektnamens zu beginnen hat.

Ich habe mich jetzt endgültig für WordPress als CMS entschieden. WordPress ist hinreichend flott, enthält alle notwendigen Dinge, die ich brauche, bietet auch genügend Raum für ein paar Spezialitäten und ich kenne mich damit dank Blog schon recht gut aus. Das ist dann allerdings auch der einfachste Schritt gewesen.

Im Gegensatz zum letzten Relaunch wird das Pferd diesmal von der beschwerlichen Seite aufgezäumt, denn ich werde nach dem Aufsetzen der Baustellen-Installation erst einmal den Content importieren und bei der Gelegenheit eine Rechtschreibkontrolle ansetzen. Denn schon beim ersten testweisen Importieren eines Artikels haben mir die dollsten Fehler entgegengelächelt. Das bedeutet also, dass der HTML-Code bereinigt werden muss, danach eine Rechtschreibkontrolle fällig ist, ggf. Bilder gesondert in die WordPress-Mediathek importieren werden und eventuell ausgehende Links als WordPress-Links in die Linkdatenbank aufgenommen werden. Der Content, der also bisher flach in einer HTML-Datei lag, muss nun aufgesplittet und in verschiedene Mechanismen aufgeteilt werden. Eigentlich ein idealer Praktikantenjob. 😉

Wie geht es also jetzt weiter? Vor allem erst einmal weitgehend unsichtbar.

netplanet goes CMS.

Am vergangenen Sonntag, an dem netplanet übrigens mal eben 11 Jahre alt geworden ist, habe ich nach einigen kleinen Tests in meinem kleinen CMS-Labor einen wegweisenden Entschluss gefasst: netplanet wird auf ein Redaktionssystem umgestellt. Ich gebe zu, dass netplanet damit vermutlich zu den allerletzten Websites im Internet gehört, die das nun endlich mal tun. Ich will das aber mal kurz begründen, warum das erst jetzt passiert.

Mit netplanet habe ich ursprünglich zu einer Zeit gestartet, in der ich noch unter Windows 95 arbeitete, mit einem 56k-Modem ins Internet kam und der telekomsche Gebührenticker noch einer meiner größten Sorgen als Netizen war. An Redaktionssystem war zu der Zeit gar nicht zu denken, zumindest finanziell nicht. Und so Sachen wie Wikis, Blogs schon gar nicht, es gab noch nicht einmal Google. 🙂

Die erste Fassung von netplanet (die Harten von euch erinnern sich noch an den schwarzen Hintergrund) war deshalb sehr krass in einzelnen HTML-Dateien und mit Frames aufgebaut. Die zweite Fassung kam dann ein halbes Jahr später und hatte dann immerhin schon einen weißen Hintergrund und erst vier Jahre später wurden die Frames ausgemustert und zugunsten von Server Side Includes ausgetauscht. Das ermöglichte dann immerhin eine gewisse Dynamik mit einbindbaren HTML-Fragmenten, ich konnte aber immer noch lokal damit auf meinem PC arbeiten, ohne ständig online sein zu müssen. Der Abgleich erfolgte dann per FTP und einem relativ schmutzigen Synchronisierungsscript.

In der Zwischenzeit leben wir in einer Welt, in der es von freien Redaktionssystemen nur so wimmelt. Da ich inzwischen auch nicht wenig online lebe und auch dieses Blog ja letztendlich auch komplett online gepflegt wird, ist der Schritt einfach fällig geworden.

Und ja, ich hatte für eine Weile auch das Gedankenexperiments eines “netplanet-Wiki”. So sehr ich die Wiki-Idee gut finde – hier passt es nicht. netplanet mache nur ich und das bleibt aller Voraussicht nach auch weiterhin so. Im übrigen haben Wikis für mich immer einen permanenten “Baustellencharakter” (was ich ja gar nicht unbedingt schlecht finde), das möchte ich so nicht.

Die nächste Frage ist die, welches CMS eingesetzt werden soll. Da gehöre ich zur mutigen Fraktion und tendiere hier zu WordPress. WordPress ist so unglaublich flexibel und die Auswahl an Plugins bei keinem anderen System so vielfältig. Außerdem kenne ich mich damit aus, die Entscheidung muss ein paar Jahre halten und wir wollen bei alldem nicht vergessen, dass netplanet ein vergleichsweise kleines Projekt ist – wir reden hier immer noch von rund 2,6 Megabyte (!) Content inklusive Bilder, alles verteilt auf etwa 400 Dateien und bequemen 5 Gigabyte Datenverkehr im Monat.

Zusammengebracht, was zusammengehört.

Endlich, endlich, endlich scheint in Sachen “deutsche WordPress-Übersetzung” ein Ruck durch die Verantwortlichen gegangen zu sein. Wie WordPress Deutschland heute im Blog meldet, gibt es zukünftig nur noch eine deutsche Übersetzung und nur noch eine Version der Du-Übersetzung und der Sie-Übersetzung. Das Hin und Her mit der “guten” Übersetzung von wordpress-deutschland.org und der “bösen” von de.wordpress.org scheint damit der Vergangenheit anzugehören. Ein weiser Schritt, der nun endlich eine große Hürde für Anfänger und für Entscheider reißt.

Beide Websites werden allerdings weiterhin unterschiedlich aussehen, es wird folgende Unterschiede geben:

  • Auf der Website von WordPress Deutschland gibt es neben den reinen Übersetzungsdateien (der Du- und Sie-Version) auch ein vollständiges WordPress-Installationspaket, das neben der Übersetzungsdatei auch noch einige weitere Übersetzungen enthält, die hartcodiert sind, also im Quellcode übersetzt werden müssen.
  • Auf de.wordpress.org gibt es demnach nur die offizielle, englischsprachige WordPress-Version zum Herunterladen. Die Übersetzungsdateien werden separat angeboten, sind aber nun die gleichen Übersetzungsdateien, die auch auf WordPress Deutschland angeboten werden.

Fisch geputzt, endlich. Das wird sich jetzt vor allem auf die automatischen Update-Funktion auswirken, die nun vereinheitlicht werden kann und die nicht mehr wie bisher bei der “guten” Version ein notwendiges Update anzeigt, wenn es die “böse" Website meldet. Es wird nun endlich alles wieder gut.

WordPress 2.8.2.

Leider darf der WordPress-Admin nach so kurzer Zeit wieder ran und updaten. Keine zwei Wochen nach der Veröffentlichung von WordPress 2.8.1 ist nun 2.8.2 mit einem wichtigen Sicherheitsupdate am Start, das einen Fehler in der XSS-Implementierung behebt. Dass die WordPress-Entwickler so flott ein Update einschieben, darf ruhig als Warnung und als dringenden Hinweis verstanden werden, dieses Update so schnell wie möglich einzuspielen.

Siehe WordPress 2.8.2 DE-Edition und Upgradepaket von WordPress Deutschland.

Das dort angebotene Upgradepaket ist übrigens eine sehr hübsche Angelegenheit für genau solche kleinen Updates, denn in diesen Upgradepaketen sind nur die Dateien beinhaltet, die auch tatsächlich ausgetauscht werden müssen. Mit einem halbwegs vernünftigen FTP-Client und etwas Scriptgebastel kann man sich da auch für eine größere Liste an zu aktualisierenden Webservern mit etwas sorgfältiger Vorarbeit das Leben deutlich erleichtern.

WordPress 2.8.1.

Einigermaßen überraschend kommt die Meldung gerade eben, dass WordPress 2.8.1 veröffentlicht wurde. Offenbar hat man auf das heute bekannt gewordene Sicherheitsproblem, mit dem weniger privilegierte Benutzer unter Umständen Zugriff auf Plugin-Einstellungen bekommen könnten, reagiert. Witzigerweise scheinen selbst die Jungs bei WordPress selbst noch ziemlich am Werk zu sein, denn während WordPress-Installationen bereits ein Update anbieten und auf dem WordPress-Server schon die 2.8.1 Final steht, steht rechts unten noch ein Artikel zum Release Candidate 1 der Version 2.8.1. Bei den Kollegen von WordPress Deutschland ist bis zum jetzigen Zeitpunkt noch gar nichts von 2.8.1 zu sehen (wohl wurde aber schon angekündigt, dass in den nächsten Tagen etwas kommt.

Generell: Update empfiehlt sich dringend.

Lösung zweier latenter WordPress-Probleme.

Ich kann es nur wiederholen – ich mag die Folks von WordPress Deutschland, sie machen ihren Job einfach klasse. Heute gibt es nämlich zwei Lösungsansätze für zwei WordPress-Problemchen, die zwar nicht wirklich schädlich, aber nervig sind.

Zum einen die Problematik mit dem Ping und der zu kurzen Timeout-Zeit, zu der es leider nach wie vor keine Lösung gibt, so dass man die Timeout-Zeit in der betreffenden Datei manuell hochsetzen sollte. Dass dieses Problem nach wie vor existiert, hatte ich vor einigen Tagen selbst bemängelt. Ich verstehe bei solchen Dingen die WordPress-Entwickler manchmal nicht – warum machen die für solche Dinge nicht einfach einen Schalter in den Optionen und gut ist? Soll doch bitte jeder selbst entscheiden, ob er Performance oder Zuverlässigkeit haben möchte. Mannometer…

Zum anderen die Problematik, dass heute morgen selbst bei frisch upgedateten WordPress-Installationen die Meldung erscheint, dass „WordPress 2.8 verfügbar“ sei. Das liegt leider schon wieder/immer noch daran, dass es neben wordpress-deutschland.org (den „Guten“) noch de.wordpress.org (die „weniger Guten“) gibt und eine WordPress-Installation per default letzteres abfragt. Leider stellen sich die WordPress-Entwickler auch hier noch auf taube Ohren. Dabei wäre es endlich mal Zeit, zu begreifen, dass die Folks, die sich unter de.wikipedia.org de.wordpress.org verstecken, die eigentlichen Protestler waren, die wirklichen Sprachdateienpfleger aber unter WordPress Deutschland hausen und auch die bessere Arbeit machen.

WordPress 2.8 RC1.

Das war wieder klar, dass ich mir unbedingt den Release Candidate 1 von WordPress 2.8 installieren muss. Aber Testen muss eben sein, bevor ich eine neue Version auf die Horde der WordPress-Installationen loslasse. Deshalb muss mein Blog mal wieder daran glauben. Allerdings passiert inzwischen selten etwas, die wirklich grundlegende Rettungsmaßnahmen erfordern würden.

Wer warten möchte (und im Zweifelsfall das auch sollte), wartet auf die Final Version, die dürfte erfahrungsgemäß diese Woche noch erscheinen, angepeilt ist der morgige Mittwoch.

Installation

Ist so wie immer, es passiert atemberaubend wenig. Ich muss zugeben, ich bin weiterhin ein Fan der traditionellen FTP-Upgrade-Linie, ziehe also das Zip-File mit der WordPress-Installation, packe es auf meinem Rechner aus, entferne all den Salat, den ich nicht brauche (Themes, Plugins etc.) und ballere das dann per FTP auf den Server. Das deshalb, weil ich zu Hause eine Grundinstallation von WordPress mit allen von mir bevorzugten Plugins pflege, sozusagen also mein kleiner Universalwerkzeugkoffer.

Nach dem Herüberschieben wünscht WordPress beim nächsten Zugriff in den Admin-Bereich ein Update der Datenbank, was wie immer problemlos passiert. Danach sieht eigentlich alles erst einmal aus, wie immer. Mit einer 2.7.1-Sprachdatei sollte man weitgehend klarkommen, bis die Folks von WordPress Deutschland die 2.8-Sprachdatei veröffentlichen.

Die Benutzeroberfläche und das Dashboard

Dankenswerterweise haben die Folks von WordPress nicht schon wieder alles auf den Kopf gestellt, sondern behalten die GUI-Linie weiter. Nach dem Update sieht also alles wie vorher aus, selbst die Position der Boxen. In den Optionen lässt sich nun aber die Spaltenzahl auf 1 bis 4 ändern. Mehr als die bisherigen 2 lohnen sich aber erst bei einem Breitbildschirm, dann aber wird es sehr effektvoll. Im Editor kann man übrigens nun auch die Spaltenzahl für die Boxen einstellen, hier aber nur zwischen 1 und 2. Ersteres bringt dann wieder einen ähnlichen Aufbau wie zu Frühzeiten von WordPress.

Die Benutzeroberfläche hat auch noch ein paar andere Faceliftings erhalten. Etwas umgewöhnen darf man sich in der Plugins-Übersichtsseite, denn dort gibt es keine eigenständigen Blöcke für deaktivierte und kürzlich deaktivierte Plugins mehr – alles ist in einem Block und deaktivierte Plugins sind grau unterlegt.

Ebenfalls runderneuert ist die Übersichtsseite für Widgets in der Design-Rubrik, hier sieht es auf den ersten Blick etwas unübersichtlich aus, was sich aber schnell ändert. Links stehen die verfügbaren Widgets, rechts die Sidebars, in die Widgets eingefügt werden. Es kann wie üblich verschoben werden. Neu ist unten die Box in deaktivierte Widgets, in die Widgets “zwischengeparkt” werden können, wenn man sie vorläufig nicht mehr braucht, man aber die Einstellungen nicht verlieren möchte. Leider gibt es von Hause aus immer noch keine vernünftige Widget-Steuerung, mit der man beispielsweise Widgets für bestimmte Seiten deaktivieren kann.

Eine nette Neuerung gibt es im Editor der Design-Rubrik, denn der zeigt nun den Quellcode “highlighted” an, also mit markiertem HTML-Code. Dazu gibt es nun endlich auch eine Zeilennummernansicht.

Pingback-Bug-Problem

Wer sich erhoffte, dass die Problematik mit dem Pingback-Timeout nun behoben wurde, wird sich vermutlich etwas enttäuscht zeigen. Wir erinnern: Vor einigen Monaten hat jemand herausgefunden, dass die Timeout-Zeit für die Rückmeldung von Pingbacks in der Datei cron.php (im Ordner “wp-includes”) auf 0,01 sec (bzw. in der amerikanischen Schreibweise: 0.01) steht und das bei einer größeren Zahl von anzupingenden Websites möglicherweise nicht ausreicht. Der Workaround war der, die betreffende Zeile namens:

wp_remote_post( $cron_url, array('timeout' => 0.01, 'blocking' => false, 'sslverify' => apply_filters('https_local_ssl_verify', true)) );

zu suchen und dort den Wert von “0.01” auf “1” umzustellen. Leider steht im RC1 (und vermutlich dann auch in der Final) der Wert immer noch auf 0.01, so dass man hier wohl oder übel wieder per Hand ran muss, wenn beim Schreiben von Artikeln Pingbacks vermisst werden. Offenbar will das WordPress-Team dieses Verhalten derzeit auch nicht ändern, wenn man sich das entsprechende Ticket anschaut.

Grobes Fazit zu WordPress 2.8 in einem Satz

Moderater Feature-Ausbau, durchaus installationswert.

Neuerungen in WordPress 2.8.

WordPress 2.8 ist schon seit einigen Tagen in der Beta-Phase, so dass mit dem ersten Release Candidate und der meist sehr kurz darauf folgenden finalen Version in den nächsten Tagen gerechnet werden kann. Und wenn die Version 2.8 auch nicht unbedingt die „Oberburner“-Version ist, bringt sie doch ein paar interessante Änder- und Neuerungen, die sich die wackeren Folks des WordPress-Deutschland-Blogs zum Thema gemacht haben.

Besonderer Schwerpunkt liegt auf das Admin-Menü, das nun ein leichtes Facelifting bekommt und besser auf eigene Vorlieben angepasst werden kann. Und auch gegen so peinliche Dinge wie fehlende Zeitzonenauswahl oder die Einstellung der Sommerzeit wurde gearbeitet, so dass nun beide Zeiteinstellungen justierbar sind.

Ich denke, ich werde mir an dieser Stelle wieder den Release Candidate einschenken, wenn dieser demnächst erscheint. Ich bin halt ein unbelehrbarer Bastelkopf. 😉

Probleme mit Firefox, WordPress und Google Gears.

Gestern habe ich ein höchst merkwürdiges Problem beobachtet. Ich schreibe einen Artikel im WordPress-Editor und möchte ein Bild einfügen. Dazu klicke ich auf das Bild-einfügen-Symbol über dem Editor und danach stürzt sofort Firefox ab. Gut, denke ich, kann passieren. Nochmal Firefox starten, zwischengespeicherten Artikel hervorholen, Bild-einfügen-Symbol klicken und schon wieder Firefox-Absturz. Na klasse. Ich habe dann gestern nicht mehr weiter daran geschustert, sondern den Artikel unsäglicherweise mit dem Internet Explorer 8 geschrieben.

Umso erstaunter war ich gerade, als ich genau das gleiche Verhalten nun auch mit meinem Firefox im Büro beobachte. Artikel schreiben, Bild-einfügen-Symbol klicken, Absturz. Okay… mal eine andere WordPress-Installation testen, ich habe ja genügend. Und siehe da: Seit gestern stürzt nun Firefox (aktuelle Version 3.0.10) bei allen WordPress-Installationen (sind alle bei 2.7.1), die ich unterhalte, an genau der gleichen Stelle ab! Nett, nicht?

Also, ran ans Gebälk und die Firefox-Installationen verglichen, hier vor allem die Add-Ons. Dazu sei allerdings angemerkt, dass in den letzten Wochen in beiden Browser-Installationen keine Add-Ons hinzukamen oder signifikant geändert wurden. Der erste Griff führte dann auch aus dem Tunnel heraus, als ich testweise Google Gears deaktiviert habe. Siehe da: Firefox hält wieder.

Google Gears ist ein Werkzeug, mit dem Web-Applikationen dafür sorgen können, Teile ihrer Installation auf lokale Rechner abzulegen und dort auszuführen, beispielsweise JavaScript-Bibliotheken oder ständig zu ladende Grafiken von Administrationsbereichen. Daraus ergibt sich dann in der Regel ein durchaus spürbarer Geschwindigkeitsgewinn. Die Gears-Unterstützung von WordPress kam mit der Version 2.6 und funktionierte eigentlich auch prima bei mir, allerdings nun eben seit gestern nicht mehr.

Es hilft übrigens auch nicht, die betreffenden WordPress-Installationen in den Gears-Einstellungen aus dem Caching wieder herauszunehmen. Ich muss tatsächlich Google Gears total im Firefox deaktivieren, erst dann führt ein Klick auf das Bild-einfügen-Symbol im Firefox wieder zum Auswahlfenster und nicht mehr zum Absturz.

Beobachtet jemand derzeit ähnliches?