„In der Theorie ist Drupal ein Content Management System, mit dem man Webseiten out of the box erstellen kann - in der Praxis erweist sich die Konfiguration und Wartung als ein einziger Alptraum!“ So beginnt ein Blog-Artikel der Ruby on Rails-Entwicklerin Mariya Lysenkova, dessen Titel die Richtung eindeutig vorgibt: Drupal Sucks. Zwar sei Drupal für kleine Webseiten durchaus zu gebrauchen, doch sobald spezielle Features hinzukommen sollen oder die Seite hohe Zugriffszahlen verdauen muss, ist Drupal ihrer Meinung nach nicht die beste Wahl.
Für Lysenkova spielt es auch keine Rolle, dass viele Macken von Drupal mit einem Zusatz-Modul oder einem kleinen Hack behoben werden könnten. Für einen Coder wäre es schlicht einfacher, in ein bis zwei Tagen selbst ein Rails-CMS zu entwickeln. Die größten Probleme sieht sie in der extensiven Nutzung der Datenbank, in der schweren Erlernbarkeit des Systems und im Design.
Stellt sich natürlich die Frage: Stimmen die Kritikpunkte von Mariya Lysenkova? In den Kommentaren dort gibt es bereits eine lebhafte Diskussion. Habt Ihr Erfahrungen mit dem CMS und könnt die Punkte bestätigen oder widerlegen?
RSS-Feed
Twitter
jeder entwickler hat seine persönlichen favoriten, wenn jemand, der mit rails arbeitet mit drupal nicht so gern arbeitet, dann ist das ziemlich einleuchtend.
nichts destro trotz hat drupal genau das selbe problem wie typo3 und andere grosse cms systeme, dass es dermassen überladen wird, sobald man versucht es in der praxis einzusetzen, dass die sache schon mal sehr schnell sehr langsahm wird.
in vielerlei hinsicht zahlt es sich eventuell aus, die augen gegenüber anderen systemen und methoden zu öffnen, und eventuell auch mal patches und bugfixes bei zu steuern, dass die heutigen cms systeme noch lange nicht das ende der fahnenstange dar stellen, sollte hierbei klar sein.
Das alte missverstandene Thema der Trademark Policy hat sie auch aufgegriffen und schlecht recherchiert.
Schlecht recherchiert hat sie auch in anderen Bereichen. Drupal speichert Templates nicht in der Datenbank. Auch das Zusatzmodul Views speichert seine Templates im Dateisystem und nicht, wie sie sagt, in der Datenbank.
Anregungen von Leuten aus anderen Bereichen sind bei Drupal gern gesehen, ich würde mir aber wünschen, dass sie nicht so unfreundlich verfasst werden.
Anja
Etwas mehr akzeptanz könnte uns allen nicht schaden;)
generell: vielleicht ist ja sogar rails der neue heilige gral, aber wie auch immer, anstatt dass man sich über drupal und dessen schwächen auslässt, sollte man gerade als entwickler zeigen, was das eigene system eventuell besser kann, das würde der seriösität ungemein helfen.
Worauf beziehst Du Dich? Weder in der News noch in den Kommentaren hat bislang jemand gesagt, dass die Lage bei TYPO3 besser wäre - im Gegenteil.
Von Vorteil sind natürlich die einfachen Schnittstellen um Communitys aufzubauen. Egal ob Blog, Forum, etc. Viele fertige und gute Module sind leicht zu installieren und zu betreiben.
Eigene Inhaltselemente sind mit CCK und Views ein Kinderspiel und ich muss sagen, dass ich noch kein CMS kenne, wo das Anlegen eigener Inhaltselemente so leicht ist.
Der gravierenste Nachteil momentan ist im Moment das Caching. Sind viele CCKs und Viewsabfragen auf der Seite intergriert, so lädt die Seite flott, solange die Seite gecacht wird. Alles lädt fix und ohne Probleme.
Das Caching ist in der Standardinstallation aber nur aktiv, wenn ein Benutzer nicht in das System angemeldet ist. Habe ich einen internen Bereich, wo sich Benutzer anmelden müssen (z.B. Forum, geschützter Bereich etc.) ist dieses Caching deaktiviert.
Die Seite verliert massig an Performance, da die Abfragen an die mysql DB mit unzähligen Joins recht eckelig sind. Da Drupal als Community CMS gilt, verliert es hier die meisten Pluspunkte.
Momentan wird eifrig an einer Lösung gearbeitet (siehe Drupal High performance group), doch bis zum Release von Drupal 7 wird es wohl noch dauern.
Verzichtet man bei einer hochlastigen Seite auf diesen internen Bereich, so ist Drupal sehr zu empfehlen.
Spätestens bei diesem Satz könnte man eigentlich aufhören zu lesen:
"A CMS requiring a slew of third-party mods before it can be usable is useless to someone who can code a custom Rails CMS in a day or two. (Hint, hint. Build it in Rails.)"
Ei, wo isses denn, das super duper In-2-Tagen-mit-RoR-gebaute-CMS?
[...] Warum Drupal nervt – Rails-Entwicklerin zieht über das Open-Source-CMS her Ich mag zwar Ruby on Rails nicht, aber wahren Worten über ein total überbewertetes CMS kann ich nur zustimmen… [...]
Die Modulpolitik: für fast jede Funktion wird ein Modul(welches dann abhängig von weiteren ist, wo es bestimmt wieder schöne Bugs gibt.) gebraucht bei welchem man sich durch Bugs, Patches und wenn Dokumentation durch die Modul-issius der verschiedenen Versionen kämpfen muss. Genau so das Templating, ein Graus in der 5er Version.
Aber mit einer neuen Version wird alles besser, leider geht das mit den Updates nicht so einfach, da die API sich immer schön ändert.
In Drupal 6 hat es viele Verbesserungen für die von spencer genannten Dinge wie Rechte- und Profilverwaltung gegeben.
Drupal ist eher als Framework zu sehen als eine bestimmte Art CMS (wie Community CMS). Um den Kern möglichst klein zu halten, sind deshalb zusätzliche Funktionen nicht mitgeliefert. Das kommt auch den Endbenutzern zu gute, denn Module, die nicht im Kernsystem enthalten sind, können viel flexibler weiterentwickelt werden und öfter neue Features erhalten, als wenn sie im Kern enthalten wären. Dann würden sie nur alle 12 - 24 Monate neue Features bekommen können.
Die Lernkurve ist wie gesagt recht hoch, aber hat man einmal raus wie es geht, kann man alles damit umsetzen. Meiner Meinung nach gerade größere Seiten, für kleine Seiten könnte gerade für Einsteiger der Aufwand zu groß sein. Es gibt ja auch genügend Beispiele für große Webseiten, die erfolgreich mit Drupal laufen.
http://www.whitehouse.gov
Im Vergleich mit C#/Java ist das eine "Bastelsprache" in meinen Augen.
Deshalb werden viele Systeme die darauf aufsetzen auch entsprechend "Bastelsysteme" sein.
Mittlerweile bereue ich die Entscheidung aus verschiedenen Gründen: Die schon erwähnte Modulabhängigkeit ist einfach nur lästig und die Modulqualität ist absolut durchwachsen. Leider braucht man für jede Pupu-Funktion irgendein Modul. Eine granulare Benutzerverwaltung im Kontext zu den Inhalten z. B. war nur total umständlich über Inhaltstypen und Taxonomy Access Control umzusetzen.
Das vielbeschworene Modul Views-Modul ist in Bezug auf die Bedienung das Beknackteste, was mir jemals untergekommen ist. Dabei hat man nicht mal die Flexibilität, die man prinzipiell erwartet. Jeder, der auf die listenartige Darstellung von Daten angewiesen ist, sollte sich mal das Konzept der CustomFields von ExpressionEngine ansehen.
Templates zu erstellen macht in Verbindung mit dem Drupal PHP-Code überhaupt keinen Spass und man hat auch nicht die volle Kontrolle über das generierte HTML. Es ist einfach supersperrig, als codender Designer damit zu arbeiten ("function garland_preprocess_comment_wrapper(&$vars) < alles klar)".
Dazu kommen Kleinigkeiten wie z. B. das sich wiederholenden READ-ONLY setzen der config-Datei durch das System. Ist immer wieder voll produktiv, sich wegen so einem Sch*ss auf dem Entwicklungsserver einzuloggen und die Datei zu 'changemoden'. Die drupal.org Seite nebst Dokumentation trägt ebenso nicht zur allgemeinen Entwirrung bei. Z. B. das hier: http://drupal.org/node/52241
Und ganz ehrlich: Das "Backend" bzw. die Editierfunktionalität nach dem Einloggen mit dem Bilderupload und Platzieren von Bildern möchte ich meinen Kunden nicht zumuten (Ja, ich weiss, es gibt auch hier wieder Module).
Meiner Meinung nach sind Systeme wie Joomla oder Drupal einfach nicht so gut wie ihr Ruf. Es gibt Werkzeuge, mit denen lässt es sich wesentlich besser (im professionellen Bereich) arbeiten. Wordpress z. B. ist auch ein bisschen (sehr) dreckig, was Codequalität, Dokumentation und Konzept angeht, allerdings komme ich hier mit eigenen Plugins schnell zum Ziel und muss nicht erst 3 Wochen im Keller eine komplizierte API studieren. Ansonsten sind z. B. Typolight, ExpressionEngine und Textpattern schlanke, sichere und modulare Systeme, mit denen man sehr gut produktiv arbeiten kann. Und wenn man ein PHP-Framework will, setze ich gleich auf das an RoR angelehnte Cake, das schlanke CodeIgniter oder Zend und schlage mich nicht mit den prozeduralen Spagettis rum.
Ich kann mir nur vorstellen, dass die Drupaluser, die das CMS wie den Gral verteidigen, sich noch nicht genügend mit anderen System auseinandergesetzt haben.
Mittlerweile bereue ich die Entscheidung aus verschiedenen Gründen: Die schon erwähnte Modulabhängigkeit ist einfach nur lästig und die Modulqualität ist absolut durchwachsen. Leider braucht man für jede Pupu-Funktion irgendein Modul. Eine granulare Benutzerverwaltung im Kontext zu den Inhalten z. B. war nur total umständlich über Inhaltstypen und Taxonomy Access Control umzusetzen.
Das vielbeschworene Modul Views-Modul ist in Bezug auf die Bedienung das Beknackteste, was mir jemals untergekommen ist. Dabei hat man nicht mal die Flexibilität, die man prinzipiell erwartet. Jeder, der auf die listenartige Darstellung von Daten angewiesen ist, sollte sich mal das Konzept der CustomFields von ExpressionEngine ansehen.
Templates zu erstellen macht in Verbindung mit dem Drupal PHP-Code überhaupt keinen Spass und man hat auch nicht die volle Kontrolle über das generierte HTML. Es ist einfach supersperrig, als codender Designer damit zu arbeiten.
Dazu kommen Kleinigkeiten wie z. B. das sich wiederholenden READ-ONLY setzen der config-Datei durch das System. Ist immer wieder voll produktiv, sich wegen so einem Sch*ss auf dem Entwicklungsserver einzuloggen und die Datei zu 'changemoden'. Die drupal.org Seite nebst Dokumentation trägt ebenso nicht zur allgemeinen Entwirrung bei. Z. B. das hier: http://drupal.org/node/52241
Und ganz ehrlich: Das "Backend" bzw. die Editierfunktionalität nach dem Einloggen mit dem Bilderupload und Platzieren von Bildern möchte ich meinen Kunden nicht zumuten (Ja, ich weiss, es gibt auch hier wieder Module).
Meiner Meinung nach sind Systeme wie Joomla oder Drupal einfach nicht so gut wie ihr Ruf. Es gibt Werkzeuge, mit denen lässt es sich wesentlich besser (im professionellen Bereich) arbeiten. Wordpress z. B. ist auch ein bisschen (sehr) dreckig, was Codequalität, Dokumentation und Konzept angeht, allerdings komme ich hier mit eigenen Plugins schnell zum Ziel und muss nicht erst 3 Wochen im Keller eine komplizierte API studieren. Ansonsten sind z. B. Typolight, ExpressionEngine und Textpattern schlanke, sichere und modulare Systeme, mit denen man sehr gut produktiv arbeiten kann. Und wenn man ein PHP-Framework will, setze ich gleich auf das an RoR angelehnte Cake, das schlanke CodeIgniter oder Zend und schlage mich nicht mit den prozeduralen Spagettis rum.
Ich kann mir nur vorstellen, dass die Drupaluser, die das CMS wie den Gral verteidigen, sich noch nicht genügend mit anderen System auseinandergesetzt haben.