blog@netplanet

WordPress kommt mit dem Editor namens TinyMCE daher. Das kann man als Nachteil sehen, denn jedes wirklich gute Content Management System kommt gern mit einem Editor daher, der WYSIWYG-Editieren ermöglicht, also das Template der eigentlichen Website dazu nutzt, im Editor eine Fast-wie-echt-Ansicht zu ermöglichen.

Nun gut, wir können darüber streiten, ob nun WordPress mit TinyMCE gut bedient ist oder nicht. Ich finde: Ja, es ist soweit ganz gut damit bedient. Und WordPress lebt vor allem davon, dass es in der Entwicklung selten mal gigantomanische Entwicklungszyklen hat, sondern alles nach und nach eingebaut wird.

Was wiederum viele Nutzer von WordPress am Editor stört, ist eigentlich gar keine echte TinyMCE-Schuld: Fehlende Features. Tatsächlich ist TinyMCE in WordPress in einer eher abgespeckten Variante am Start. Einer der Dinge, die am schmerzlichsten vermisst werden, sind zweifellos die Möglichkeiten, eine HTML-Tabelle in einem Artikel zu integrieren. Das kann man, wenn man den WordPress-eigenen TinyMCE-Verschnitt nutzt, nur dadurch, in dem man ein HTML-Tabellenkonstrukt über die HTML-Ansicht in den Editor hineinklatscht und den dann entsprechend editiert. So ätzend, dass man im Zweifelsfall tatsächlich eher darauf verzichtet, HTML-Tabellen in Artikel zu nutzen. Ich spreche aus Erfahrung und das nicht nur mit meinem Blog, sondern auch mit Kundenprojekten, in denen mitunter sehr schwer vermittelbar ist, dass derWordPress-Editor HTML-Tabellen aus nicht nachvollziehbaren Gründen von Hause aus nicht mag.

Eine elegante Lösung gibt es, wie immer (und die eigentliche Stärke von WordPress) per Plugin. Und da gibt es gleich eine ganze Reihe von Plugins, die sich dem Thema HTML-Tabellen widmen. Der tatsächlich eleganteste Weg ist aber, WordPress per Plugin eine “richtige” Version von TinyMCE zu spendieren. Willkommen bei TinyMCE Advanced!

TinyMCE Advanced ermöglicht nicht nur eine vollständig selbstdefinierbare Anordnung und Zusammenstellung der üblichen Buttons im Editor (mal ganz ehrlich… wer braucht schon das Symbol für die Rechtschreibprüfung?), sondern liefert auch eine Reihe von TinyMCE-Erweiterungen mit. Unter anderem eine für das Einfügen von HTML-Tabellen. Das folgende Bild spricht Bände:

Ich habe mir tatsächlich meine Symbolleiste gleich so zusammengeklickt, dass die zweite Reihe nur noch die HTML-Tabellenerweiterungen enthält und die Auswahl für die Überschriften in die erste Reihe gewandert ist. Dafür sind dann in der ersten Reihe so sinnarme Dinge wie die Rechtschreibprüfung oder die Suchfunktion weggefallen. Braucht kein Schwein bzw. das Schwein Besim nicht. (Anmerkung: Rechtschreibprüfung deshalb nicht, weil das Firefox für mich übernimmt).

Installation? Sehr einfach. Im WordPress-Dashboard in die Plugins-Rubrik wechseln (links in der Navigation der Stecker) und dort “Installieren” wählen. Dann in der Plugin-Suche “TinyMCE Advanced” eingeben, auswählen und automatisch installieren lassen. Die individuellen Einstellungen kann man dann, wenn das Plugin installiert ist, bequem in den WordPress-Einstellungen vornehmen, dort gibt es dann nämlich eine eigene Einstellungsseite für TinyMCE Advanced. Und diese Einstellungsseite ist auch wunderbar klickibunti, so dass auch Automatikfahrer zu schnellen Erfolgen kommen. Und wer absolut nicht klarkommt, kann auf dieser Einstellungsseite die gemachten Einstellungen auch wieder mit einem Klick zurücksetzen. Und wer dann doch lieber wieder kuppeln mag, kann auch einfach das Plugin wieder deinstallieren und lebt einfach so weiter, wie vorher.

Hinweis: Es gibt am Ende dieses Artikels ein nachträglich hinzugefügtes Addendum.

Die deutsche WordPress-Community hat zu ihrem diesjährigen Barcamp gestern nach Köln an die Humanwissenschaftliche Fakultät (welch wunderbarer Wink mit dem Zaunpfahl) geladen. Der Einladung war zu folgen.

“WordPress sprachfähig machen – Lokalisierung Kür oder Krampf?” von David Decker

Die Session wählte ich, weil ich mit dem Übersetzen von Open Source ja schon die eine oder andere Erfahrung habe und die andere, interessante Session in diesem Zeitslot zum Thema E-Commerce vermutlich mächtig überlaufen sein würde (was sie auch war). Davids Session war jedoch dennoch eine sehr ordentliche Geschichte zum Einstieg, da neben seinen Erfahrungen aus der Übersetzungsarbeit eine Menge Verweise auf Plugins abfielen, die ich mir notierte und die näher angeschaut werden müssen.

Generell bleibt in Sachen Internationalisation zu sagen, dass in der WordPress-Entwicklung noch eine Menge Verbesserungspotential in Sachen Übersetzung liegt. Es fiel unter anderem eine Aussage, dass die Nutzung einer Übersetzungsdatei die WordPress-Installation bis zu 44 % verlangsamt. Ich habe das zwar nie gemessen, habe aber die generelle Verlangsamung ebenfalls beobachtet. Dazu kommen die vielen Unzulänglichkeiten, die bei der Plugin-Entwicklung entstehen, wenn Plugin-Entwickler schlicht nicht berücksichtigen, dass auf diesem Planeten nicht nur Englisch gesprochen wird. Dabei wäre es so einfach, einfach eine Schnittstelle für Übersetzungsdateien zu schaffen und tatsächlich finden sich auch immer wieder Menschen, die dann auch entsprechende Übersetzungen zur Verfügung stellen.

“Spaßbremse beim Bloggen – rechtliche Rahmenbedingungen” von Maximilian Brenner

Der Rechtsanwalt Maximilian Brenner veranstaltete vermutlich einer der erfrischensten Sessions des WordCamps – nämlich die aus Sicht eines Rechtsanwaltes. Und die ist selbst in der bunten Social-Media-Welt knochentrocken und formalistisch. Mit einem brillanten Zynismus zeigte er, wie man als Blogger ruckzuck die Basis dafür schaffen kann, in stürmischeres, juristisches Fahrwasser zu kommen, was für die meisten Blogger auch der sofortige Ruin bedeuten dürfte. Und das fängt alles bei der Definition an, ob ein Blog privater Natur ist oder geschäftlicher. Privat ist es tatsächlich nur, wenn es rein private Inhalte aus Familie etc. beinhaltet und keinerlei “regelmäßige, meinungsbildende Inhalte”. Letzteres durchzuhalten, dürfte für die meisten Blogger, die nicht einmal im Jahr aus dem Urlaub bloggen, schon gehörig schwierig werden.

Ist man aus der Definition des Privatbloggers draußen, geht es dann schon los: Impressumspflicht nach § 5 TMG wegen des Anbietens eines Dienstes, Angabe eines redaktionell Verantwortlichen nach § 55 RStV, Informationen über die Verarbeitung personenbezogener Daten. Und das alles dann nicht nur im Weblog, sondern auch auf den Microblogging-Kanälen. Hier immerhin gibt es die Möglichkeit der “Zwei-Klick-Lösung”, d.h. einem direkten Link zu einem Impressum im Weblog. Prinzipiell muss aber im geschäftlichen Verkehr tatsächlich auch der Twitter-Stream mit einem Impressum versehen sein.

Anhand der vielen Notizen, die die meisten Session-Teilnehmer machten und einiger recht hilflos wirkender Fragen, die Maximilian Brenner herzlich amüsant beantwortete, nehme ich an, dass in den nächsten Tagen einige Leute ihre Impressen sehr stark umbauen werden. Inklusive meiner Person.

“Genesis Theme-Framework” von Heinz Duschanek und “Xtreme One Theme-Framework” von Alex Frison und Michael Preuß

Die nächsten zwei Session-Blöcke waren dann Framework-Geschichten. Mit Frameworks habe ich bis jetzt noch recht wenig Erfahrungen, weshalb ich einmal sehen wollte, was da geht – und da geht was.

Heinz Duschanek von der österreichischen E-Werkstatt entschuldigte sich schon zu Beginn über seinen österreichischen Akzent und verwies darauf, dass er “die Fähigkeit, Hochdeutsch zu sprechen, nach und nach verlieren wird”. Die verlor er tatsächlich auch sehr schnell, dennoch war sein Überflug ins Genesis- Theme-Framework gut und umfassend.

Mit Theme-Frameworks wird die Web-Entwicklung gehörig vereinfacht. Mit Child-Theming ist es möglich, ein bestehendes Theme mit relativ wenig Einstellungen und dem Austausch von wenigen Grafikelementen an den Kundenbedarf anzupassen. Das Genesis-Framework geht da einen umfassenderen Ansatz mit Einstellungenmöglichkeiten in Sachen SEO und vielen anderen Bereichen, während das Xtreme One Theme-Framework, in das Alex Frison und Michael Preuß einen Einblick gaben, sich auf weniger Bereiche beschränkt, hier aber erschlagend viele Einstellungsmöglichkeiten bietet. Das, was die beiden in Sachen Widget-Design zeigten, ist an Konfigurationsmöglichkeiten kaum noch zu übertreffen.

Beide Frameworks, die wie viele andere Frameworks kostenpflichtig sind, zeigen sehr anschaulich eine Entwicklung: Websites von kleineren Firmen können gut aussehen, mit WordPress ein vernünftiges CMS an Bord haben und mit einem Framework kostengünstig und effizient entwickelt werden.

“Bestehende WordPress-Seiten auf Multisite umstellen” von Walter Ebert

Walter hielt einer der inhaltlich anspruchsvollsten Sessions, in die er auf die “Erwachsenenversion” von WordPress, der Multisite-Installation einging. Für mich ist WordPress Multisite immer noch “WordPress µ”, auch wenn das natürlich nicht mehr so ist – die Multisite-Version von WordPress wird nicht mehr als getrenntes Projekt geführt, sondern steckt in jedem WordPress drin und muss nur noch aktiviert werden.

Wie das grundsätzlich geschieht, hat Walter Ebert in einem Schnellkurs beschrieben und ist dann später auch die richtig spannenden Dinge eingegangen, nämlich wie man die Inhalte aus einem Einzelplatz-WordPress in eine Multisite-Installation übernimmt. Der Artikel-Ex-und-Import ist zwar der offizielle Weg, dauert jedoch bis in die Puppen und beinhaltet immer noch die gewaltige Arbeit, alle Plugins auf der neuen Instanz manuell konfigurieren zu müssen. Das hat mich von einigen größeren WordPress-Geschichten bei uns auf dem Server immer zurückschrecken lassen.

Der Weg über einen MySQL-Dump hat Walter beschrieben, mit einigen Insider-Tipps garniert und darauf gepocht, dass der Weg gar nicht so schlimm ist, wie er sich anhört. Für mich ein Ansporn, es tatsächlich mal auf diesem Weg zu probieren. Natürlich nur mit expliziten Backups.

Fazit zum WordCamp 2011 Köln

Überraschend gut, überasschend unaufgeregt, überraschend “barcampig”, überraschend gute, inhaltliche Qualität. Zwar variiert die inhaltliche Qualität in barcamp-artige Konferenzen mitunter gewaltig (keine weiteren Kommentare, die Sessions meines “Lieblingsschlagersängers” besuche ich nicht mehr), allerdings findet man echte inhaltliche Juwelen zu dem Preis nur auf einem Barcamp. Und während die großen Barcamps inzwischen immer mehr zu Schlipsveranstaltungen von ganz arg wichtigen und an sich inkompetenten Leuten verkommen, ist das WordCamp als “Nischen-Barcamp” schön außerhalb dieser unschönen Entwicklung. Und ein Barcamp an einer Universität und dort in normalen Klassenräumen abzuhalten, ist “back to the roots”. Die Organisation war gut, das spendierte T-Shirt kommt mit einem tollen Motiv daher, die Verpflegung war herausragend und das von Netcologne gesponserte WLAN funktionierte sogar und hätte sicherlich auch noch besser funktioniert, wenn nicht jeder immer gleich alle seine zehn Gadgets am WLAN anmelden müsste.

Blogger-Kollege Jens vom Pottblog war übrigens auch da. Das heißt: Nicht immer ganz vollständig mit Körper und Verstand, aber BVB-Fans haben samstags eigentlich besseres zu tun:

Ich habe tatsächlich schon um 17 Uhr zusammengepackt und bin mit Straßen- und U-Bahn zurück zum Hauptbahnhof gefahren, um nochmal schnell eine Runde um den Kölner Dom zu fahren und staunend zu sehen, wie tausende Touristen davor sitzen und ebenfalls staunen, allerdings eher über den Kölner Dom an sich. Und vielleicht auch über die davor sitzenden und liegenden Trunkenbolde, die ja wirklich überhaupt keine Scham kennen und ihren Rausch mitten auf der Domplatte ausschlafen. Bei uns im Ländle wird sowas weggekärchert, bevor sie überhaupt ihr erstes Bier im Leben trinken.

Auch ein Erlebnis: Ein praktisch leerer ICE-Großraumwagen, den wir uns zu dritt geteilt haben. Und das erste Mal bei 300 Stundenkilometern aufs Klo gegangen. Bei der Geräuschkulisse und der Schaukelei kommt man sich in dem glänzenden Toilettenabteil vor wie im Space Shuttle. Nur was für die Harten.

Addendum vom 26. September 2011

Zum WordCamp gibt es in der deutschen Blogosphäre inzwischen ein eher durchwachsenes Stimmungsbild. Bemängelt werden da vor allem die an sich üblichen und auf dem WordCamp teilweise fehlenden “Barcamp-Gepflogenheiten” wie die fehlende Vorstellungsrunde und die weitgehend schon vorab feststehende Sessionplanung.

Kurzum: Ja, kann man monieren. Und nein, muss man nicht unbedingt. Es könnte mich durchaus nerven (was es nicht tut), wenn ich mir anschaue, wie Fans von Barcamps, die vorgeben, die Offenheit und Ungezwungenheit von Barcamps so sehr schätzen, gerade hier auf Formalien pochen, die angeblich erst ein Barcamp zu einem Barcamp machen.

Mir ist es relativ egal, ob man am Anfang eine Vorstellungsrunde macht, in der man viele Namen und viele Hashtags hört, die man im gleichen Moment wieder vergisst. Mir ist es auch relativ egal, ob eine Sessionplanung schon vorgeplante Inhalte hat (und ausdrücklich noch Raum für Ideen vor Ort) oder völlig nackt daherkommt. Ich will vor allem Dinge lernen und mitnehmen und das gern in Sessions, die gut sind und mit Leuten gefüllt, die ähnliche Ideen oder zumindest Bedürfnisse haben und mit denen man dann in Kontakt treten kann. Das ist der Mehrwert in meinen Augen.

Die Zeiten, in denen ich für eine Blog-Operation mal eben so dieses kleine, bescheidene Weblog für Stunden oder gar Tage lahmlegen konnte, scheinen vorbei. Sonst hätte der geneigte Leser gemerkt, dass gestern Abend ein Großumzug stattfand und das weitgehend ohne Ausfälle. Gestatten, dieses Weblog ist nicht mehr auf einer WordPress-Einzelinstallation zu Hause und schnattert auch nicht mehr im Chor mit den vielen anderen Einzelinstallationen auf meinem Hostingaccount, sondern alle sind jetzt Eins; alle sind jetzt in einer WordPress-Multiuser-Installation zu Hause. Hier spielt nun WordPress MU die Geige.

Im Prinzip ist WordPress MU ein ganz normales WordPress, das jedoch nicht nur ein Blog beheimatet, sondern beliebig viele. Dazu bohrt ein entsprechend konfiguriertes WordPress die Datenbankinstallation so auf, dass für mehrere Blog-Instanzen dort Tabellen angelegt werden können. Die gesamte Multiuser-Funktionalität bringt also WordPress (inzwischen) von Hause aus mit. Und tatsächlich funktionieren inzwischen auch die meisten Plugins und Themes mit der Multiuser-Umgebung, bis auf wenige Ausnahmen, für die es aber, wenn man entsprechend sucht, auch Alternativen gibt.

Die Vorteile einer Multiuser-Umgebung überwiegen deutlich:

• WordPress MU läuft deutlich flotter, als eine Einzelplatzinstallation. Warum das so ist und ob das tatsächlich mehr als nur ein gefühlter Eindruck ist… i dunno.
• Eine gemeinsame Benutzerdatenbank für alle Instanzen, was sich sehr schön vor allem dort macht, wo ein Autor auf mehreren Parketts zu tanzen hat.
• Etablierung einer einheitlichen Umgebung mit einem definierten Satz an Plugins. Jeder, der ein WordPress aufsetzt, kennt die Zeit, die man dazu verschwendet, die vielen essentiellen Plugins zu installieren, die man so braucht. Wenn ich hier ein neues Blog einrichte, greife ich auf den bereits installierten Plugin-Bestand zu und schalte mir nur das dazu, was ich in der Instanz auch wirklich brauche.
• Es gibt nur noch eine WordPress-Installation zu pflegen, der Update-Aufwand für WordPress und die mehr oder weniger vielen Plugins beschränkt sich nur noch auf diese eine Installation.

Der Zweck dieses Spaßes, an dem ich schon zwei Wochen arbeite und bei dem, wie sich das gehört, zuerst ein Kunden-Weblog daran glauben musste, bevor der Administrator sein eigenes Spielzeug umzieht, ist das Aufblasen und der Testflug eines Versuchsballons. In der Tat ist es so, dass im Providerumfeld beim Anbieten von Diensten (dem so genannten Application Service Providing) die Wertschöpfung schon beim Hosting des Dienstes beginnt. Je effizienter das Hosting ist, desto performanter laufen die Dienste, desto schneller sind sie eingerichtet und desto weniger Pflegeaufwand hat man mit ihnen.

Tatsächlich haben auch wir mit WordPress-Einzelinstallationen angefangen (man kennt das ja, “mach’ mal schnell ein WordPress klar”), aber eine Multiuser-Umgebung ist letztendlich eine unumgehbare Pflicht. Je früher man das erkennt, desto schmerzärmer wird es.

Heute hat die Truppe rund um WordPress die lange erwartete Version 3.1 des beliebten CMS veröffentlicht. Nach rekordverdächtigen 5 Release Candidates dürfte die Final Version nun hinreichend stabil sein, auch sofort eingesetzt zu werden. Sicherheitshalber teste ich das aber erst mal hier in meinem privaten Blog, das dortige Herumspielen hat eine lange Tradition.

Wie inzwischen üblich, ist die Liste der neuen Features nicht besonders umfangreich, dafür jedoch interessant:

• Verbesserte, interne Verlinkungsmöglichkeit von Blog-Artikeln
  Hierzu ist der Dialog, der sich im Artikeleditor hinter dem Linkbutton befindet, um eine Funktion erweitert worden, um interne Artikel anzuzeigen. Angezeigt werden die letzten Artikel, über eine Suchbox kann mit Stichworten nach Artikeln gesucht werden. Hinzugefügt werden kann pro Link logischerweise nur ein Artikel, will man einen weiteren Artikel verlinken, muss man einen neuen Linkbutton-Dialog beginnen. Alles in allem hört sich diese Funktion reichlich spartanisch an und das Dialogfenster sieht auch so aus, allerdings ist das dennoch erstaunlich funktional – man muss es einfach ausprobieren.
• Vorbereitung für Post Types
  Endlich ist WordPress nun mit eigenen Bordmitteln auf Post Types, also eigene Artikeltypen, vorbereitet. Das ist vielleicht einer der wichtigsten Neufunktionen, die WordPress zu der Riege der ganz großen CMS aufschließen lässt. Nun liegt es an den Entwicklern für Themes, diese neue Funktion auch in Themes einzusetzen.
• Eine Admin-Bar, ähnlich wie bei wordpress.com
  Ist bei mir eher in Sachen Priorität eher niedriger angesiedelt, wer aber bei wordpress.com mit einem eigenen Login angemeldet Blogs besucht, weiß die Admin-Bar dort zu schätzen. Es macht den Sprung von der “Vorderseite” der Website ins Backend sehr einfach – hoch auf die Seite und ab auf das Dashboard oder eine neuen Artikel angefangen.

Eher nicht so aufregend ist, dass das blaue Design im Backend “aufgefrischt” wurde. Das heißt, dass das Blau heller gemacht wurde und vom Kontrast her ebenso blaß daherkommt, wie das Grau. Das ist leider ein echter Rückschritt, schon der Kontrast des grauen Designs ist grenzwertig bei dunkel gedimmten Bildschirmen, nun ist das blaue Design auch so. Hätte man nicht machen sollen.

Was ich ebenfalls nicht in die Feature-Liste aufnehmen mag, ist der Versuch, die standardmäßige Ansicht des Editors dadurch zu verbessern, in dem nicht alle Boxen angezeigt werden, sondern nur die wichtigsten. Das ist grundsätzlich ein guter Schritt, ich vermisse jedoch nach wie vor eine Möglichkeit, eine entsprechende Ansicht als Administrator so definieren zu können, dass sie für mehrere/alle/neue Benutzer gilt.

Ansonsten: Gut! Installieren. Die deutsche Übersetzung lässt noch etwas warten, allerdings funktioniert die Übersetzungsdatei für 3.0+ soweit problemlos, bis auf den Umstand, dass eben neue Fenster und Dialoge noch nicht übersetzt sind. Verschmerzbar, weil sich die Übersetzungsdatei später problemlos per FTP ersetzen lässt.

Da viele WordPress-Nutzer vermutlich auf die kommende Version 3.1 warten (die es schon als Vorabversion in Form des Release Candidate 1 gibt), fällt möglicherweise ein Update für die 3.0-Version gar nicht so sehr auf, das gestern Abend als Version 3.0.4 veröffentlicht wurde.

Und dieses Update hat es in sich, denn es behebt ein “Critical”-BUG in der Verarbeitung von HTML. Dass das Update mehr oder weniger Hoppladihopp veröffentlicht wurde und die Update-Ankündigung mehr oder weniger gleichzeitig erschien, zeigt recht deutlich, dass man es eilig hat. Im Blog von WordPress Deutschland war man fast schneller.

Deshalb entweder in der WordPress-Installation das Update anwerfen oder bei den emsigen Freunden von WordPress DeutschlandWordPress Deutschland das Installationspaket oder auch das Update-Paket (wenn man den bisher immer schön aktuell die Updates mitgefahren ist) herunterladen und manuell via FTP in das WordPress-Verzeichnis schieben.

Das automatische Aktualisieren von Plugins, Themes und des WordPress-Kernes ist seit der Version 3.0 hübsch und einfach. Es lädt quasi dazu ein, seine WordPress-Installation aktuell zu halten und genau das ist auch das Ziel der ganzen Aktion. Auch wenn das alles nun so einfach geworden ist, gebietet es nach wie vor eine gewisse Sorgfalt, dieses Updaten.

Denn auch wenn man auf die “Aktualisieren”-Seite im WordPress-Dashboard springt und aktualisiert, sollte man tunlichst das Ergebnis dieser Aktion abwarten. Tut man dies nicht und springt während dem Update auf eine andere Seite, wird das jeweilige Update zwar fertiggestellt (im besten Falle), allerdings kann es passieren, dass der Hinweis auf den Maintenance-Mode, der immer dann eingeblendet wird, wenn ein Update vorgenommen wird, fälschlicherweise bestehen bleibt. Das zeigt sich dann an der Meldung: “Briefly Unavailable for Scheduled Maintenance.”

Dummerweise erscheint diese Meldung nach jeder WordPress-Aktion, also selbst beim Versuch, wieder zurück auf das Dashboard zu kommen. Maintenance ist Maintenance.

Die Lösung ist einfach, wenn man sie kennt: Per FTP ins Root-Verzeichnis der WordPress-Installation und dort die Datei “.maintenance” löschen. Diese Datei wird immer dann angelegt, wenn eben der Maintenance-Modus aktiviert wird und dann danach auch wieder gelöscht. Bricht man auf der “Aktualisieren”-Seite den Vorgang ab, in dem man beispielsweise auf eine andere Seite springt, wird diese “.maintenance”-Datei nicht mehr gelöscht.

Sicherlich bin ich da nicht der schnellste, aber wenn ich schon Weblogs auf WordPress 3.0.1 upgrade, kann ich auch gleich darüber schreiben. Also, WordPress 3.0.1 ist seit heute morgen veröffentlicht. Und wie die Versionsnummer zu erkennen gibt, handelt es sich um ein Wartungsupdate.

Erfreulicherweise werden in diesem Update auch nur kleinere Fehler behoben, es gibt also kein katastrophales Sicherheitsloch, das damit zu beheben wäre. Das bedeutet, dass das Update auch nicht ultradringend eingespielt werden muss, wenn man schon WordPress 3.0 einsetzt, sondern auch mal warten kann.

Wie immer kann man entweder innerhalb des WordPress-Dashboards aktualisieren, ein gesamtes Installationspaket über eine bestehende Installation laufen lassen oder auf das bewährte Update-Paket von WordPress Deutschland zurückgreifen. Letzteres hat den hübschen Vorteil, dass nur die betroffenen Dateien inkludiert sind und das Update per FTP ein Klacks ist. Bei der Gelegenheit sei darauf hingewiesen, dass auch die deutsche Sprachdatei in einer neuen Version erschienen ist, üblicherweise auch mit Ergänzungen und Fehlerbehebungen.

Es gibt so herrlich wenig darüber zu schreiben, dass es eine Freude ist.

Einer der sichtbarsten Weiterentwicklungen, die in WordPress 3.0 eingeflossen sind, ist die nun deutlich präsentere Update-Funktion, mit der einheitlich auf einer Seite alle Komponenten einer WordPress-Installation – Core-Installation, Plugins und Theme – aktualisiert werden können. Und damit die neue Update-Funktion auch gut ins Auge sticht, ist sie gleich im Dashboard-Menü integriert:

Die Ziffer hinter “Aktualisierungen” gibt hierbei an, wie viele Updates insgesamt zur Verfügung stehen. Klickt man auf “Aktualisierungen, geht es auf die Update-Seite, die von oben nach unten die Core-Installation behandelt (inklusive der Möglichkeit, eine vorhandene WordPress-Installation neu zu installieren), Plugins und Themes (klicken für Großansicht):

Hübscher geht es kaum noch, wobei ich den Textblock zum Updaten der WordPress-Core-Installation zu überfrachtet und zu unübersichtlich halte. Das hätte man ähnlich wie weiter unten bei “Plugins” realisieren können. Aber immerhin.

Endlich, endlich, endlich, die finale Version von WordPress 3.0 mit dem Arbeitsnamen “Thelonious” ist soeben veröffentlicht worden. Damit hat sich dieses Release – fast wie üblich – um einige Monate verspätet, aber da die letzte Version keine wirklich großen Sicherheitsprobleme hatte, war es zu verschmerzen.

Über die größten Änderungen, die WordPress 3.0 mitbringt, habe ich schon vor einer Weile, nämlich schon im März (!) gebloggt, daran hat sich im Prinzip nicht viel geändert. Was auffällt, sind vor allem Details im Dashboard, aber das muss ich alles erst noch entdecken. Zumindest ist jetzt aber die bisher getrennte Pflege von WordPress und WordPress MU (“Multiuser”) endgültig Geschichte geworden – es gibt nur noch WordPress.

Wichtig für die Upgrader ist, dass das Upgrade wieder mal einfach funktioniert – völlig problemlos. Es sei aber wie immer stärkstens empfohlen, vor dem Upgrade eine Sicherung der WordPress-Datenbank und des WordPress-Verzeichnisses zu machen. Da man das eh nie macht, ist das immer eine gute Gelegenheit, wenigstens eine Art “Jahressicherung” zu machen.

Die deutsche Übersetzung ist wie immer auch schon fertig. Man kann bedenkenlos schon die eingedeutschte Version der Folks von WordPress Deutschland nehmen, das dann beispielsweise in der WordPress-Anmeldung auch einen sichtbaren Hinweis auf die deutsche Version einblendet oder einfach die englische Version und danach die deutsche Sprachdatei installieren. Und der Vollständigkeit halber auch noch ein Verweis auf den Blog-Eintrag zu WordPress 3.0 von WordPress Deutschland – Ehre denen, denen Ehre gebührt.

Mit einer korrekt installierten WordPress-Umgebung gibt es bei den meisten Webhostern keine Probleme, aus der Administrationsoberfläche heraus dateioperative Dinge zu tun, die das Hochladen von zusätzlichen Dateien in die WordPress-Installation erfordern, beispielsweise die Installation von Plugins. Für Situationen, in denen das nicht funktioniert (beispielsweise aufgrund fehlender Rechte), haben die WordPress-Entwickler eine Hintertüre eingebaut, über die das per FTP erledigt werden kann.

Kann WordPress demnach nicht selbst Dateien hochladen, fragt es den Benutzer nach FTP-Zugangsdaten, die der Benutzer hinterlegen kann. Das Problem hierbei: Einmal hinterlegte FTP-Zugangsdaten kann man nicht mehr in der WordPress-Administrationsoberfläche löschen und die Daten auch nur dann ändern, wenn der Login fehlschlägt, denn nur dann blendet WordPress nochmal das Fenster zum Eingeben der FTP-Zugangsdaten ein. Das ist unkomfortabel, aber immerhin im Backend lösbar. Dazu ist allerdings Zugriff auf die WordPress-Datenbank per PHPmyAdmin notwendig.

Und gleich die obligatorische Warnung: Wer nicht fit mit PHPmyAdmin ist und wer nicht fit darin ist, Dinge aus der WordPress-Datenbank zu löschen, sollte hier bitte die Finger weglassen oder zumindest die Datenbank vor der Operation wegsichern. Ich habe es gesagt.

Und hier nun Punkt für Punkt:

1. Genau das, was ich oben gesagt habe – zuerst die WordPress-Datenbank sichern. Jetzt. In PHPmyAdmin also oben auf die Registerkarte “Exportieren” gehen, voreingestellt alle Tabellen der Datenbank markiert lassen. Weiter unten den Exporttyp auf “INSERT” belassen und ganz unten in der “Senden”-Box eine Komprimierung wählen, damit die Exportdatei nicht allzu groß wird, “Zip” dürfte seinen Zweck erfüllen.
2. (Punkt 1 getan? Falls nein, bitte dann jetzt nachholen.)
3. In der WordPress-Datenbank links in der Tabellenübersicht die Tabelle “wp_options” mit einem Klick auswählen. Wer in seiner WordPress-Installation in der wp-config.php einen anderen Präfix für seine Tabellen in der WordPress-Datenbank angegeben hat, ersetzt das “wp” mit seiner benutzerdefinierten Präfix.
4. In der Tabellenübersicht zu “wp_options” nun auf die Registerkarte “Suchen” klicken.
5. Nun eine “Suche über Beispielwerte” starten, das ist der Kasten unten. Hier beim Feld “option_name” rechts in der Spalte “Wert” den Suchbegriff “ftp_credentials” (ohne Anführungsstriche) eingeben und auf OK klicken. Das Suchergebnis wird dann ein Ergebnis aufführen, nämlich genau den Datensatz, der im Feld “option_name” den Eintrag “ftp_credentials” enthält. Dieser Datensatz enthält nun im Feld “option_value” die FTP-Zugangsdaten.
6. Den gefundenen Datensatz ersatzlos löschen, also vorne auf das rote Kreuzchenfeld klicken. Es wird nochmal von PHPmyAdmin gefragt, ob man das wirklich tun möchte. Bestätigen, ja, wir wollen das.

Ist dies getan, sind ab diesem Moment die hinterlegten FTP-Zugangsdaten aus der WordPress-Konfiguration entfernt. Sollte WordPress wieder FTP-Zugangsdaten anfragen, dann bedeutet dies, dass die WordPress-Installation keine Rechte hat, die jeweilige Dateioperation mit den Rechten des Webservers auszuführen.