Druckbare Version
Moin Zusammen,
ich muss (mal wieder) einen CMS Vergleich anfertigen. Das ist auch insgesamt kein Problem, die meisten Vorzüge von Contao sind mir bekannt.
Dennoch; welche Argumente würdet Ihr ins Feld führen, wenn Ihr Contao statt Drupal verwenden möchtet?
Grüße
das Hauptargument dürfte sein, dass du dich mit Contao bestens auskennst - m. E. bekommt man eine Webseite sowohl mit Contao als auch mit Drupal hin. Die Idee vom Core ist eben bei beiden unterschiedlich und passen demnach je nach Aufgabenstellung mal besser oder schlechter.
Ich habe 2012/13 noch einmal intensiv nach einem CMS auf MySQL-Basis gesucht. Zuvor hatte ich sehr lange phpCMS und PivotX in Verwendung. Mit datenbankbasierten Systemen wie WordPress und Joomla wurde ich nicht warm. Und Typolight (das ich damals noch nicht als Contao wahrnahm) gefiel mir zwar trotz MySQL im Backend aufgrund der Aufgeräumtheit, aber warum sollte ich Typolight nehmen, wenn ich auch die Vollversion TYPO3 haben kann?!
Ich testete mehrere CMS und Drupal begeisterte mich aufgrund der Inhaltselemente und der Struktur. Ich kaufte mir Bücher und Videos und testete Drupal ein halbes Jahr lang. Das K.o.-Kriterium war schließlich, das man jedes kleine Plugin selbst installieren mußte, sogar den WYSIWYG-Editor. Irgendwann hatte ich mir so das System gnadenlos zerschossen, das ich Drupal aufgab.
Danach fiel mir Contao auf und auch der Namenswechsel wurde mir nun klar. Da mir das Backend von Typolight gefiel, blieb ich Contao von da an treu. Der Code ist sehr aufgeräumt und die wichtigsten Plugins sind vorinstalliert (Nachrichten, Termine, Newsletter usw.). Der Wechsel zu Contao 4 machte mir noch einmal das Leben sehr schwer. Aber letztendlich gewöhnt man sich an alles.
Zum aktuellen Drupal kann ich nichts sagen, da ich mich seit 2013 nicht mehr damit beschäftigt habe. Es bleibt einfach keine Zeit für andere CMS, wenn man sich vollständig auf Contao fokussiert und alle Projekte damit umsetzt.
jemand von Drupal könnte gegenüber Contao ins Feld führen, dass man bei Drupal durch den Aufbau auf Knoten im Prinzip alles mit jedem verknüpfen kann und sowas wie MetaModels bei Drupal im Prinzip schon mit dabei ist
aber wie gesagt: ich halte den Ansatz auf die technischen Prarameter zwischen den beiden CMS zu gucken nicht für zielführend - will der Kunde, dass jemand zuverlässig und bezahlbar die Aufgabe umsetzt?
Vielen Dank für Eure Info´s.
Es geht darum, in einem Unternehmen festzustellen, welches der beiden CMS sich womöglich besser eignet.
Es sollen sowohl technische Anforderungen, als auch Benutzerfreundlichkeit gegenübergestellt werden.
Meine persönlichen Contao-Skills sollen dabei erst mal bewusst ausgeklammert werden, wohl aber in die Gesamtbewertung mit einfließen.
Ich sammle also erst mal ein Paar Gedanken, was ich übrigens auch im Drupal-Forum mal anbringen möchte. Mal schauen, was die Drupal-Community dazu sagt.
Grüße
das kommt sehr auf die Anforderungen des Projekts an - Drupal schreibt sich ja auf die Fahnen, bei Community-Projekten mit viel User-Input der Star zu sein.Zitat:
Zitat von tschero
ggf. mal Stephan Luckow vom CMS-Garden kontaktieren - der kennt beides, ist aber Team "Drupal"
Und was sind die technischen Anforderungen?Zitat:
Zitat von tschero
Es soll erst mal geprüft werden, welche Systemvoraussetzungen die beiden CMS benötigen, ob und wie es API-Zugriff gibt, wie die beiden in die bestehende Infrastruktur integriert werden können, ist das vorhandene Personal genügend für die Grund-Administration geschult und welche Hard- und Software ggf. dafür neu beschafft werden müsste.Zitat:
Zitat von Spooky
Das sind so meine Punkte die ich derzeit für wichtig erachte, Vorgaben habe ich natürlich keine (Null, 0), warum auch!?!
Weitere Punkte kommen sicherlich im Rahmen der Gegenüberstellung noch dazu.
Grüße
Je nach Größe des Unternehmens auch außen vor lassen und keine komplizierten Themes nutzen um die zu Vendor-Locken, dann lieber nativ auf Contao setzen und selber bauen.
Ich würde beispielsweise ein "nacktes Drupal" einem "Contao mit bspw. PCT o.ä" vorziehen, rein aus Wartungs-, Kosten- und Dokumentationsgründen.