Vor einem halben Jahr wurde Drupal in Version 6 (D6) veröffentlicht. Und noch immer lief mein Blog mit D5. Grund dafür, wie bei so vielen anderen Websites: cck.module und views.module mussten erst einmal auf D6 portiert werden.
Nun lagen beide Module als release candidate (RC) vor und wichtige, darauf aufbauende Module brachten einsatzbereite D6-Versionen.

So habe auch ich es versucht, meine Websites auf die “neue” Drupal-Version zu aktualisieren. Nach zügiger Arbeit hatte ich alle Module aktualisiert und auch neu hinzugekommene Abhängigkeiten herausgefunden (z.B. imagefield.module hängt von imageapi.module und filefield.module ab) und Patches eingespielt (textile.module hat wohl keinen Maintainer mehr, wohl aber einen bereitgestellten Patch). Und dann kam der K.O.: imageapi.module und filefield.module benötigen PHP 5.2 als Voraussetzung. Damit werde ich wohl NIE auf D6 wechseln können – wie auch viele andere Leute, die ihre Websites bei ISPs hosten und keinen eigenen Server betreiben. Es ist schon eine tolle Sache, einen Hoster zu finden, der PHP5 unterstützt (meist in Version 5.1.x), aber bis sich 5.2 bei Webhostern durchsetzt, wird wohl auch D7 und D8 freigegeben sein. Tolle Sache!

Der Modul-Autor (den ich bisher für seine Arbeit schätzte) gab einen ziemlich schlappen Grund für die hohen Forderungen an:
It requires 5.2 because I use 5.2. I keep finding bugs on 5.1 hosts I cannot reproduce on 5.2. I choose to only support PHP >= 5.2. You can figure out the nuances of the bugs fixed between 5.1 and 5.2 if you really need to run on 5.1 or you can just try using 5.1 but that is unsupported.

Jedenfalls habe ich an dem Abend ziemlich gefrustet den Aufwand abgeschätzt, meinen Blog auf Wordpress umzustellen. :-/

Und an dem ganzen D6-Dilemma zeigen sich die Grenzen dieser so freizügigen Projektorganisation: Jeder Entwickler kann machen, was er für richtig hält. Drupal hat in der nächsten Version die Features, die die Entwickler einbringen wollen. Dries definiert lediglich Schwerpunkte und Entwicklungsziele. Soweit so gut. Auch finde ich es toll und richtig, dass Drupal – gemeinsam mit anderen PHP-zentrierten Projekten – mittelfristig die Unterstützung von PHP4 abkündigen. Aber so ein heterogenes Projekt wie Drupal sollte für jede Version die Randbedingungen klar definieren, die von allen Contrib-Modulen erfüllt werden sollten. Und bei den Entwicklern dafür werben, dass solch große, umfassende Rewrites wie Views2 von einem Drupal-Update entkoppelt werden. Die probleme beim Umstieg vieler Anwender auf eine neue Version zeigen, dass das Projektmanagement eines solchen Projekts an seine Grenzen kommt und zunehmend unbeherrschbar wird.
Solche “Negativschlagzeilen” braucht Drupal nicht.

Eine Hoffnung gibt es noch: Acquia – die Firma von Dries Buytaert – arbeitet an einer Drupal-Distribution, die neben dem dem drupal-Kern auch so wichtige Module wie CCK, Views und Imagefiled enthält. Und ich bin sicher, dass die PHP-Laufzeitumgebung < 5.2 sein wird. Mal sehen … da werde ich wohl doch noch zum Kaufsoftware-Anwender. Oder ich lerne PHP und “backporte” das die filefield.module und imageapi.module. Oder schaue mir WordPress nochmal an.