Gerümpelkammer WordPress-Mediathek.

Kennt ihr die Szene im Bonusmaterial von Findet-Nemo-DVD, in der Nemo, Marlin, Dorie und der Haifisch Bruce herumalbern und der kleine Clownfisch Nemo, der sich mit Bruce angefreundet hat, in seinem Magen schwimmt und da so Sachen wie ein Surfbrett findet? So erging es mir heute bei der Datensicherung einer WordPress-Installation.

Mit einigen Kunden habe ich Wartungsverträge für ihre WordPress-Installationen. Updates zu installieren, ist eine Sache (die auch viel zu wenig WordPress-Nutzer machen), aber das Drumherum ist entscheident. Zum Werterhalt einer Software-Installation gehört nämlich auch eine Datensicherung, die ich in allen Wartungsverträgen beinhalte.

Also, per SFTP eingeloggt und das gesamte WordPress-Verzeichnis am Herunterkopieren. Und da schaut man so mit einem Auge, wie die Dateien im FTP-Log vorbeiflitzen, am spannensten natürlich die Upload-Verzeichnisse der Mediathek mit den vielen JPG-Bildern … moment … photoscape.exe? Und filezilla.exe? Hu? Surfbrett und so. Nachdem das Kopieren und Sichern beendet war, schaute ich mir das mal näher an: Tatsächlich hatte der Kunde in seiner WordPress-Mediathek ein Bildbearbeitungsprogramm und FileZilla hochgeladen, säuberlich als Setup-Dateien. Also tatsächlich die EXE-Dateien, mit denen auf einem Unix-Server und auch in einer WordPress-Installation so ziemlich gar nichts gemacht werden kann außer Speicherplatz wegfressen lassen.

Nach kurzer Rücksprache mit dem Kunden war die Rätsels Lösung sehr einfach: Er hatte wohl einen Satz von mehreren Bildern hochladen wollen und alles fein säuberlich auf dem Desktop zum Drag’n’Drop markiert – inklusive noch einigen „Kollateralschäden“, die natürlich auch alle brav hochgeladen wurden. Und dann aus dem Auge, aus dem Sinn und alles blieb schön über Monate auf dem Webserver.

Ein guter Ansporn, der Mediathek jetzt mal beizubringen, nur bestimmte Dateitypen zu akzeptieren und zukünftig sicherlich keine EXE-Dateien mehr.

Erste Hilfe bei plötzlich defekter Kommentarfunktion in WordPress.

Gerade habe ich eine Mail von einem Blog-Leser bekommen, der sich darüber beklagte, dass die Kommentarfunktion in diesem Weblog defekt sei. Gleich mal gecheckt und tatsächlich – so bald man versuchte, bei einem Artikel in diesem Weblog einen Kommentar zu senden, kam folgende PHP-Fehlermeldung:

Warning: get_object_vars() expects parameter 1 to be object,
null given in /webseiten/wpmu_netplanet/wp-includes/comment.php
on line 171

Ich hätte eigentlich auch schon etwas früher darauf kommen können, dass irgendetwas schief läuft, denn ich lasse mir neue Kommentare per Mail schicken und in den letzten Tagen sahen diese Mails folgendermaßen aus:

Ein neuer Kommentar zum Beitrag "TiddlyWiki 5 im Betatest."
wartet auf deine Freigabe.
http://blog.netplanet.org/2014/01/03/tiddlywiki-5-im-betatest/

Autor:  (IP:  , )
E-Mail : 
URL: 
Whois: http://whois.arin.net/rest/ip/
Kommentar:

Eine Kommentar-Mail ohne Inhalt, was bedeutet, dass WordPress zwar scheiterte beim Speichern eines Kommentares, aber immerhin die Kommentarlogik zumindest einmal gestartet wurde. Da war also tatsächlich etwas kaputt.

Bei so etwas gilt normalerweise immer das Standardprogramm an Debugging:

  1. WordPress aktuell? (Ist aktuell.)
  2. Plug-Ins installiert, die ggf. inkompatibel sein könnten?
  3. Ggf. Theme mit Problem?
  4. Datenbank bzw. Tabellen inkonsistent oder defekt?

Alle drei Problemfelder konnte ich zumindest ausschließen. Mein WordPress ist aktuell, an kommentarfunktionsspezifischen Plug-Ins habe ich in den letzten Woche nichts geändert und das Blog-Theme ist uralt und die Kommentarfunktion funktionierte vor ein paar Tagen ja auch problemlos. Zudem: Dieses Blog hier ist so aufgebaut, dass es nicht auf einer einzelnen WordPress-Installation läuft, sondern in einer Multiuser-Installation. Die anderen Weblogs auf dieser Installation laufen problemlos und insbesondere die Kommentarfunktion läuft in den anderen Blogs einwandfrei.

Das Problem ist dann letztendlich nur noch an einer Stelle zu suchen gewesen und da war dann auch das Problem: In der MySQL-Datenbank, genau genommen in den Tabellen für diese Blog-Instanz und dort in den zwei Tabellen wp_comments und wp_commentmeta. Diese beiden Tabellen, die es in einer Multiuser-Umgebung für jede Instanz gibt und die Kommentare des jeweiligen Blogs enthalten, waren inkonsistent. Das bedeutete dann, dass WordPress beim Versuch, einen abgesendeten Kommentar in die Datenbank zu schreiben, scheiterte und obige Fehlermeldung produziert. Die ist leider weitgehend nichtssagend, weil sie den Laien in die falsche Richtung führt, aber so bald die entsprechenden Tabellen z.B. in phpMyAdmin repariert werden, funktioniert alles wieder. Kleiner Fehler, große Wirkung.

Also: Kommentarfunktion in diesem Blog geht wieder. Wer in den vergangenen Tagen etwas schreiben wollte und an der defekten Kommentarfunktion scheiterte, darf das nun nachholen. 🙂

WordPress, RSS und die Möglichkeit einer Digest-Seite.

Seit einiger Zeit brüte ich über eine akute Schwäche vieler Weblogs: Da hast du ein Weblog, sogar richtig viele Hundert Artikel drin und es kommt ein Neuleser. Der findet auf den ersten Blick auf der Startseite erst einmal nur die zehn Artikel und mehr nicht. Vielleicht gibt es noch einen Einführungsartikel, aber der steht meist nicht auf Seite 1 und macht generell nur verhältnismäßig wenig Eindruck auf den Leser.

Nun gibt es bei Web-Entwickler zwei Fraktionen: Die einen, die ein Blog darin sehen, dass auf der ersten Seite bereits das Blog passiert und die ersten zehn Artikel dort aufgeführt werden und die anderen, die die Seite 1 eines Blogs lieber als Portal haben möchten und Artikel dort anteasern. Ich bin – für ein Weblog wohlgemerkt – Anhänger der Theorie 1. Ein Blog muss auf Seite 1 passieren. Das ist das größte Unterscheidungsmerkmal zu einer normalen Website.

Nun aber zu der besagten Schwäche: Wäre es nicht wenigstens schön, wenn es eine Seite 2 gäbe mit echten Highlight-Artikeln aus der Blog-Vergangenheit? Wie oft schreibt man einen Blog-Artikel, nimmt sich richtig viel Zeit und Schmalz und dann läuft das Ding nach zehn Artikeln unten durch und verschwindet im Archiv? Zu oft. Und auf so einer Seite 2 könnte man so ein Archiv aufbauen, sozusagen mit den Highlightartikeln, schön angeteasert oder auch einfach nur mit Überschrift versehen.

An so einer Seite 2, wie gesagt, zahne ich schon eine ganze Weile herum und habe auch schon an einer Programmlogik gemalt, bis mir eine Standardtugend bei solchen Fragestellungen eingefallen ist: Erst mal schauen, ob WordPress das nicht mit RSS-Bordmitteln kann. Und ja, WordPress kann. Denn WordPress kann nicht einfach nur den RSS-Feed der letzten zehn Artikel bereitstellen, sondern auch Feeds zu einzelnen Kategorien. Und zu einzelnen Schlagwörtern. Und – nun wird es spannend – auch Kombinationen von Kategorien und Schlagwörtern.

Nehmen wir an, wir haben in einem Weblog die Artikelkategorie „Technik“, die die interne Kategorie-ID 2 hat. Nun schreibe ich in dieser Kategorie beispielsweise zehn Artikel und zwei dieser Artikel finde ich so gut, dass ich sie gern auf die Seite 2 nehmen würde, sozusagen auf die „Besim’s Digest“. Die sehr einfache Vorgehensweise ist nun, diese zwei Artikel mit einem zusätzlichen WordPress-Tag zu versehen, beispielsweise mit „Highlight“.

Der nächste Schritt ist nun, auf der besagten Seite 2 eine Programmlogik zu integrieren, die einen RSS-Feed ausliest und parst. Und der lautet folgendermaßen:

http://blogname.de/feed/?tag=Highlight&cat=2

Dieser Aufruf des RSS-Feeds ruft demnach nur die Artikel auf, die mit dem Begriff „Highlight“ getaggt sind und in der Kategorie-ID 2 laufen. Fertig.

HTML-Tabellen in WordPress.

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.

WordCamp 2011 in Köln.

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.

WordPress MU.

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.

WordPress 3.1.

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.

WordPress 3.0.4.

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.

WordPress aus dem Maintenance-Mode holen.

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.

WordPress 3.0.1.

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.