Seit über sechs Jahren erstellen wir bei webtotum nun Webseiten mit Joomla, Drupal oder Wordpress. Aber welches dieser CMSe ist das optimale? Klare Antwort: "Es kommt darauf an."

Jedes der drei Systeme hat spezifische Stärken und Schwächen, die es für einen bestimmten Zweck als die beste (oder auch schlechteste) Wahl empfehlen. Aber was sind nun die Kriterien, nach denen wir ein CMS für einen bestimmten Kunden auswählen? Insbesondere diese Faktoren spielen eine entscheidende Rolle:

• Kann ich eine einfache Bedienbarkeit für den Kunden erreichen ?
• Wie leicht lässt sich die gewünschte Funktionalität mit dem CMS realisieren? In der Regel gilt: einfacher = preiswerter.
• Welche Größe ist für die Webseite geplant, d.h. wie komplex wird sie und wieviele Besucher werden erwartet?
• Wie steht es um die Sicherheit? Eine Webseite, auf der sich Besucher selbst registriern können, stellt andere Anforderung als eine Seite, die nur durch einen kleinen Kreis von Personen betreut und inhaltlich gefüllt wird.

Das sind die Faktoren, die zunächst einmal besonders wichtig sind. Aber dann gibt es noch Dinge zu bedenken, die für die Zukunftssicherheit der Webseite entscheidend sind:

• Wie steht es um die Weiterentwicklung des CMS und seiner Drittanbieter-Komponenten?
• Welche Lizenzen werden eingesetzt?
• Wie einfach ist ein Update auf neue Versionen?
• Wie wird die Qualität des Programmcodes gewährleistet?

Im Folgenden wollen wir versuchen, diese Fragen zu beantworten. Natürlich ist unsere Einschätzung zum Teil subjektiv, denn manches - wie z.B. die Bedienbarkeit einer Webseite - ist auch Geschmackssache.

Was möchte ich mit meiner Webseite machen?

Fangen wir damit an, was die Webseite eigentlich alles können soll. Danach kann man schon mal grob sagen welches CMS zum Einsatz kommen wird. Grundsätzlich kann man mit Drupal praktisch jedes Projekt realisieren, von der kleinsten Seite bis zum größten Firmenauftritt oder Portal. Allerdings ist der Aufwand für die Installation und Einrichtung im Schnitt höher, als für eine Wordpress- oder Joomla-Seite. Will man nur eine kleine Webseite mit vielleicht 10 statischen Seiten und einer Seite mit aktuellen News, so ist Wordpress in der Regel die beste Wahl. Seine Stärke liegen eindeutig im Bereitstellen eines Weblogs und hier läßt es Drupal und Joomla weit hinter sich. Einzelne Seiten in ein Menü einbinden sind mittlerweile auch keine große Schwierigkeit mehr und für Suchmaschinenoptimierung (SEO) gibt es nicht nur von Haus aus Nützliches, sondern auch eine gute Auswahl an Plugins. Außerdem lässt sich Wordpress relativ leicht sehr benutzerfreundlich einrichten. Auch eine Joomla-Seite ist schnell aufgesetzt und prinzipiell für kleine und größere Webseiten geeignet. Die vergleichsweise starre Strukturierung der Inhalte mit Kategorien (bzw. früher mit Sektionen und Kategorien) ist hier wesentlich unhandlicher. Bei Drupal gibt es praktisch alle Freiheitsgrade, um Inhalte zu strukturieren - diese Freiheit erfordert allerdings vorab eine sorgfältige Planung.

Wer suchet der findet – CMS-Erweiterungen

Es kommt eigentlich nur selten vor, dass wir eine Webseite ausschließlich mit den Funktionen realisieren, die der CMS-Core (d.h. das Basissystem) bereitstellt. Funktionale Erweiterungen sind die Regel. Sei es ein Modul zu Vermeidung von Kommentar-Spam, ein Newsletter oder ein Kontaktformular. Entscheidend für die erfolgreiche Suche ist dann, dass die Projektseite des CMS derartige Erweiterungen übersichtlich anbietet.

Gut gelöst ist dies bei Drupal. Unter Download & Extend findet man das eigentliche Drupal, Module (für die funktionale Erweiterung) und Themes (für das Layout). Bei den Modulen stehen zur Zeit (September 2012) 11.094 zur Verfügung. Die Suche kann nach Stichworten, Kategorien, Drupal-Version oder fertigen Projekten (im Unterschied zu Sandbox-Versionen) erfolgen. Zusätzlich kann man die Ergebnisse nach Relevanz, Veröffentlichungs- oder Aktualisierungsdatum, Häufigkeit der Installation und anderen Kriterien sortieren lassen. Auf den Detailseiten der einzelnen Suchergebnisse bekommt man direkt die verschiedenen Versionen zum Download aus dem zentralen Repository angeboten. Insgesamt ist das sehr gut gelöst.

Anders sieht die Sache bei Joomla aus. Die zur Zeit gelisteten 9.991 Extensions sind lediglich in Kategorien unterteilt. Die Suchfunktion bietet erst in der „Advanced Search“ mehr als nur die Suche nach Stichworten. Immerhin kann man dort auch nach Version und Lizenztypen suchen. Manchmal ganz hilfreich sind die Bewertungen und Kommentare aus der Community, um die Qualität einer Extension zu beurteilen. Hat man endlich gefunden, was man sucht, so gibt es zwar bei den Suchergebnissen jeweils einen „Download“-Button, der führt dann aber nur auf die Seite, wo die jeweilige Extension gehostet wird. Dort muss man sich dann unter Umständen extra registrieren, um endlich den Download zu erhalten. Es ist auch keineswegs immer gewährleistet, dass die Seite überhaupt noch existiert. Da ist die zentrale Repository-Lösung von Drupal eindeutig die bessere Lösung.

Nicht besser ist das bei Wordpress. Hier gibt es noch nicht einmal eine Filtermöglichkeit nach Version und die Suche nach Relevanz liefert auch nicht die besten Suchergebnisse. Hilfreich ist auch hier die Bewertungsfunktion durch die Community. Auf der Detailseite der Extensions gibt es dann noch einen Compatibilty-Check, der ebenfalls von der Community gefüttert wird, so kann man oft vor der Installation klären, ob die Extension überhaupt mit der verwendeten Wordpress-Seite zusammenarbeitet. Immerhin sind die meisten Plugins (aber nicht alle) im zentralen Repository.

Lizenzen und Versionen

Die Lizenzfrage ist bei Drupal eindeutig geregelt. Es gibt für den Drupal Core und die Drittanbieter-Module ausschließlich lizenfreie GNU/GPL-Lizenzen. Bei den Themes ist dies zum Teil anders, so dass hier zumindest einmalige Kosten entstehen können. Die Versionierung von Drupal und den Drupal-Modulen folgt einem klaren Schema. Es gibt die Hauptversionsnummer (zur Zeit ist Drupal 7 aktuell, Drupal 6 wird noch unterstützt, Drupal 8 ist in der Entwicklung) und diese Versionsnummer findet sich in allen Versionsnummern der Module wieder. Module im Entwicklungsstadium sind explizit als solche gekennzeichnt. Hier am Beispiel des wohl meistgenutzte Moduls „Views“:
Empfohlene Releases sind 7.x-3.5 (7.x ist das Kennzeichen für Drupal 7, 3.5 ist die Version von Views) und 6.x-2.16 (für Drupal 6, die 2.16 zeigt, dass es aktuell keine stabile Views3-Version für Drupal 6 gibt). Zusätzlich gibt es die aktuellen Development-Versionen 7.x-3.x-dev und 6.x-3.x-dev, sowie unter „other releases“ ein 6.x-3.0 (also doch ein stabiles Views3, aber es erfordert ein Upgrade von 2.x). In der Regel kann man die kleineren Versionssprünge (also z.B. von 2.15 auf 2.16) problemlos upgraden, während Umstellungen auf neue Hauptversionen (in unserem Beispiel von 2.15 auf 3.5) unter Umständen zusätzliche Migrationsschritte erfordern. Insgesamt ist das recht übersichtlich und in der Praxis gibt es vergleichsweise wenig Probleme bei Updates und Upgrades.

Mit am einfachsten sind Updates bei Wordpress. Diese erfolgen direkt aus dem Backend heraus, ohne dass man per FTP auf seine Seite zugreifen muss. Bei Drupal kann man seit Version 7 immerhin die Module auf diese Art aktualisieren, das Core-Sytem erfordert dagegen nach wie vor einen FTP- oder Shell-Zugang. Das gleich gilt für Joomla.

Ein ziemlicher Versionswildwuchs existiert leider bei Joomla. Die Logik hinter den Versionsnummern ist nicht einfach erkennbar. So gibt es die Versionen 1.0, 1.5, 1.6, 1.7 und aktuell 2.5 mit unterschiedlichen Supportzeiten. Wer glaubt, dass Joomla 1.6 und 1.7 länger unterstützt würden als Joomla 1.5, der irrt. 1.5 ist ein sogenanntes "Long-term-support-Release" und wurde bis April 2012 unterstützt. Die später erschienen Versionen 1.6 und 1.7 waren dagegen nur "Short-term-support-Releases," die bis August 2011 bzw. Februar 2012 unterstützt wurden. Die Erweiterungen von Drittanbietern haben beliebige eigene Versionsnummern. Eine klare Struktur fehlt, was die Übersicht erschwert.

Schlimmer noch als dieses Versions-Chaos ist das Durcheinander bei den Lizenzen. Obwohl der Joomla-Core unter unter GNU/GPL steht ist es Drittanbietern gestattet, andere Lizenzen zu verwenden, auch kommerzielle, die es ermöglichen Geld für die Extensions zu verlangen. Da keine Extension ohne das freie Joomla irgendeinen Wert hätte, sollte so etwas nicht gestattet sein! Häufig ist man sogar gezwungen, die Katz im Sack zu kaufen, weil es keine Möglichkeit gibt, die Extension zunächst einmal zu testen. So wird das Erweitern einer Joomla-Installation zur Lotterie.

Wenn ich für Erweiterungen zahle, ist dann die Qualität wenigstens besser?

Aus unserer Erfahrung heraus muss man das leider verneinen. Insgesamt mussten wir immer wieder feststellen, dass Joomla-Extensions, die als „stable“, also stabil, bezeichnet wurden, bei Drupal bestenfalls als Alpha-Version durchgegangen wären (die früheste Phase der Entwicklung von Software) und zwar mit dem Hinweis, dass sie für den Produktiveinsatz noch nicht geeignet sind. Und dieser Mangel an Qualität betraf sehr oft auch Extensions für die man zahlen sollte. Ebenfalls nervig ist bei Joomla, dass nicht wenige Seiten, die eine Extension anbieten, zuvor eine Registrierung verlangen. Dass sich das Spam-Aufkommen auf der verwendeten Mailadresse hinterher signifikant erhöht, dürfte kaum Zufall sein. Die Folge der mangelhaften Qualitätskontrolle: schlecht kodierte Erweiterungen, die sehr häufig Nachbesserungen erfordern. Dass so mancher Autor seine Erweiterung zwar noch anbietet, dafür aber keinen Support mehr anbietet, führt immer wieder dazu, dass wir selbst Hand anlegen oder erneut auf die Suche nach einer brauchbaren Alternative gehen müssen.

Dieses Risiko kann man zwar bei Drupal nicht ausschließen, aber unsere Erfahrung hat gezeigt, dass der Qualitätsstandard bei den Erweiterungen für dieses System deutlich höher liegt. Ein Modul im Beta-Stadium konnten wir bei Drupal sehr oft ohne irgendwelche Nachbesserungen einsetzen. Und falls es doch mal Probleme gab, war die Community in der Regel schneller, kompetenter und hilfsbereiter als bei Joomla.

Ein häufiges Problem bei Wordpress entsteht, wenn man auf einer Seite zahlreiche verschiedeneErweiterungen einsetzt. Im Vergleich zu Drupal oder Joomla gibt es häufiger den Fall, dass bestimmte Plugins sich gegenseitig stören. Auch nach einem Update muss man deshalb immer damit rechnen, dass plötzlich irgendetwas nicht mehr so funktioniert, wie vorher. Das erhöht deutlich den Pflege- und Testaufwand. Bei Joomla und Drupal konnten wir dies dagegen nur sehr selten beobachten. Am ehesten gehen hier mal spezielle CSS-Codeteile verloren, die Modulspezifisch eingebaut wurden, oder es kam zu Problemen mit Komponenten, die AJAX verwenden.

Wie einfach ist ein Update auf neue Versionen?

Das Update auf neue Versionen innerhalb einer Hauptversion ist bei allen drei Systemen vergleichsweise einfach und gelingt problemlos. Anders sieht die Sache bei den Erweiterungen aus. Bei einem Upgrade von Joomla 1.0 auf 2.5 mussten wir beispielsweise fast alle Extensions (Bildergalerie, Newsletter) neu aufsetzen und die Daten mühsam von Hand migrieren. Bei Wordpress-Updates ist dagegen ausgiebiges Testen der Plugins erforderlich, um sicher zu gehen, dass die oben beschriebenen Kompatibilitäsprobleme zwischen den einzelnen Erweiterungen nicht auftreteten. Am einfachsten waren dagegen regelmäßig Updates bei Drupal. Die Core-Updates waren völlig unproblematisch und die Quote der Erweiterungen, die ersetzt werden mussten weil es keine Nachfolgeversionen gab, war die geringste.

Wie sicher ist meine Webseite?

Wenn die eigene Webseite gehackt wird ist das immer ärgerlich. Wichtig ist daher, dass das CMS möglichst sicher programmiert wurde und dass regelmäßig Sicherheitsupdates bereitgestellt werden.  Die größten Probleme bereiten auch hier in der Regel nicht die Core-Systeme selber, sondern die Erweiterungen.

Am problematischsten war in der Vergangenheit Joomla 1.0. Hier gab es wiederholt Kunden, deren Seite gehackt wurde, weil auf Sicherheitsupdates verzichtet worden war, aber auch, weil manche Erweiterungen extrem schlampig programmiert waren. Zum Teil ließen sich die Sicherheitslücken nur noch durch serverseitige Absicherung des Administrations-Backends schließen.

Auch bei Wordpress sind Hackerangriffe nicht selten. Praktisch ist hier z.B. die Erweiterung Wordpress Security Scan, mit der man schon vor dem Start einer Webseite ihren Sicherheitsstand testen und mithilfe von Anleitungen die Seitensicherheit erhöhen kann. Nicht ohne Grund gibt es zahlreiche andere Plugins zum Theme Sicherheit. Es empfiehlt sich, vor der Installation von Wordpress einen Blick auf den Artikel Wordpress installieren und sicherer machen von Vladimir Simović (Perun) zu studieren.

Am besten hat jedoch Drupal abgeschnitten. Hier hatten wir in all den Jahren keinen einzigen Fall, in dem eine Seite gehackt wurde.

Zum Thema Sicherheit gehört aber nicht nur, dass die Seite nicht gehackt werden kann, sondern auch die Vermeidung von unerwünschten Inhalten, wie z.B. Kommentar- oder Trackback-Spam. Hier ist unser Favorit eindeutig Wordpress in Verbindung mit dem Plugin Antispam-Bee. Während die Erkennungsquote von Spam bei rund 99 % liegt, kommt es praktisch nicht zu False Positives (das sind als Spam markierte Kommentare, die kein Spam sind). Drupal kommt mittlerweile beim Einsatz von Mollom auf ähnlich gute Werte. Bei Joomla-Seiten haben wir keine neueren Erfahrungen, weil wir mittlerweile vom Einsatz im Community-Bereich abraten.

Fazit

Wir von webtotum empfehlen für den Einsatz als Weblog oder auch für eine kleine Webseite mit einigen statischen Seiten und einem Newsbereich gerne das einfach zu bedienende und schnell installierte Wordpress. Vor allem, wenn keine größeren Erweiterungen der Funktionalität für die Zukunft geplant sind oder eine Community-Webseite entstehen soll. In solchen Fällen, oder wenn komplexe Seitenstrukturen, Newsletter, kleine Shops, die Anbindung eines Forums etc. geplant ist, setzen wir mittlerweile fast immer auf Drupal. Joomla ist aufgrund seiner kruden Versionspolitik, der z.T. sehr schlechten Code-Qualität bei den Erweiterungen und der für ein Open-Source-Projekt nicht akzeptablen Lizenzpolitik für uns nur noch in Ausnahmefällen das CMS der Wahl. Eigentlich nur dann, wenn der Kunde es bisher schon im Einsatz hatte oder bereits damit gearbeitet hat, und es uns nicht gelingt, ihn von der Überlegenheit von Wordpress oder Drupal zu überzeugen. ;-)