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.

Zur Zeit arbeite ich an einem Wordpress-Projekt und bin nach der Umstellung auf PHP 5.3 (vorher war versehentlich PHP 4 auf dem Webspace aktiv) über etliche Deprecated-Warnungen gestolpert. Die explizite Zuweisung von Objekten per Referenz (also mit =& statt dass das Objekt mit = geklont wird) in der wp-settings.php ist schuld, denn dieses im Grunde erwartungskonforme Verhalten ist seit PHP 5 der Normalfall, Objekte werden jetzt nur noch geklont, wenn man explizit clone benutzt, so dass die explizite Zuweisung per Referenz überflüssig ist und angemahnt wird.

Nun ist es bei einem guten Hoster ein Handgriff ein, die E_DEPRECATED-Warnungen in der php.ini zu unterdrücken, von daher ist das alles halb so wild. Die Sache ist aber ein Symptom eines großen Dilemmas: Will man – aus welchen Gründen auch immer – kompatibel zu PHP 4 bleiben, muss man manchmal Code schreiben, der in PHP ab 5.3 eine Deprecated-Warnung wirft. Das TYPO3-Backend beispielsweise warf bis vor kurzem (vielleicht auch immer noch) ebenfalls Unmengen an Deprecated-Warnungen, weil es intensiven Gebrauch von eregi-Funktionen macht. Die kann man mit gutem Geschwindigkeitsgewinn und ohne Schwierigkeiten mit PHP 4 gegen preg-Funktionen austauschen, hier ist es also lediglich eine Sache von Fleiß; ganz davon abgesehen, dass TYPO3 sowieso seit Jahren kein PHP 4 mehr unterstützt. Die Sache bei Wordpress und einigen anderen Projekten mit Objektorientierten Elementen ist aber eine Zwickmühle.

Wobei es in meinen Augen keineswegs eine Zwickmühle ist, da die Lösung auf der Hand liegt: Man wirft einfach den PHP 4 Support über Bord und hält die Anfeindungen einiger Ewiggestriger aus, die nicht wissen, wie sie bei ihren Webspace eine aktuelle PHP-Version umstellt. Diese Anfeindungen kommen leider vor, und sind einer der Gründe, wieso ich zu Serendipity keinen Code mehr beitrage. Serendipity bewahrt wie Wordpress noch immer die PHP 4 Kompatibilität und steht einer zukunftsgerichteten Weiterentwicklung damit massiv im Weg. Wordpress wird wohl ab Version 3.0 (also ab demnächst) PHP 5 vorraussetzen, damit es endlich nach vorne gehen kann. Das ist im Falle von Wordpress auch bitter nötig, wenn man sich den mitunter grauenerregenden Code anguckt. Die aktuelle Beta 1 wirft aber leider immer noch die Deprecated-Warnungen.

Es gibt so etwas wie Codehygiene. Ich frage mich, wieso sich so viele Softwareprojekte mit aller Macht dagegen stemmen, ihren Code ein wenig zu warten. Eregi-Funktionen gelten schon seit mindestens fünf Jahren als um Größenordnungen langsamer, als ihre preg-Pendants. Wieso zur Hölle liest man dann als Abhilfe für Deprecated-Meldungen immer und überall, dass man die Warnungen ausschalten soll? Wo ist das Problem, sich einmal eine Nacht hinzusetzen und die veralteten und langsamen eregi-Funktionen zu eliminieren? Wieso wird unter Verzicht auf fundamental wichtige Programmiertechniken der Objektorientierung auch mehrere Jahre nach Einstellung des Supports für PHP 4 so sehr daran geklebt? PHP 4 ist veraltet, langsam und behindert massivst eine saubere Programmierung. Das ist sogar so offensichtlich, dass es jedem auffallen müsste, der nur ansatzweise objektorientiert mit PHP programmiert. PHP 4 fehlt es an fundamentalen Funktionalitäten an allen Ecken und Enden, nicht nur bei der Objektorientierung. Bitte, hört auf mit der falsch verstandenen Rückwärtskompatibilität und blickt mal nach vorne.

P.S. Ich bin übrigens latent auf der Suche nach einem neuen Blogsystem. Serendipity möchte ich den Rücken kehren, weil sich an der Front scheinbar nichts mehr tun wird. Auf PHP 5 umstellen? Neue Programmierkonzepte zulassen? Nix da, alles bleibt, wie es ist. Ein System, dessen Core so ungerne angefasst wird, ist nicht meins. Davon abgesehen, dass der Core in meinen Augen sowieso gar kein HTML ausgeben sollte. S9Y ist super stabil und funktioniert bei mir seit nunmehr fast sechs Jahren ohne jedes nennenswerte Problem vor sich hin, aber in etwa so lange hat sich auch nicht mehr wirklich etwas nennenswertes weiter entwickelt; das stimmt zwar nicht ganz, aber die Änderungen blieben insgesamt doch sehr dezent. Wordpress ist leider keine Alternative, auch wenn das Backend großartig ist. Ein Blick in den Core an beliebiger Stelle sollte ausreichend Anlass geben, das System nicht zu wollen. Was ist eigentlich aus Habari geworden?

Heute musste ich in einem Wordpress-Eintrag ein kleines jQuery Script einbauen, wofür ich erst mal ein DIV an den BODY anhängen musste. Im Grunde macht man sowas in jQuery mit folgendem Code:

<script>
  jQuery('<div id="soundso" class="undsoso"></div>').appendTo('body');
</script>

Leider fährt einem Wordpress hier an die Karre, wenn man das in den Post-Editor einfügt (davon abgesehen, dass sowieso alles kaputt ist, wenn man den WYSIWTFWYSIWYG-Editor benutzt). Die Automatik, die Ps um die Absätze macht, grätscht hier rein und fummelt da irgendwie noch ein p mit rein, wo es einem einen JavaScript-Fehler einbringt. Eine andere Weise, dieses DIV zu erzeugen, scheiterte an anderen Randbedingungen oder wäre sehr unelegant gewesen, deswegen musste ich das irgendwie hinbekommen. Da Wordpress normalen JavaScript-Code in Frieden lässt, habe ich letztlich auf die Standard-JavaScript-Methode zurückgegriffen, wie man DOM-Elemente erzeugt. Das sieht dann so aus:

<script>
  var d = document.createElement('div');
  d.id = 'soundso';
  d.className = 'undsoso';
  document.body.appendChild(d);
</script>

Wenn man es so macht, lässt Wordpress den Code passieren, ohne daran wohlmeinend herumzufummeln. Eine andere Möglichkeit ist das PlugIn Text Control, das auf Pro-Post-Basis die Textformatierungen abschalten kann. Das Plugin scheint auf den ersten Blick trotz des Alters (es ist von 2005) mit einem aktuellen Wordpress zu funktionieren, aber leider bietet es seine Dienste nur für Posts an und nicht für statische Seiten.

Nachtrag 06.05.2010: Man kann auch einfach radikal wie wpautop-Funktion deaktivieren, etwa mit diesem PlugIn. Das automatische rein pfriemeln von Absätzen ist nett gemeint, aber es schadet in der Praxis mehr, als es nützt; zumindest in meiner Praxis.