Weil beispielsweise über Drupalcenter.de eine ganze Menge Um- und Einsteiger auf meinen Artikel von Ende 2005 stoßen, möchte ich hier einige Punkte deutlicher machen und auf den aktuellen Stand bringen.

Grundsätzliches

(1) Meine Beobachtungen aus dem Jahr 2005 gelten grundsätzlich auch noch für die aktuelle Drupal-Version 5.1.

(2) Die Beobachtungen gehen von einem ganz bestimmten Anwendungsszenario aus, nämlich einer mittelgroßen Website (> 10.000 und <100.000 Nodes/Seiten/Artikel) mit hierarchischer Inhaltsstrukturierung, Anmerkungen auf der Artikelseite und Option auf ein 'echtes' Forum sowie andere Funktionen, für die wir einen möglichst flexiblen "Unterbau" brauchen. Für andere Einsatzgebiete können vollkommen andere Anforderungen gelten. Nicht jeder möchte beispielsweise Bilder auf seiner Website haben, verschiedene Autoren schreiben lassen oder Inhalte hierarchisch strukturieren (modisch sind momentan ja ganz andere Ansätze wie Tag-Wolken).

(3) M.E. ist Drupal kein Content Management System (CMS), ebensowenig wie die damals verglichenen Systeme MediaWiki oder FrontPage, sondern in erster Linie ein Framework zur Entwicklung eigener Anwendungen.

Es gibt durchaus Einsatzgebiete, für die man Drupal "out of the box" verwenden kann, im Regelfall wird man bei halbwegs gehobenen Ansprüchen jedoch (a) auf 3rd-Party-Module zurückgreifen, (b) selbst Module schreiben, (c) den Code von Drupal- und 3rd-Party-Modulen anpassen (oder reparieren) und (d) eigene Themes ("Motive") gestalten.

Da Drupal saubere Open Source Software ist, kann man das alles machen - aber eben nur, wenn man es kann. Ich habe beispielsweise versucht, einige notorisch defekte 3rd-Party-Module zu 'reparieren' und bin daran als Nicht-Informatiker gescheitert. Auch das Kreieren von ansprechenden und funktionalen Themes für Drupal ist eine Aufgabe, die _extrem_ viel Zeit erfordert.

(4) Drupal ist m.E. eine "eierlegende Wollmilchsau", die alles und nichts kann, sprich: die für sehr viele Anwendungsszenarien angepasst werden kann, jedoch in keinem Bereich besonders spezialisiert ist. Wer weiß, dass er vor allem bloggen möchte, sollte sich beispielsweise erstmal so etwas wie WordPress anschauen.

(5) Der Core von Drupal ist m.E. so grundsolide, wie Open Source Software nur sein kann. Allerdings kann man mit der Funktionalität des Core möglicherweise nur wenig anfangen, das hängt aber natürlich wieder vom Anwendungsszenario ab.

In unserem konkreten Fall - dieser Website - kommt ein signifikanter Teil der "mission critical"-Funktionalität aus 3rd-Party-Modulen, und deren Qualität reicht von "grandios" über "so-la-la" bis hin zu "unbrauchbar". Außerdem schwankt die Qualität vieler Module zwischen den einzelnen Releases des Core, man kann also beispielsweise plötzlich Ärger mit einem Modul unter Drupal 5.1 bekommen, das man in der ganzen 4er-Generation problemlos verwenden konnte. Darüber hinaus interagieren viele Module miteinander, so dass es häufig zu unerwarteten Wechselwirkungen kommt; aufgrund der enormen Vielzahl von Modulen stehen die Chancen nicht schlecht, dass man der einzige Mensch auf dieser Erde ist, der genau diese Kombination einsetzt, es kann also schwierig sein, Unterstützung zu finden.

Wegen des hohen Stellenwerts der Module für "real life"-Drupal-Installationen Muß man daher m.E. auch die eingesetzten Module berücksichtigen, was aber dem Framework Drupal gegenüber eigentlich ungerecht ist - es handelt sich eben um angeflaschte Funktionen und nicht um Drupal selbst.

Zwischenfazit

Nach diesen Vorbemerkungen kann ich, hoffentlich ohne allzu viele Mißverständnisse, ein erstes Zwischenfazit ziehen.

• Drupal läuft bei uns seit gut anderthalb Jahren, und das ohne Katastrophen oder Totalausfälle.
• Wir haben irgendwas im Bereich von rund 14.000 Nodes, die Drupal recht souverän verdaut.
• Der Testbetrieb war ursprünglich auf ein Jahr angesetzt, wir mußten ihn jedoch immer wieder verlängern und haben mittlerweile eine konkrete Roadmap aufgegeben.
• Wir haben nicht vor, Drupal aufzugeben; wir sehen aber auch keinerlei echte Alternativen.

Was es an konkreten Problemen gab und gibt, haben wir ja bereits an anderer Stelle mehr oder minder ausführlich dokumentiert; dabei handelt es sich überwiegend um Annoyances, die praktisch ausschließlich durch Module (Wechselwirkungen, Fehler, Einstellung der Entwicklung etc.) hervorgerufen werden. Wegen der hohen Bedeutung dieser Funktionen möchten wir die Website bis auf weiteres nicht aus dem Teststadium entlassen.

Unsere ursprünglichen Kritikpunkte konnten wir nicht wirklich beseitigen, wir können aber halbwegs damit leben. Das bedeutet nicht, dass Drupal in irgendeiner Weise "schlecht" wäre, sondern lediglich, dass es (a) für unsere konkreten Bedürfnisse "out of the box" nicht hinreichend maßgeschneidert ist und (b) wir bisher nicht in der Lage waren, die erforderlichen Anpassungen durch vorhandene oder selbst geschriebene Module zufriedenstellend "nachzurüsten". Das liegt weniger daran, dass wir zu faul dazu wären, sondern eher, dass wir uns eigentlich eher auf die Inhalte als auf die Technik der Website konzentrieren würden.

Drupal hat für uns durchaus einen gewissen unwiderstehlichen Charme, und es gibt - inbesondere im Core - eine Fülle von guten, konsequenten und sinnvollen Design-Entscheidungen. Letztlich ist aber das Bessere der Feind des Guten, und etwas besseres als Drupal gibt es - für unsere Zwecke - und nach unserem aktuellen Wissensstand nicht ;)

> Also ich finde Deinen Erfahrungsbericht sehr subjektiv

> und bin ganz anderer Meinung.

Das kannst gerne, ich freue mich jederzeit über eine inhaltliche Diskussion.

Aber natürlich ist der Bericht subjektiv, da er ja unsere tatsächlichen Erlebnisse im Live-Betrieb beschreibt und eben keine Pseudo-Objektivität unter hypothetischen Laborbedingungen anstrebt. Deshalb nennen wir derartige Artikel ja ganz bewusst _Erfahrungsbericht_ und nicht _Testbericht_ o.ä.

> Findest Du das es wirklich schwierig ist oder extrem viel Zeit erfordert

> ein Drupal-Theme zu erstellen?

Ja, sonst würde ich das nicht schreiben und auch kein fremdes Theme aus dem CVS verwenden. Als Indiz dafür, dass es auch anderen Drupal-Interessenten ähnlich geht, würde ich den dramatischen Mangel an hochwertigen und originären Drupal-Themes (egal ob quelloffen oder kommerziell) anführen, insbesondere im direkten Vergleich mit Konkurrenten à la WordPress.

Ich möchte hier allerdings nicht darüber spekulieren, ob das Problem an Drupal selbst oder an der (m.E. zu schwer zu findenden und zu knappen) Dokumentation der Template-Engines liegt (ich vermute letzteres).

> Hast Du das mal mit vergleichbaren CMS wie z.B. Joomla oder Typo3 gemacht?

Ja, ich habe schon Templates für Websites entwickelt, sowohl privat als auch beruflich (ich habe seit 1994 mit Webdesign zu tun). U.a. habe ich Templates für Bricolage mit HTML::Template und Mason gemacht, und ich würde einfach mal behaupten, dass das ein etwas anderes Kaliber ist als Drupal ;) Auch ein paar andere Teammitglieder haben schon für "echte" CMS wie NPS oder Hyperwave entwickelt.

Und nein, ich habe mich bisher noch nicht so detailliert mit Joomla oder Typo3 auseinandersetzen müssen.

> Weiterhin finde ich, man sollte Drupal nicht mit Frontpage vergleichen

> sollte. Hast Du schon mal mit Frontpage eine Webseite in entsprechender

> Größenordnung (> 10.000) betreut oder besser noch mit verschiedenen

> Redakteuren daran gearbeitet?

Gerade deshalb haben wir ja die drei Systeme (Drupal - Frontpage - Mediawiki) verglichen, wobei die datenbankbasierten Online-Systeme natürlich einen leichten 'Bonus' bekommen, weil sie kein Staging können oder wollen, also prinzipbedingt wesentlich höhere Hardwareanforderungen stellen müssen als ein Offline-Publisher wie FrontPage (oder auch das datenbankbasierte Bricolage, das aber Staging kann). Gerade durch den Vergleich dreier so unterschiedlicher Konzepte kommt man doch den Stärken und Schwächen der verschiedenen Systeme viel besser auf die Schliche...

Und ja, natürlich haben wir mit FrontPage schon große Projekte gemacht (in der Liga 100.000 bis 500.000 Seiten; ja, man muß da ein wenig tricksen, aber es geht und ist so stabil wie man sich nur wünschen kann; ja, wir arbeiten mit mehrern Autoren daran). Bei FP wissen wir definitiv, dass es in nahezu jeder Beziehung in Dimensionen skaliert, in denen mindestens 90 Prozent aller FLOSS-CMS komplett aussteigen. Wir haben viel Zeit mit der Evaluation verbracht und könnten da einige üble Geschichten erzählen...

Einer der Gründe, warum wir Drupal überhaupt zu evaluieren begonnen haben, war, dass wir einige FP-Projekte gerne migirieren möchten (hauptsächlich aus zwei Gründen, zum einen aus ideologischen Überlegungen heraus und zum anderen wegen der zunehmen kriminellen und auch rechtlich kritischen Spam-Problematik). Außerdem hängen einige andere Projekte in der Pipeline, die wir möglichst nicht mit FP angehen würden; Drupal ist dabei - im Gegensatz zu diversen anderen Systemen - zwar in die engere Wahl gekommen, allerdings ist aus verschiedenen Gründen bisher an eine Migration nicht zu denken; MediaWiki wäre aus verschiedenen Gründen wahrscheinlich besser geeignet, bietet aber im Vergleich zu dem, was wir sowieso mit FP machen können, zu wenig echte Vorteile (hast Du schon mal in einem großen Wiki <> Wikipedia administriert? Wie viel Zeit ist da beim händischen Spamputzen draufgegangen?).

Doch zurück zum Vergleich Drupal vs. FrontPage... Das (zumindest für uns) interessante daran war, dass FP

• beim Erstellen, beim Strukturieren und beim Verwalten von Daten trotz aller bei diesen Datenmengen erforderlichen Trickersereien schneller, übersichtlicher und komfortabler ist, während Drupal bereits bei unseren läppischen >10.000 Nodes quasi unverwaltbar geworden ist (ich liefere gerne Beispiele, falls es jemanden interessiert);

• trotz der um Größenordnungen umfangreicheren und komplexeren Websites mit relativ hoher Last nur einen Bruchteil der Ressourcen einer knapp mittelgroßen Drupal-Installation nahezu ohne Last verbraucht.

Unsere FP-Projekte konnten bis vor kurzem sogar noch auf einem Shared Host laufen lassen, während die hier laufende Drupal-Installation einen (kleinen) dedizierten Server ("Strato High End Server SR") mehr als auslastet. Wir können hier beispielsweise weder das G2- noch das Spam-Modul laufen lassen, weil wir sonst Ladezeiten von >20 Sekunden pro Seite bekommen. Der Minimaltraffic, den kefk.org verursacht (etwa 500 Besucher pro Tag, also nahezu Null) lastet den Server nahezu vollständig aus (CPU Load kontinuierlich zwischen 20 und über 90 Prozent), während die meisten FP-Sites ganz gut unter Last stehen (zu Spitzenzeiten ein paar hundert Besucher pro Minute) und dabei eine gesamte CPU-Last von 2 bis 5 Prozent verursachen. Übrigens sind auch alle unsere größeren FP-Projekte teilweise dynamisch (ASP-Skripte plus Datenbanken).

Die Vorteile von Drupal (mehr oder minder "out of the box") beginnen da, wo man bei FP beginnen muß, richtig Aufwand zu betreiben: Foren (vor allem spamfreie Foren), dynamisch rekombinierte Inhalte, flexible (Echtzeit-) Volltextsuche und vor allem Interaktion mit Benutzern. Bei FP muß man hier alles selbst skripten (die Bots für "Gästebuch" und Volltextsuche sind indiskutabel), während Drupal genau hierfür sein Framework anbietet. Verkürzt gesagt: Drupal hat genau dort Schwächen, wor FP seine Stärken hat, und umgekehrt.

Richtig spannend wird es, wenn man dann noch MediaWiki in die Gleichung mit einbezieht. Das ist ja auch datenbank-basiert, aber bewiesenermaßen hoch skalierbar; die Verteilung von Stärken und Schwächen ist nicht mehr so einfach wie zwischen FP und Drupal. Unter anderem bemerkenswert ist jedoch, dass MediaWiki bei den Hardwareanforderungen signifikant genügsamer ist als Drupal (in einer Grundinstallation ohne Dutzende von Modulen). Andererseits traten die wirklich krassen Performance-Einbrüche bei Drupal (Ladezeiten einer Seite ohne jegliche sonstige Systemlast 20-40 Sekunden!) immer nur durch amoklaufende Module wie Pathauto (momentan gücklicherweise wieder stabil) auf.

Wir bekommen mit Drupal also Features, die einen hohen "Preis" fordern (in Bezug auf Hardwareanforderungen und Verwaltbarkeit und Erschließung des Content etc.); allerdings sind das Features, die wir unter vergleichbaren Systemen nicht mit vertretbarem Aufwand bekämen (z.B. Annotationen zu einer Seite mit effektiver Spamfilterung). Der "Preis" für eine derartige Drupal-Site ist nun aber wieder doppelt so hoch, weil auch hier mittlerweile Trackbacks, Kommentare oder Foren nur noch schwerstbewaffnet möglich sind, sprich: Wir müssten eine ganze Armada von Schutzfiltern laufen lassen, wofür wir wer weiß was für Hardware benötigen würden (da es zumindest bis gestern sowieso noch kein Trackback-Modul für Drupal 5.1 gibt, müssen wir uns darüber momentan noch nicht den Kopf zerbrechen ;-)

MfG -asb