Die CMS-Landschaft im Jahr 2014

Dreimal habe ich hier im Blog bereits verschiedene Content-Management-Systeme verglichen und Empfehlungen ausgesprochen:

Höchste Zeit für ein Update, denn es verändert sich ja so vieles! Nach wie vor sind bei den meisten Kundenprojekten entsprechende Systeme angesagt, auch wenn wir inzwischen ein wenig restriktiver mit der Frage umgehen, ob und wieviel Pflege seitens des Kunden tatsächlich zu erwarten sind.

Fangen wir zunächst mit den CMSen an, die wir derzeit aktuell in Betracht ziehen bzw. aktiv anbieten:

ProcessWire

Unser aktueller persönlicher Liebling, der sich bei einer Handvoll Projekte auch schon bewährt hat. Ein schlankes und von Altlasten größtenteils unbelastetes CMS, welches die besten Konzepte aus vorhandenen Systemen klaut und zu einem großartigen Gesamtpaket schnürt. Die Inhaltstypen sind von Haus aus komplett leer – bis auf einen pflichtmäßigen Titel und URL-Titel – und müssen vom Entwickler von Null aufgebaut werden. ProcessWire macht nichts von sich aus, aber macht es dem Entwickler gleichzeitig sehr einfach, die Strukturen Schritt für Schritt aufzubauen. So entsteht kein Overhead – man bekommt jedoch auch nichts geschenkt.

Bei ProcessWire gibt es keine nennenswerten, fertigen Frontend-Themes. Warum auch? Im Regelfall hat jede gut gemachte Website ganz individuelle Inhaltstypen und Felder, denen man mit einem Standardtheme gar nicht gerecht werden kann. Aber auch hier gilt: Dem Entwickler wird es sehr leicht gemacht, die individuellen Themes schnell und pragmatisch aufzubauen. Gecodet wird direkt in PHP in den Template-Dateien, mit einer sehr einfachen API, die im Wesentlichen aus dem Objekt $pages besteht, und dann in jQuery-ähnlicher Manier für die Ausgabe einzelner Feldwerte, sowie für foreach-Loops mit Filtern usw. genutzt wird.

Das Backend ist mit der Version 2.4 nochmal deutlich schicker geworden und führt den Redakteur durch visuell schlanke, aber potenziell sehr mächtige Eingabemasken. Eben genauso simpel oder komplex, wie es die jeweilige Website verlangt.

Kirby

Besonders viel haben wir mit Kirby noch nicht gemacht, aber das kommt noch – zumal in einigen Tagen Version 2 erscheinen wird. Kirby ist – von der Denkweise her – eine datenbanklose Version von ProcessWire, besitzt eine sehr ähnliche Template-API und macht prinzipiell alles, was man für die meisten Websites benötigt.

Inwiefern das System sich für umfangreiche, komplexe, mehrsprachige und laiensichere Websites eignet, vermag ich noch nicht zu sagen. Aber für technisch interessierte Kunden, die gerne auch mal elegante Wege einschlagen, sollte man sich das überlegen. Keine Datenbank! Das bedeutet: Deployment und Migration in wenigen Sekunden und ohne Stress. Oder sogar: Continuous Integration von Struktur und Inhalt über Git oder Dropbox (oder andere Syncing-Dienste)!

Dass Kirby auch über ein normales Admin-Interface mit Browser-Login verfügt, wird da fast zur Nebensache. Allerdings ist hier natürlich der Knackpunkt für die Arbeit mit »normalen« Kunden. Es muss sich zeigen, wie realitätsnah das Backend von Kirby 2 ist, um auch für den Schreinermeister von nebenan eine sinnvolle CMS-Alternative darzustellen.

WordPress

Auch wenn wir insgesamt keine ausgewiesenen Freunde von WordPress (mehr) sind, so kommt man natürlich nicht drum herum. Kein System ist so schnell von 0 auf 100% aufgesetzt, nirgendwo findet man eine größere Vielfalt an Plugins für jeglichen Anwendungsfall.

WordPress ist die eierlegende Wollmilchsau und gleichzeitig ein historisch gewachsenes Ungetüm, welches immer noch den Geist eines Blogsystems atmet, das jedoch über viele voneinander unabhängige Krebsgeschwüre zu einem vollwertigen CMS mutiert ist, dabei niemals den klaren Schnitt eines Reboots gewagt hat, obwohl er dringend nötig wäre. Der Fluch des Erfolgs: Ständig neue Sicherheitslücken, eine völlig chaotische API mit unterschiedlichen Naming-Conventions, 20 verschiedenen Plugins für grundlegende CMS-Funktionen wie Content-Fields, und ein riesiger Markt an fertigen Amateurthemes, die dann mit großer Mühe an die eigenen Bedürfnisse angepasst werden können – oder auch nicht.

Wir haben uns darauf verständigt, dass wir nur noch dann WordPress einsetzen, wenn

  • wir das Theme komplett selber machen können, oder ein fertiges Theme ohne Anpassungen einsetzen können.
  • die Website tatsächlich blogähnlich oder zumindest newslastig ist.
  • es ein expliziter und gut begründeter Kundenwunsch ist.

Das Problem ist nicht nur rein technisch, sondern auch kulturell zu verstehen: WordPress animiert den Seitenbetreiber, selbstständig auf Knopfdruck Plugins und Themes installieren zu können, was dieser in vielen Fällen auch gerne in Anspruch nimmt. Dass aber viele Plugins nicht mit anderen Plugins, und andere Plugins nicht mit allen Themes zusammenarbeiten, kann der Laie vorher nicht ahnen. WordPress verspricht, das ultimative Baukasten-CMS zu sein, nur dass in der Realität häufig Duplo, Lego und Playmobil kombiniert werden sollen.

Dennoch gibt es natürlich positive Aspekte: Der WYSIWYG-Editor ist einer der am besten integrierten, die Medienverwaltung ist vorbildlich und sehr, sehr nutzerfreundlich. Mehrsprachigkeit über das WPML-Plugin rockt – auch wenn WPML inzwischen fast genauso komplex ist wie WordPress selber. Und natürlich die allgemeine Bekanntheit und Beliebtheit des Systems. Wir kamen noch nie in argumentative Schwierigkeiten, wenn wir WordPress empfohlen habe.

Drupal

Wenn es groß sein soll, die Website und das Budget, kommt oftmals Drupal ins Spiel. Das CMS scheut sich nicht, alle paar Jahre inkompatible Major-Versionen zu veröffentlichen und damit alte Zöpfe abszuschneiden. Derzeit ist Version 7 aktuell, doch viele Websites arbeiten noch erfolgreich mit Drupal 6. Nummer 8 steht schon in den Startlöchern – und die Migration zwischen den Systemen kann extrem hakelig sein, da sämtliche Plugins/Module umgeschrieben werden müssen.

Ansonsten habe ich in Drupal immer noch am meisten Vertrauen, was Stabilität und Flexibilität angeht. Es ist zwar immer kompliziert, aber letztlich kann man mit Drupal jede Art von großen Brötchen backen. Als Richtwert setze ich gerne die magische 10.000-Euro-Grenze an. Erst ab diesem Budget für die gesamte Website lohnt es sich, die große Keule namens Drupal auszupacken. Falls das jedoch möglich ist, kann man tolle Dinge anstellen, denn Drupal kommt spielend leicht mit großen Datenmengen zurecht: Viele tausend Einzelinhalte, die in beliebiger Struktur in Form von Seiten, Tabellen oder anderen Auflistungen frei platziert werden können, quer über die Website verteilt und mit hunderten von Benutzern (falls gewünscht). Angeschlossene Foren, multiple User-Blogs, externe Datenströme, Redaktionsworkflows, Mehrsprachigkeit, Baukastenlayouts… Drupal kann alles! Aber es ist oftmals umständlich, es sauber und mit schlankem HTML-Code einzurichten. Wenn die Kiste jedoch einmal läuft, gibt es verhältnismäßig wenig Schwierigkeiten. Bis zum ersten Major-Uprade.

Es gibt jedoch eine Reihe von Systemen, zu denen wir inzwischen nicht mehr raten würden, obwohl wir früher viel und gerne mit ihnen gearbeitet haben:

Viel wurde versprochen, kaum etwas wurde gehalten. Die monströse Basis-Installation mit vielen tausend Einzeldateien, das superträge ExtJS-Backend, die völlig verkopfte und kaputte Rechteverwaltung, die überdimensionierte Package-Verwaltung, das umständliche Bearbeiten von Inhalten. MODX Revo ist aus meiner Sicht ein Fehlschlag: überkomplex, theoriegetrieben und praxisfern. Alle Kritikpunkte aus dem Jahr 2011 sind immer noch gültig – es hat sich kaum etwas getan.

Grundsätzlich immer noch ein feines CMS, welches es verdient hätte, dass man ernsthaft weiter daran arbeitet – inzwischen gibt es ja nur noch winzige, kosmetische Updates. Man könnte ProcessWire als den legitimen Nachfolger von MODX bezeichnen. Interessanterweise habe ich bei meinen noch aktiven Evo-Kundenwebsites insgesamt weniger Bauchschmerzen als bei den Revo-Kundenwebsites. Neue Projekte würde ich allerdings trotzdem nicht damit anfangen – zu wenig aktuelle Weiterentwicklung ist hier zu erwarten.

Alles hat seine Zeit. Textpattern ist immer noch ein okayes Blogsystem für Liebhaber, und für die eine oder andere kleinere Website verrichtet es seinen Dienst. Aber der Zahn der Zeit macht nicht halt, und Textpattern hat sich seit Jahren nicht mehr weiterentwickelt. Ruhe in Frieden!

Bleibt noch die lange Liste von Systemen, die wir nicht so genau kennen, zu denen ich deswegen erstmal kein negatives Urteil fällen möchte. Einige von den genannten Systemen sind aber nicht ganz ohne Grund hier unten gelandet – bei anderen mag das anders sein :-)