TYPO3 vs. Drupal: Vor- und Nachteile und was TYPO3 dringend machen muss

Richtig gezankt wird vor allem in den Kommentaren des t3n-Magazins zum Thema TYPO3 und Drupal. Der Artikel (Link s.u.) ist als „Battle“ betitelt und interviewt 2 Menschen über Pro und Contra beider Content Management Systeme. Das Thema ist durchaus berechtigt und es konfrontiert jede Agentur, die das eine oder das andere CMS einsetzt, natürlich erst mal mit seiner eigenen Zukunft und Existenz. Hier nun einige Zitate aus dem Artikel, die für mich die wichtigsten Gründe für und gegen TYPO3 und Drupal darstellen sowie Folgerungen, die ich für die Zukunftsfähigkeit von TYPO3 schließe.

pro TYPO3*:

„Die Templates sind völlig standardisierte W3C-konforme Templates, […] man kann per Point & Click durch einen Wizard gehen und so innerhalb von Minuten sein komplettes Template mappen.“

„[…] ist das System bei richtigem Einsatz […] automatisch upgradebar, was es in großen Umgebungen sehr beliebt bei den IT-Abteilungen macht“

„TYPO3  4.x hat klare Roadmaps und einen fest definierten sechsmonatigen Release-Zyklus für Major Releases und derzeit läuft ja auch schon parallel ein Rewrite des gesamten Systems (5.x Codename Phoenix)“

„TYPO3 hat vor allem diese Entscheidung zu einer Enterprise-Architektur schon vor drei Jahren getroffen, das heißt hier ist schon ein klarer Vorsprung zu vermerken.“

pro Drupal*:

„Man kann nun mit dem fantastischen Views-Modul „Views“ (Auswahl und Präsentation von Inhalten) von jeder möglichen Mischung der Entities bauen. Noch besser: Views können von jeder erdenklichen Daten-Quelle gebaut werden“

„Drupal ist Pionier in Sachen Semantic Data“

„Drupals Bedienungskonzept unterscheidet nicht besonders stark zwischen Front- und Back-End. […] Um einen Inhalt zu editieren, muss man nur dahin navigieren – wenn der Benutzer die entsprechende Freigaben hat, kann er editieren. Simpel aber effektiv“

„Im Drupal 7 Release-Zyklus geht der ganze Core-Code durch ein „integrated testing framework“. Dies wird demnächst ein „distributed CI performance testing network“ werden, welches dann auch alle Community-Module testen wird.“

contra TYPO3*:

„TYPO3 und Extensions wird ab und an vorgeworfen, zu komplexen und schwierigen Code zu haben. Das trifft auch auf einige Module zu […]“

contra Drupal*:

„Um in Drupal annähernd die Features von TYPO3 darzustellen, brauche ich ca. 60 Drupal-Module, mit zig Abhängigkeiten.“

„Drupals Standard-Templating-System ist eine Mischung aus HTML und PHP“

contra beide*:

„Andererseits werden Frameworks immer die beste Lösung sein für Systeme, die wirklich einzigartig sind oder nicht von den großen Vorleistungen eines CMS wie Drupal oder TYPO3 profitieren können.“

* alle Zitate: CMS-Battle: TYPO3 vs Drupal – Wettkampf über 20 Runden » t3n News

Mein Fazit

Ich habe Erfahrungen mit beiden CMS sowie mit WordPress gesammelt, und ich arbeite auch noch immer mit beiden CMS. Es handelt sich bei TYPO3 und Drupal um zwei völlig unterschiedliche Herangehensweisen, wobei die allgemeinen Anforderungen an Internetseiten der vergangenen Jahre deutlich für Drupal sprechen. Das will ich begründen.

Drupal hat keine Baum-Struktur für den Seitenaufbau

Bei Drupal ist ähnlich wie bei WordPress die Seite erst einmal leer und kann relativ wenig. Die Seitenstruktur ist nicht wie bei TYPO3 als Baum dargestellt. Der Baum hat zwar Vorteile (z.B. drag and drop Seiten verschieben), drängt den Admin jedoch erst mal gedanklich in die Richtung, dass die Seite eine Ordner-Struktur in die Tiefe hat. Diese Verschachtelung von Webseiten hat aber abgenommen. Youtube hat vor Jahren schon gezeigt, dass man Unmengen an Content ohne tiefe Verschachtelung darstellen kann. Dagegen wirkt so manche Universitäts-Webseite mit TYPO3 überfüllt und träge.

Stattdessen hat Drupal CCK, Taxonomien und Views

Die Strukturierung der Inhalte bei Drupal kann sowohl in Menüs als auch auf andere Weise geschehen. Wo TYPO3-Nutzer immer wieder auf tt_news zurückgreifen, um auch andere Arten von Objekten zu kategorisieren, ist es in Drupal schnell möglich, eigene Objekttypen (Content Types) mit dem Content Construction Kit (CCK) zu erstellen, diese dann durch jede Art von Taxonomien (Kategorien und/oder Tags) zu kennzeichnen, und dann mit „Views“ auf komplexeste Art zu sortieren und als Listen, RSS-Feeds oder wie auch immer auszugeben. Views kann zudem noch auf externen Content irgendwo im Netz zugreifen, so auch demnächst sogar per SPARQL.

Was TYPO3 unbedingt ändern sollte

TYPO3 hat auch Vorteile, und das sind die Dinge wie TemplaVoila, Typoscript, der Dateimanager, was jedoch schon vor Jahren erfunden wurde und bestimmt auch die Entscheidung vieler für TYPO3 als CMS bedingt hat. MVC-Struktur ist toll, aber das ist eben nur eine Voraussetzung des Systems für gute Arbeit, jedoch noch kein gute Arbeit an sich. Es sind nicht viele Dinge, die TYPO3 ändern muss, um an Drupal dran zu kommen. Die Lösung sind meiner Meinung nach 3 Erweiterungen. Wer sich an der Entwicklung beteiligen will bzw. diese sponsoren möchte, der melde sich bitte bei mir!

1. Taxonomy

Taxonomien, also Tags und Kategorien dürfen nicht weiter an einzelnen Module und Inhaltstypen gebunden sein. Man muss sie aus dem Backend egal welchem Inhaltstyp zuordnen können, also allen Dingen, die auch in der Listenansicht auffindbar sind.

1. User Content Types

Es muss endlich eine Extension her, die das Erstellen von angepassten Inhaltstypen ermöglicht. Das darf nicht weiterhin tt_news sein. Dazu gehören dann auch bestimmte Felder wie Bild, Datei, Link, Upload sowie Verknüpfung zu allen anderen Content Types.

3. Views

Man braucht etwas anderes als Typoscript, um diverse Content Types sowie sonstige Inhalte aus der Datenbank auszugeben. Das Views-Modul bei Drupal ist absolut vorbildlich mit dem, was alles möglich sein kann. Hieran sollte man anknüpfen und eine ähnliche Erweiterung entwickeln.

Diese drei Module sind meiner Meinung nach die Grundvoraussetzung für flexible Seitengestaltung in TYPO3.

Für Hinweise, welche TYPO3-Extensions diese Möglichkeiten bereits bieten, sowie für Vorschläge, was man sonst noch von Drupal lernen kann, bin ich offen. Schreibt einfach Kommentare auf diese Seite.

10 Gedanken zu „TYPO3 vs. Drupal: Vor- und Nachteile und was TYPO3 dringend machen muss“

  1. Hallo Michael,

    vielen Dank für diese extreeem differenzierte Auseinandersetzung mit unserem Interview zu Drupal und TYPO3. Genau solche Beiträge habe ich mit gewünscht, als wir das Interview geplant haben. Was die drei Extensions angeht: Werde mal versuchen, Deinen Beitrag etwas zu spreaden, vielleicht finden sich da ja Leute, die Bock drauf haben…

  2. Guter Bericht. Ich denke auch, dass TYPO3 bei der Entwicklung von Extensions sich ein Vorbild an so manchen Drupal Modulen nehmen kann. Bei Drupal werden viele Module viel allgemeiner, offener entwickelt und nicht zu sehr auf einen speziellen Anwendungsfall. So z.B. Views, CCK, Rules, Wysiwyg, Panels, usw.
    Bei TYPO3 würde ich den Kickstarter als eine Art CCK Vergleich hernehmen. Wobei das nicht hundertprozentig passt. DB Integration klingt ein bischen nach Views (habe ich noch nie eingesetzt) .
    Ich finde es auch faszinierend, dass bei Drupal ein Modul oft aus einem kleinen Forumseintrag entsteht. Da hat einer eine Idee und postet dies, dann steigen viele mit ein – oft auch nur durch ein einfaches „comitted“.

    Aber ich kenne Leute, die keine Programmierer sind und trotzdem mit Drupal nur durch „klicki-klicki“ sich ganze Portale aufgebaut haben. Das ist mit TYPO3 nicht möglich und spricht für Drupal. Z.B. [Link wurde entfernt] oder [Link wurde entfernt].

    Dennoch bin ich überzeugt, dass TYPO3 durch die neuen Basis-Technologien wie extBase und Fluid und deren modernen Design Patterns noch mehr „professionelle“ Entwickler anzieht und somit TYPO3 Phoenix schnell Gefallen finden wird. Ein bischen mehr raus aus der Bastler „Linux-Freak“ Ecke, mehr in die hübsche „Klicki-Klicki-Barbie-Word-Press-Welt“ kann TYPO3 auch nicht schaden und wird mit der aktuellen Version 4.3 und TYPO3 Phoenix gemacht. (Hoffentlich auch mit dem Relaunch von TYPO3.org)

    Wie heißt es immer so schön – wer zuletzt lacht…

  3. Danke! Würde mich vor allem freut mich, wenn der Artikel etwas bewirkt.

    Habe mich heute noch mit extbase und fluid auseinandergesetzt und muss noch immer feststellen, dass TYPO3 etwas schwerfällig für user defined content types ist. Das ist alles gut gemeint, aber läuft dann doch noch nicht so einfach. Ich bin auch kein Fan von WordPress und seine „Klick Dir alles zusammen“ – Strategie, besonders für größere Webseiten, aber TYPO3 ist in der Hinsicht zu kompliziert. Selbst Magento mit einer strikten MVC-Architektur hat z.B. auch Attribute und Attribute-Sets, die man einfach im Backend definieren und hinzufügen kann. Typo3 braucht diese Möglichkeit unbedingt, und das für Leute ohne PHP-Kenntnisse!

    Leider bisher aber noch keine konkrete Reaktion auf meine Idee mit den Extensions.

  4. Zum Punkt
    1. User Content Types

    Es muss endlich eine Extension her, die das Erstellen von angepassten Inhaltstypen ermöglicht. Das darf nicht weiterhin tt_news sein. Dazu gehören dann auch bestimmte Felder wie Bild, Datei, Link, Upload sowie Verknüpfung zu allen anderen Content Types.

    Wie wär es denn mit TemplaVoila und FCE’s? Was ist mit dem Kickstarter?
    TYPO3-Kochbuch oder TYPO3- Extensions. Professionelle Frontend- und Backend-Programmierung. Mit Extbase und Fluid, ich kanns nur empfehlen

    Wysiwyg – gibts schon seit Ewigkeiten bei TYPO3!!!

    Rules – gibts auch schon seit Ewigkeiten, schon an Benutzerrechte gedacht oder Workspaces?

    Die Strukturierung der Inhalte bei Drupal kann sowohl in Menüs als auch auf andere Weise geschehen.

    Struktur? Bei Drupal? Witzig.

    Es ist doch immer wieder die Frage, was will ich machen?
    Für ein Newsportal würde ich kein Drupal nehmen, um schnell einen einfachen Blog zu erstellen, ist Drupal nun wieder eine bessere Alternative.

  5. “ “TYPO3 hat vor allem diese Entscheidung zu einer Enterprise-Architektur schon vor drei Jahren getroffen, das heißt hier ist schon ein klarer Vorsprung zu vermerken.” “

    Ein Großteil der Enterprise-funktionen und v.a. die API-Architektur sind schon mind. 7 Jahre bestandteil des Systems – also bitte besser recherchieren, bevor man hier M+++ verzapft…

  6. Lieber „gast“,
    es handelt sich bei dieser Aussage nur um Zitate von einem t3n-Interview, das in meinem Artikel auch verlinkt ist. Also selbst erst mal den Artikel richtig lesen bevor man hier in den Kommentaren schimpft.
    Übrigens, Beleidigungen, wie Du mir in einem weiteren Kommentar geschrieben hast, markiere ich sofort mit „Spam“.
    Ich möchte hier sachlich mit Fachleuten diskutieren, damit meine ich keine Beschimpfungen.

  7. zu „1. Taxonomy“
    Ist mir um ehrlich zu sein zu hoch was damit gemeint sein soll 😉

    zu 2. „1. User Content Types“
    Stimme „aucheiner“ da zu, das geht wunderbar und strukturiert über Flexible Content Elements FCE und TemplaVoila.

    zu „3. Views“
    Verstehe die Problematik nicht. Grundsätzlich werden Daten von Ihren Extension ausgegeben. Danach folgt noch die Ebene des Typoscript (wenn man sich damit befasst kann man ne ganze Menge anstellen). Dazu gibt es noch die Möglichkeit Typoscript und PHP zu mischen (wenns denn sein muss).
    In 5 Jahren Typo3 habe ich noch nichts gesehen was nicht über Bordmittel, Extensions, Templates, Typoscript zu pflegen gewesen wäre und seit Templavoila ist die Flexibilität ja nun wirklich ein Kinderspiel.

    Grundsätzlich hätte man auf Typoscript verzichten können und besser gut strukturierten PHP-Code verwenden sollen, aber das ist ein anderes Thema.

  8. ALso Fluid würde ich weniger als als als Kontra sehen
    Dsa ganz ist fast schon ein rückschritt eine weiterentwicklung jedoch nicht

    Tempalteproblematik in typo3 is immens
    da müssen andere neue ansätze her nicht die alten etwas aufpolieren

    ich finde es auch etwa unsinnig das man weiterhin html templatefiles erstellen muss – dann noch css templatefiles etc

    hier gibt es fertige technologien /ajax frameworks die zb ein drag and drop /klick/ templateediting möglich machen würden

    ich würde generell alle template und css informationen erstmal im system speichern (dank des caching frameworks wäre dann statischer code zwecks geschwindigkeit kein problem)

    das ganze dann per liveview / edit änderbar machen
    das können sogar shcon einge shopsysteme zumindest teilweise

    und was datentyp3n betrifft so muss ich dem author mehr als recht geben.
    daten werden nur per extensions verwaltet – die flexibelste ist ttnews – das ist aber kein zustand
    sicher lässt sich tt erweitern aber für einen user praktisch unmöglich

    und nein templavoila mit fces ist da kein echter ersatz – das ist zwar ganz nett für flexform und einfachste inhalte mehr aber auch nicht

    was mich zu dem stört ist die notwendigkeit jedesmal neue template und css files zu shcreiben für jede kleine ext die man einbaut

    hier wäre zu meiner idee oben neue ansätze nötig
    bzw auch wiederverwenbarkeit bestehender tempaltes/subtemplates/fces etc

    btw man könnte über diesen weg auch wirklich nur die benötigten css klassen ausgeben – will man das jetzt machen ist zumindest ts code auf jeder seite nötig alles sehr umständlich

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *