Nach dem Aufsetzen des Servers kam mir die grundsätzliche Frage, welches CMS ich einsetze. Zur Auswahl standen schließlich WordPress – womit ich recht gut zurechtkam und Drupal – ein CMS, das nicht vorher nicht kannte.
WordPress
Pro:
- Ich kannte WordPress, die Bedienung ist relativ einfach, die Installation trivial und es ist recht komfortabel zu benutzen.
Contra:
- Irgendwie sehen alle WordPressinstallationen – egal, unter welchen Themes – gleich aus und den WP-Look hatte ich irgendwie satt
- WordPress ist recht unflexibel (was automatisch zum ersten Punkt führt) und
- WordPress hat in älteren Versionen eine Vorstrafenliste an – zum Teil massiven – Sicherheitslücken.
Drupal
Pro:
- Ein echtes CMS, das nicht aus einer Bloggingengine entstand
- Flexibilität
Contra:
- Einarbeitung in ein komplett unbekanntes CMS
- Für reine Blogs langsamer als WordPress und ggfls. Overkill
Ich habe mich dann doch für Drupal entschlossen, auch wenn ich kurz davor stand doch zu WordPress zu wechseln und ich habe die Entscheidung – trotz einiger Probleme – nicht bereut, die größte Stärke von Drupal im Vergleich zu WordPress ist Flexibilität. Nun einzelne Aspekte der Flexibilität:
1. Benutzer
Drupal ist u.a. für Online-Communities gedacht und dies ist auch in der Benutzerverwaltung ersichtlich. Es lassen sich Benutzerrechte sehr fein nach vorgefertigten Rollen (anonym, angemeldet und Administrator) granulieren – als Beispiel lässt sich leicht festlegen, dass angemeldete Benutzer kein Captcha benötigen oder Zugriff auf bestimmte Funktionen haben.
Interessanter ist jedoch die Definition eigener Rollen in Kombination des Taxonomy Access Control-Moduls: Es lassen sich hier Zugangsbeschränkungen anhand von Kategorien oder Tags (in Drupal ist das prinzipiell identisch, fällt beides unter dem Begriff „Taxonomie“ und unterscheidet sich nur im definierten „Vokabular“) definieren: Ein Benutzer der Rolle „Privat“ könnte so z.B. alle Inhalte – egal, ob Artikel, Mediengalerie oder Forum – in der Kategorie „Privat“ sehen, während ein anonymer oder normal angemeldeter Benutzer dies nicht kann – die Inhalte sind nicht nur unzugänglich, sie sind auch für diese Gruppen unsichtbar (inklusive der Auswahlkategorie per se). Alternativ ließe sich statt einer Kategorie ein Tag „Privat“ einführen (für das das gleiche gilt), oder eine dritte Klassifizierungsmöglichkeit (Kategorien, Tags und Zugangsklassen).
2. Inhalte
Drupal trennt scharf zwischen Inhalten und deren Darstellung (Themes), während bei WordPress die Inhalte oft auch vom Thema abhängen – speziell bei den Widgets und Modulen. Generell gibt es eigentlich keine Inhaltstypen per se, sondern jeder Inhaltstyp (Artikel, Buch, Umfrage, Galerie) ist eine Sammlung von einzelnen Feldern, die in der Datenbank gespeichert und beliebig kombiniert werden können und deren Darstellung/Ausgabe angepasst wird. Dazu demnächst ein Beispiel für das Anlegen eines neuen Inhaltstyp („Review“). Dies hat bei mir zuerst für Verwirrung gesorgt, als ich bei „Galerien“ nach einem Kategorie-Feld gesucht habe. Die Lösung war trivial: Einfach den Inhaltstyp durch das entsprechende Feld erweiteren, fertig – und schon wurde die Galerie in der entsprechenden Kategorie gefunden.
Exemplarisch soll der Unterschied zwischen Drupal und WordPress anhand des „Neuste Kommentare“-Block gezeigt werden: Der Block (und die dazugehörige Seite) sind schlicht und ergreifend Datenbankabfragen, die aufgearbeitet dargestellt und ohne großartige SQL-Kenntnisse leicht angepasst werden können:

Im Felder-Teil des Blocks werden die darzustellenden Inhalte eingestellt, während unter Filter die Selektion der Inhalte stattfindet. Das zweite Filterkriterium wurde von mir angepasst, so dass in dem Block nur Kommentare zu den Artikeln erscheinen, die mit der gewählten Sprache des Besuchers übereinstimmen.
Probleme
Neben der Einarbeitungszeit und dem Umdenken – Inhaltstypen sind nichts festes sondern eher eine Sammlung von Feldern – gibt es ein, zwei Dinge die nicht ganz zu gut gelöst sind:
- So hat es lange gedauert bis ich herausgefunden habe, wie sich Bilder (halb-)automatisch im WYSIWYG-Editor vergößern/verkleinern lassen, das gleiche galt auch für die Bilderunterschriften. Die Lösung hier waren Filter (dazu noch mal mehr in einem anderen Artikel), die aus den Texten dieBildgrößen und -unterschriften herausfiltern, die Bilder entsprechend skalieren und mit Beschreibung darstellen. Das geht in WordPress einfacher und eleganter.
- Manche Module sind noch recht buggy – das gilt für die von mir verwendete Version 7 besonders, da etliche Module für 7 nur Beta gekennzeichnet sind. So musste ich ab und an manuell Patche installieren.
Fazit
Trotz aller Schwierigkeiten und Widrigkeiten bin ich dennoch mit Drupal sehr zufrieden und bereue den Schritt und die Einarbeitungszeit nicht. Die Stärken und Schwächen von Drupal und WordPress aus meiner Sicht:
- WordPress ist ideal für Blogs mit wenig anderen Inhalt. Es ist für die Aufgabe schnell (vermutlich schneller als Drupal), sehr einfach installiert und läuft ohne großartige Anpassungen problemlos und ist somit ideal für Blogger ohne großartige technische Kentnisse. Dagegen ist es als allgemeines CMS eher mäßig – sobald es etwas außerhalb des Schemas „Website für Blogs“ werden soll wird es schnell schwierig und die Anpassung vermutlich wesentlich aufwändiger als in einem echtem CMS.
- Drupal ist ein Allround-CMS wie Typo3 oder Joomla. Es fordert erheblich mehr technischen Sachverstand und hat eine deutlich steilere Lernkurve (die jedoch erheblich geringer als die von Typo3 ist) als WordPress. Es besticht jedoch durch enorme Flexibilität und Eleganz, sobald die notwendige Einarbeitungszeit gemeistert wurde. Manche Module für Version 7 haben noch Bugs.
Wer nur ein Blog betreiben möchte, der ist vermutlich bei WordPress besser aufgehoben. Wer jedoch – wie ich – Flexibilität und die enormen Möglichkeiten eines echten CMS schätzt, sollte die Zeit in die Einarbeitung investieren – sie ist es wert.
comments title