spackblog

Vorweg: Ich habe mal im Jahr 2005 für ein Projekt einen genaueren Blick in das CMS Joomla geworfen und mich klar dagegen entschieden. Ich weiß nicht mehr im einzelnen, wieso, aber die Entscheidung war sehr klar und fiel seinerzeit zugunsten von TYPO3 aus, das ich seitdem hervorragend bewährt hat. Ich weiß also im Grunde nicht viel über Joomla. Irgendwann habe ich mal beim Multimediatreff in Köln einen Vortrag zur Joomla-Entwicklung gehört, bei dem der (oder die?) Vortragende keinen leichten Stand hatte: Das Publikum war offensichtlich der Meinung, dass Joomla eher zu den weniger ernstzunehmenden Content-Maganement-Systemen gehört; zudem überzeugte auch der Vortrag kaum vom Gegenteil. Auch sonst haben Joomla-Integratoren einen schweren Stand in meiner Peergroup. Genau genommen habe ich nicht eine Empfehlung für Joomla von jemandem gesehen, den ich in Sachen Webentwicklung üblicherweise ernst nehme. Vielleicht ist das Zufall, aber ich kenne auch niemanden, der jemanden kennt, der Joomla einsetzt und dabei – wie auch immer definiert – gut ist.

Wo mir Joomla aber häufig begegnet, ist bei sehr günstigen Angeboten für Webseiten (sowohl Wettbewerb für, als auch zur beratenden Prüfung durch mich). Fast immer sind das 1-Mann-Agenturen, deren Angebote und vor allem deren Auftreten mich nicht von gesteigerter technischer Kompetenz überzeugt. Ganz häufig sind das Quereinsteiger, die sich autodidaktisch irgendwie HTML und CSS angefressen und im Zuge der Joomla-Integration auch ein paar Brocken sehr schlechtes PHP angeeignet haben. Ich möchte das nicht generell kritisieren, jeder fängt mal an und lernt den Kram im Laufe der Zeit irgendwie mehr oder weniger gut. Das Problem ist, dass bei den Leuten, die mir im Joomla-Kontext begegnet sind, das weniger dominiert. Das heißt nicht, dass jeder Joomla-Integrator ein Stümper ist; nur eben, dass er sich in einem Umfeld mit auffällig vielen Stümpern bewegt.

Frage ist: Warum ist das so? Ist Joomla ein schlechtes CMS? Meiner Meinung nach ja, aber das ist wenig objektiv. Aber irgendwas muss doch da dran sein, wenn es so beliebt ist. Module zusammenstöpseln und eine irgendwie lauffähige Seite bekommen, ohne sich groß einarbetien zu müssen, können auch andere Systeme. Was ist es also, was all die Stümper und Anfänger so anzieht? Warum setzt man ein System ein, dessen nach vielen Jahren endlich erscheinende neue Version ungefähr das halbe Featureset von anderen Systemen vor fünf Jahren implementiert? Stichwort Rechtesystem oder tabellenfreier HTML-Output der Core-Funktionen. Weil es so einfach in der Integration ist und man vom Wissensstand her nicht in der Lage ist, ein besseres System einzusetzen? Dann stellt sich aber die Frage: Warum nimmt man Geld für eine Dienstleistung, wenn der eigene Wissensstand gerade mal für das einfachste Werkzeug reicht? Immerhin muss man den Joomla-Integratoren der Kreisliga lassen, dass sie meistens auch nur Kreisliga-Preise aufrufen. Wenn ich aber bei günstigen Nebenberuflern die Wahl habe zwischen einem ambitionierten Studenten und einem Feierabend-Joomla-Bastler, gewinnt der ambitionierte Student. Joomla im Angebot ist für mich ein klar schlechtes Zeichen, das würde ich nicht buchen. Gemeine Vorurteile? Vielleicht, aber auch das ist bei der Wahl eines CMS für Angebote für Geld zu berücksichtigen.

Aber mit der nächsten Version kommen doch endlich alle wichtigen Features… Ja, schön. Schon mal die Planungen für TYPO3 5.0 gesehen? Nein? Weil das noch nicht relevant ist, weil es in ferner Zukunft passiert? Genau. Handfeste Defizite in der aktuellen Version mit Planungen für die Zukunft zu entschuldigen, ist nicht zielführend, weil die anderen sich ebenfalls weiterentwickeln. Während in Villabajo noch mit einem benutzbaren Rechtesystem gekämpft wird, redet man in Villarriba von Aspektorientierter Programmierung, MVC, Content-Repositories und (vielleicht endlich mal praxistauglichem) Frontend-Editing.

Empfehlungen, die ich übrigens über die Jahre immer wieder gehört habe, sind ModX (das als Geheimtipp gilt), TYPO3 (das ich selber häufig nutze), Wordpress (weil alle es nutzen, es ein tolles Backend hat und es so schön nah am Code operiert), Textpattern (das ich vom Konzept her gar nicht mochte, das aber von seinen Fans vehement vertreten wird), Drupal (vor allem im Community-Kontext) und verschiedene kleinere recht charmante Systeme.

Fast immer, wenn ich an Websites arbeite, die andere (Agenturen) verbrochen haben, stolpere ich über mehr oder weniger lästige Eigenheiten der konkreten Implementierung. Dass man TYPO3 auf etliche verschiedene Weisen mit Templates füttern kann, ist ja normal, auch dass es Abweichungen in der Sorgfalt im Umgang mit HTML-Markup und CSS-Code gibt. Aber es gibt Abweichungen im Rahmen des Nachvollziehbaren und solche, die einfach dumm, lästig und ärgerlich sind.

Aktuelles Beispiel: Ich mache zur Zeit einige inhaltliche Änderungen an einer Website, deren CSS-Code sehr eigenartig ist. Die auffälligste Eigenart ist dabei wirklich spaßig: Man hat dem BODY ein text-align: center; gegeben, ohne das bei nächster Gelegenheit, etwa einem Wrapper, wieder zurückzunehmen. Nun könnte einem im weiteren Verlauf auffallen, dass nun alles, aber wirklich alles zentriert wird. Das ist natürlich nicht zu übersehen und vor allem ziemlich lästig. Ich und die meisten anderen Frontend-Entwickler, die ich kenne, würden nun unseren Fehler bemerken und dem Wrapper ein text-align: left; zuweisen, wie es best practice ist. Nicht so der Entwickler dieser Website, denn der gibt der mittleren Content-Box diese Eigenschaft und zudem noch mal allen möglichen anderen Boxen, die nicht zentrieren sollen. Bei der Gelegenheit habe ich mal die style.css geöffnet und staunte nicht schlecht: Fast alle vergebenen Styles sind per ID an verschiedene Content-Boxen drangehängt, so dass beispielsweise eine H2 in Box A gestyled ist, in Box B, C und D und überhaupt anderswo nicht; was wiederum bedeutet, dass sie fast überall zentriert ist (und sonst die Standardeigenschaften des Browsers für H2 hat). Das ist eine Wartungshölle sondergleichen, denn bei jeder Inhaltsänderung, die über den initialen Zustand der Site hinausgeht, muss man den Style anfassen. Letztlich hat man also etwas ähnliches, wie inline-styles, nur eben in eine externe Datei ausgelagert und auf unvorhersehbare Weise mal wirkungsvoll und mal nicht. Die Vorteile der Kaskadierung werden also nicht ausgespielt, die Nachteile aber schon.

Nun wäre es eine Kleinigkeit, das alles zu korrigieren, aber dann schlägt gnadenlos der Nachteil der Kaskadierung zu: Man weiß nicht, welche Seiteneffekte sich bei grundlegenden Änderungen ergeben. Nimmt man etwa die Zentrierung für alles heraus, wird man gar nichts mehr zentriert vorfinden, weil bei absichtlich zentrierten Elementen möglicherweise eine Angabe zur Zentrierung weggelassen wurde, weil sich das ja implizit aus der nicht zurückgestellten Zentrierung des BODYs ergibt. Ohne eine genaue Analyse des Stylesheets und der Seitenstruktur, sowie umfangreiche Tests wird man solche Änderungen also besser nicht machen. Ich halte mich in solchen Fällen einfach an das vorgegebene System und ergänze meine nötigen Styles entsprechend. Das macht es nicht besser, aber wenigstens wird man – ohne daran Schuld zu sein – für jede dieser Änderungen angerufen und bezahlt.

Die ahnungs- oder lustlose CSS-Schluderei ist nur ein Aspekt dieser Website, auch die URLs der Seiten (mit CoolURI gemacht) waren weit entfernt von Sinn und Zweck einer guten URL-Struktur. Die Menüs sind lieblos zusammenkopiert, das Hauptmenü ein manuell erstelltes (und manuell zu pflegendes) Imagemap-Ungetüm, das einen besonders spannenden Nebeneffekt zeigt: Sind Seiten in TYPO3 nicht über zumindest irgendein automatisch erstelltes Menü zu erreichen, kann CoolURI die URL der Seite nicht wissen und wirft eine Fehlerseite. Man muss nun für jede dieser Seiten einen manuellen Eintrag in CoolURI vornehmen und den bei Änderungen auch Pflegen. Besonders lustig ist das, wenn man die URL-Struktur nach umfangreichen Änderungen neu startet und dann das Hauptmenü nicht funktioniert. Falls man eine automatische Sitemap hat, kann die einen immerhin retten. hat man hier aber nicht. Solche Schludrigkeit zieht sich durch das gesamte Projekt und macht erhebliche Mehrarbeit bei der Pflege. Kein Wunder, dass direkt nach Projektabschluss alle Passwörter geändert wurden und die Änderungen bei mir landen. Leider ist das kein Einzelfall, gerade im TYPO3-Kontext treffe ich immer wieder auf haarsträubende Implementierungen. Ob die Agenturen, die immerhin explizit TYPO3 anbieten, zu dumm oder zu faul sind, weiß ich nicht.

Also aufgemerkt: Wenn man jemanden beauftragt, eine Website umzusetzen, gerade bei TYPO3 und anderen komplexen Systemen, achte man auf einen Dienstleister mit Ahnung und Bock. Nur billig billig schnell schnell führt einen zu oft schon mittelfristig aufs Wartungs-Glatteis. Mir ist das recht, wenn ich der Typ bin, der jammern darf und dabei auch noch gut an der Schludrigkeit anderer verdient.

Am Dienstag habe ich dem Fachbereich die Migration unseres alten Testservers Horst (533MHz Celeron mit 768MB RAM und 20GB Festplatte) auf eine neue Maschine (2GHz P4 mit 512MB RAM und 80GB Festplatte) geschenkt. Dieser neue Rechner wurde uns (wie auch der alte übrigens) freundlicherweise vom Admin userer PC-Pools zur Verfügung gestellt, wofür wir ihm sehr dankbar sind.

Parallel zu dieser sowieso geplanten Migration kam die Anfrage unseres Hosters (ein FH-internes Institut am Standort Golzheim), ob wir für einige Zeit unsere Fachbereichs-Seite selber hosten könnten, während uns eine neue Maschine aufgesetzt wird und die alte leider mit einem schleichenden Hardware-Defekt behaftet ist. Irgendwann hört die Liebe zu meinem alten Job auf und so wurde ich für das Einspielen des Backups unserer Fachbereichs-Seite tatsächlich bezahlt.

Was ich aber eigentlich erzählen wollte: Wie Alex schon schrieb, ist das TYPO3-Backend und auch (weniger auffällig) das Frontend auf dem neuen Server viel flinker, obwohl Maschine und Anbindung deutlich schlechter sind als auf dem alten Server. Der Verdacht liegt da nahe, dass man unserer virtuellen Maschine die ganzen zwei Jahre über die Handbremse angezogen hat. Vielen lieben Dank dafür. Meine bescheidene Meinung dazu: Extern hosten.

Manchmal trifft man bei der Webentwicklung auf "kompiliertes JavaScript". Ärgerlich ist das, wenn man dieses dann debuggen muss, aber die Stelle nicht so recht findet.

Beispiel: Der HTMLarea in TYPO3 ist eine System-Extension, die man nicht mal eben (wie andere Extensions) im Extension-Manager updaten kann. Halb so wild: Man kann ja die JS-Datei schnell selber fixen. Gedacht! Nix da, denn die Datei ist kompiliert und besteht aus etwa 10000 Zeichen in einer Zeile. Juhu. Was tun also?

Gibt es keinen Tidy für JavaScript? Doch, klar: http://www.howtocreate.co.uk/tutorials/jsexamples/JSTidy.html. Gute Sache sowas.

Seit Wochen ärgere ich mich über den Rechner hier im Büro. Davon abgesehen, dass er gerne mal einen Bluescreen rausrückt, während ich lange Mails schreibe oder andere zusammenhängende Arbeiten erledige, ist das Backend von Typo3 unendlich träge geworden. Listen kommen zeilenweise herein. Das das nicht immer so war und das Backend bei Alex am Mac nur so fluppt, habe ich mich mal auf die Suche nach dem Schuldigen gemacht: Adblock! Verdammte Scheiße! Das checkt in T3 Backend offenbar jedes einzelne Element durch und bremst damit auf der langsamen Kröte hier das Rendering übelst aus. Also runter damit.

Aber auch so treibt uns Typo3 gerade zur Weißglut. Seit einiger Zeit (heute erst aufgefallen) hängt es an alle Links im Content ein target="_blank" an. Keine Ahnung wieso, er macht, was er will. Und dann ist da noch der Bug im HTMLarea, der mit Firefox 2.0.0.3 nicht mehr lädt. Ich muss Kotzen. Und unser Admin ist nicht erreichbar, um den Patch einzuspielen und Schreibrechte für unsere Typo3 Installation haben wir auch nicht. Manchmal hasse ich das Leben!

Hey, gerade bin ich zufällig über die regelmäßige Typo3-News Recherche auf ein wirklich interessantes Framework gestoßen: YAML - Yet Another Multicolumn Layout. Eine Stabile und flexible Grundlösung für Barrierearme und Cross-Browser kompatible Mehrspaltenlayouts, das einem hilft die üblichen Probleme zu umschiffen und sich voll auf das Design und die Implementierung zu konzentrieren. Genial, wenn ich daran denke, wie man doch immer mal wieder kotzt, weil irgendwas nicht funktioniert, weil man die CSS Untiefen mal wieder nicht im Griff hat. Vorbei.

Ich werde mir das mal anschauen und vielleicht für mein Blog-Redesign nutzen. Das mit dem angedrohten Teppich.