Das Joomla Template, die Nerven, die Kosten

Im Moment der direkte Vergleich: einmal eine neue TYPOlight Seite mit recht spannendem Layout und einmal Joomla mit dem “Nachbau” eines Layouts einer “Dachorganisation” für den regionalen Internetauftritt eines gemeinnützigen Verbands.

Ein paar wundersame, aber auch ärgerliche Aspekte fallen da wieder auf, vor allem aber eins, was wir natürlich schon wissen: Joomla hat ein wenig zu viele Tabellen und insgesamt zuviel “drumrum”. Ich muss mal wieder meinen Frust loswerden - und meine Verwunderung.

Wie bei jedem Template starte ich ohne ein CMS, baue eine rudimentäre HTML Seite, gestalte die Blöcke und baue dann den den Body zunächst in die index.php des Templates (Joomla) bzw in eine von mir gewünschte Template Vorlage (Typolight) und binde dann die CMS eigenen PHP Anweisungen ein. Menügestaltung, Blöcke und alles weitere Systemspezifische passiert dann direkt im CMS. Meine Vorgehensweise ist hier immer gleich.

Der Vorteil  ist klar: solange ich nur die Blöcke definiere, kann ich mit Dummytexten und Platzhaltern arbeiten und schleppe keine zusätzlichen Lasten mit mir herum. Ich muss mich vor allem nicht mit Demoinhalten herumschlagen oder bereits vorab Strukturen und Inhalte anlegen, die mich zu diesem Zeitpunkt nur stören. Und eigentlich klappt das auch ganz gut, wäre da nicht Joomla.

Auffällig…

So fiel mir bei der Arbeit an den beiden Projekten eines sehr deutlich auf. Kurz: für meine Begriffe sieht so ein Joomla Template lange Zeit ziemlich “wüst” aus, verglichen mit TYPOlight.

Joomla hat erstens  zu viele Tabellen und zweitens eine Reihe an recht überflüssigen, teils inkonsisten eingesetzten, kaum wiederverwendbaren Containerelementen, die in der Summe dazu führen, dass ein Drehen an der Schraube links ungewünschte Effekte der Schraube rechts nach sich zieht- ohne dabei die typische CSS Vererbungslehre positiv ausnutzen zu können. Zusätzlich fehlen einfach Klassenelemente,- insbesondere für die Core Erweiterungen wie Weblinks oder Kontakte.

Parallel dazu führen diverse Erweiterungen (auch die großen, bekannten, ich rede hier nicht von irgendwelchen windigen Addons) mit ihren zum Teil wenig flexiblen, vor allem aber proprietären Layoutdefinitionen zusätzlich dazu, dass immer wieder irgendwas nicht passt.

Es gibt mehrere Konzepte, die wirklich fragwürdig sind und dem Webdesigner das Leben entsetzlich schwer machen:

  • der exzessive Einsatz von Tabellen inklusive der Einsatz von colspan
  • die immer wiederkehrende feste Kodierung von width und style, gerade bei Tabellen
  • das immer wiederkehrende Konzept der Klasse contentpane(open) in beliebigem Kontext
  • die Klasse article_seperator
  • ein wüstes Durcheinander von Überschriften, insbesondere h2 und h3, ohne jegliche semantische Ordnung

Gelungen hingegen, ganz abgesehen vom Joomlaschen Tabellendilemma, die TYPOlight Idee, viele wiederverwendbare Elemente mit einer allgemeingültigen und einer kontextspezifischen Klasse auszustatten, beispielsweise die Klassen mod_article, ce_text und block plus erweiterungsspezifischer Klassen. Hier wurde mitgedacht, so dass eine Styledefinition sich in die Gesamtseite integriert, ohne an anderer Stelle kontraproduktiv zu wirken.

Es zeigt sich ganz klar: der Aufbau wie auch der Einsatz von HTML Elementen wie auch CSS Klassen und IDs will im Gesamtkontext nicht nur technisch sondern auch logistisch durchdacht sein. Insbesondere gilt dies für das Zusammenspiel semantischer HTML Elemente wie Überschriften. Hier fehlt Joomla ganz klar der durchdachte, objektorientierte (!) Ansatz.  Es scheint, als würde man sich für alle möglichen Elemente einfach schnell mal aus einem Satz vordefinierter Klassenstile bedienen  und das ohne Rücksicht auf Verluste.

Eine Frage der Kosten, der Nerven und des Arbeitseinsatzes

Nein, ich möchte nicht (wieder) auf Joomla und TYPOlight herumreiten. Es geht um einen anderen Aspekt: die Kosten, die eine unsaubere Konzeption innerhalb des Projekts verursacht.

Wer nämlich nun entgegenhalten möchte, man könne dies ja alles nach persönlichen Vorlieben korrigieren abändern, hat grundsätzlich natürlich recht. Thomas hatte es irgendwann kommentiert: Joomla bietet ein leistungsstarkes Framework, das sich gut anpassen, sprich erweitern oder individualisieren lässt. Update: Ich bin mir da nur nach wie vor nicht so ganz sicher, - und das ist eine grundsätzliche Definitionsfrage, ob man da noch von Joomla sprechen kann oder ob es sich dabei dann nicht um “Core Hacks” (und hier fiel mir so auf die Schnelle nichts besseres ein, aber stehen lassen kann man das nur in einem recht laxen Kontext, denn auf ein Framework aufbauen ist natürlich etwas anderes als ein Framework ändern (also den Core hacken), besser also:) ein “Derivat” handelt.
Ein anderes wesentliches Argument übersieht der Joomlafan dabei: diese ganzen Veränderungen machen ein Projekt zeitaufwändiger und damit teuerer. Ganz abgesehen davon, dass ich das solide, leistungsstarke Framework in der Basis gerne ohne umfangreiche individuelle Anpassungen (!= Hack)  bekäme.  Warum Ergänzungen und umfangreiche Templates machen, wenn es mit einem anderen System bereits wunderbar ohne jene, ja zum Teil durchaus nervenden Anpassungen funktioniert?

Fazit für mich ganz klar, ganz abgesehen von meinem Faible für dieses klare, sehr elegante TYPOlight:

Das eine ist die Funktionalität, sowohl was den Core als auch verfügbare Erweiterungen betrifft. Das andere ist der Blick auf Layoutkonzepte und das Template Rendering. Es gibt gute Gründe, sich für Joomla zu entscheiden: der große Pool an Addons für jedes nur erdenkliche Szenario. Es muss jedoch abgewogen werden, welchen Preis man bereit ist, dafür zu bezahlen. Der Preis steckt vor allem im Template. Aus meiner Sicht ist es schlicht unmöglich, ein Joomla Template zu erstellen, das später jedem nur erdenklichen Addon in irgendeiner Form standhalten kann, ohne zu optischen Katastrophen zu führen (da kann mir der Herr Rocket Theme erzählen, was er will). Der Worst Case ist damit erreicht, wenn weniger layout-versierte Administratoren zusätzliche Erweiterungen integrieren möchten. Dass es prinzipiell zumindest mit deutlich weniger Arbeitsaufwand und nur ein paar Kleinigkeiten geht, zeigen andere Systeme.

Wer Joomla einsetzt, muss wissen, auf was er sich einlässt. Es bleibt zu hoffen, dass mit Joomla 1.6 endlich alles besser wird… ich bin erstmal wieder durch. Hier schreibe ich Verzweiflung mal ganz groß…

Update

Doch noch ein Satz zum ersten Kommentar. Es ist prima, dass wenigstens der Override funktioniert. Nur genau das ist der Punkt:

Ich möchte die Flexibilität genießen können, Änderungen vorzunehmen und Template-Elemente an meine Wünsche anzupassen. Ich möchte mich aber nicht der Notwendigkeit gegenüber sehen, es zu tun. Es wäre wünschenswert, dass bereits der Core alles mitbringt, was ich für eine schnelle, saubere Umsetzung brauche. Und das ist bei Joomla definitiv nicht gegeben.

Don’t make me think! - ganz einfach. Ich will nicht darüber nachdenken. Ich will auch nicht mal “ganz schnell” eine Erweiterung umcoden - was ich jahrelang gemacht habe. Das alles zahlt der Kunde mit Geld und ich mit meinen Nerven. Wie will ich das bitte “verkaufen”?  Es ist dann und nur dann akzeptabel, wenn man auf sein eigenes, auf Joomla basierendes System aufsetzt. Und das beispielsweise kann ich nicht machen, wenn ich nicht auch der bin, der später für die Installation von Sicherheitspatches etc verantwortlich bin. From the scratch - so wie jetzt- war es definitiv mal wieder unbefriedigend.

 

9 Antworten zum Beitrag “Das Joomla Template, die Nerven, die Kosten”

  1. am 17 Jun 09 um 10:42 meint

    Roghetti

    Tjajaja…dabei gehts ab 1.5 so einfach…du nimmst dir die Oveerrides aus dem beez-Template (Den “html”-Ordner) und siehst vin Tabellen (fast) nichts mehr, in einem von zehn Fällen schreibst du dir selbst ein override! google doch einfach mal nach diesen tollen dingern ;-)

    Bei den Erweiterungen musst du natürlich auch aufpassen, dass keine tabellen mitkommen, aber acuh das hat man schnell angepasst!

    Mir bleibt nur zu sagen, dass du mit Overrides keine Core-Hacks mehr brauchst - und Overrides gibt es seit 1.5!

  2. am 17 Jun 09 um 10:51 meint

    Anne-Kathrin

    Die Overrides aus dem Beez Template oder ganz eigene. Das war mir schon klar.
    Nur - und jetzt kommt mein großes ABER:
    Warum kann das nicht der Core schon vernünftig?
    Warum brauche ich Overrides aus dem Beez Template? Das kann es doch nun wirklich nicht sein - und genau darum geht es.
    Warum braucht ein CMS erst ein zusätzliches Template, das mitbringt, was eigentlich das CMS selbst mitbringen sollte…?

    Kurz: ich erwarte mir die Möglichkeit zur Anpassung. Nicht jedoch die Notwendigkeit!

  3. am 19 Jun 09 um 00:45 meint

    Verena

    Warum setzt du denn überhaupt noch Joomla ein? Warum nicht generell TypoLight oder eins der moderneren CMSysteme.
    Ich hatte vor Jahren auch mal zwei Sites in Joomla umgesetzt (version 1.0.12), es waren meine ersten Erfahrungen mit CMS und ich war sehr begeistert, auch von der community. Die Seiten laufen bis heute schön stabil, das erstaunt mich immer wieder, aber beim core ist fast kein Stein mehr auf dem anderen, weil das, was die Kunden brauchten, dann doch individuell und per Hand via PHP eingebaut werden musste, und das hatte Joomla gar nicht gerne.
    Worin siehst du heutzutage konkret die Vorteile von Joomla?

  4. am 19 Jun 09 um 01:33 meint

    Hallo,

    wenn Du mich mit “Thomas” meinst, möchte ich klarstellen, dass ich Core-Hacks aufs tiefste verabscheue, nie mache (bei Joomla) und steif und fest behaupte, dass wer das macht, zu wenig Ahnung von Joomla hat.

    Darüber hinaus habe ich mir abgewöhnt, an CMS-Diskussionen teilzunehmen. Joomla 1.5 macht das, was ich will.

    Gruß, Thomas

  5. am 19 Jun 09 um 05:32 meint

    Anne-Kathrin

    Hallo Thomas,

    du hast natürlich recht, ich weiß das selbstverständlich und wollte dir durch meine missverständliche Formulierung nichts unterstellen sondern im Gegenteil - und das ist hier gründlich schief gelaufen, darauf hinweisen, was man denn nun an Möglichkeiten hat. Du hattest es irgendwann so schön formuliert - und mir ja damals auch irgendwie fast wieder ein wenig Lust auf Joomla gemacht ;-)

    Ich habe daher obigen Text angepasst, um jegliches Missverständnis aus dem Weg zu räumen und muss mich nun erstmal entschuldigen.

    Der Preis sind hoch - und das muss ich noch ergänzen: In diesem Fall habe ich erstmal “nur” das Template gemacht - wobei auch eine Reihe von Erweiterungen im Spiel waren. Tja, - was macht man da? Auftrag nicht durchführen? Das Beste draus machen? Alles anpassen und hindrehen (dann sind wir beim Core zumindest einiger Erweiterungen!)? Augen zu und durch? Aus persönlichem Idealismus Overrides bis zum Anschlag schreiben, auch wenn das nicht im Budget ist? Oder soll ich sagen: nehmt “mein” Joomla. Eine Variante, in der ich bereits einen Basissatz in Richtung “Dieses Joomla tut, was ich will” integriert habe?
    Dieses Modell “Template Coding” - das ich lange Zeit immer sehr unglücklich gemacht habe - hat für mich zwar bereits seit langem ausgedient (aus verschiedenen Gründen, die einen eigenen Artikel wert wären), hier aber habe ich nun die Bestätigung bekommen.

    Das waren meine Fragen - und auf die habe ich keine Antworten bekommen… Schade, immer wieder schade.

  6. am 20 Jun 09 um 13:45 meint

    Ganz out of the box bekommt man wohl nirgends Templates, die exakt den eigenen Vorstellungen entsprechen. Das Update macht klar, dass Du das auch nicht erwartest (ich hatte mich schon ein wenig gewundert).

    Mein Tipp: Schau Dir mal Drupal an. Dort gibt es ein sehr granulares Theming-System, d. h. man kommt dem HTML (fast) jeden Outputs problemlos bei und kann umgestalten. Aber auch das, was Drupal standardmäßig erzeugt, ist anständiger Code. Meistens überladen, so ist das halt bei Frameworks, mehr oder weniger ausjäten empfiehlt sich also schon, aber das kann man ja.

    Durch seine Modularität ist Drupal ungeheuer flexibel: Man kann eigene Inhaltstypen definieren und individuelle Datenbankabfragen über ein spezielles Interface zusammenstellen. Mehrsprachigkeit, kleinteilige Rechteverwaltung, Bloggen, e-Commerce, jede Menge Add-Ons … alles da. Übrigens, im Unterschied zu Joomla gehen neue Module (Joomla: Extensions) durch ein Filterverfahren, das dafür sorgt, dass Wildwuchs im Sinne paralleler Entwicklungen begrenzt wird und die Codequalität gut ist.

    Eine Hürde gibt es: Mal eben einsteigen und easy bedienen ist nicht (wobei es für “Entwickler” sicher einfacher ist als für “Designer”, plus dem “Veteranen-Bonus”, den Du aus Joomla mitbringst). So durchdacht das ganze System ist, es ist auch komplex. Es gibt zwar eine ausführliche Dokumentation, deren offizieller Teil durch Kommentare aus der Community bereichert wird. Trotzdem, Google wird Dein treuester Begleiter. Wenn man die Komplexität aber einmal durchdrungen hat, hat man ein sehr potentes Tool. Manche sagen, Drupal sei das bessere Joomla - das hat schon was.

  7. am 20 Jun 09 um 14:29 meint

    Anne-Kathrin

    @UschaSu:
    Da könnt ich auch wieder Romane schreiben, aber ich werde und will hier keine CMS Diskussion lostreten ;-)

    Eine Qualitätsprüfung der Addons ist begrüßenswert - ist ja auch nichts Neues, nur Joomla leidet da noch ein wenig.
    Klar ist: ich glaube, es geht fast nirgendwas, das “einfach mal so anfangen”. Man muss sich drauf einlassen - dann klappt es mit JEDEM CMS. Dumm nur, wenn da der ein oder andere meint, er bekäme das beim CMS seiner Wahl alles inklusive (die Eigenschaft: selbstlernend).

  8. am 22 Jun 09 um 05:02 meint

    Dietmar

    >Warum brauche ich Overrides aus dem Beez Template? Das kann es doch nun wirklich nicht sein - und genau darum geht es.
    >Warum braucht ein CMS erst ein zusätzliches Template, das mitbringt, was eigentlich das CMS selbst mitbringen sollte…?

    Weil Tabellenlayouts auch von Anfängern gestaltet werden können, die nicht einmal wissen, was die einzelnen Buchstaben in CSS bedeuten. Die wissen auch nicht, was Overrides sind. Ich weiß es aber, und du weißt es auch, und du bist auch im Gegensatz zu Anfängern in der Lage, die Möglichkeiten, die sich dadurch bieten, auszuschöpfen. Und weil Joomla von weitaus mehr Anfängern als Profis eingesetzt wird, ist die Entscheidung damals in diese Richtung gefallen.

    In der 1.6 wird es umgekehrt sein: Der Core gibt tabellenfreien Code aus, und wer weiterhin Tabellen will, wird das Milkyway mit seinen Tabellen-Overrides oder einen Ableger benutzen müssen. Dafür wird es dann erheblich mehr Fragen von Anfängern zu simpelsten Formatierungsproblemen geben.

    Typolight ist ein schönes CMS, aber für eine völlig andere Zielgruppe als Joomla.

  9. am 04 Jul 09 um 16:46 meint

    Markus

    Wie Thomas schon schrieb:

    Joomla 1.5 macht das, was ich will.

    Und mehr muss man eigentlich nicht dazu sagen.

    @Dietmar:
    Typolight ist ein schönes CMS, aber für eine völlig andere Zielgruppe als Joomla.

    Sehe ich aus einer anderen Perspektive: Ein CMS mag eine Zielgruppe haben. Aber es liegt an jedem was aus dem CMS zu machen. Und da stimmt wieder die Aussage von Thomas die man dann sogar noch auf alle Systeme aus weiten kann!

Auch was dazu sagen?