Hab's schon installiert und ausprobiert und muss meine Eindrücke hier gar nicht lang und breit beschreiben, denn das Geschriebene würde sich wahrscheinlich nicht besonders von Guido Mühlwitzs Artikel unterscheiden [übrigens schon ein Jahr alt; weiß gar nicht, wie und warum er vorhin in meinen Browser kam; beschränkt sich aber auch 'nur' auf Drupal aus Benutzersicht und nicht mit irgendwelchen Tiefen und Untiefen der Architektur oder Skalierbarkeitsgedanken, wo ja auch was passiert sein soll], im Gegenteil: meiner würde sogar weniger Aspekte behandeln, weil ich mich noch nicht sooo eingehend damit beschäftigt habe. Mal zwei kleine Oberflächlichkeiten, über die ich mich gefreut habe: Einerseits kann man Module nun ohne FTP aus dem System heraus installieren, wobei es anschließend schon in der Modul-Übersicht Links auf die jeweilige Modul-Konfiguration gibt (wie sehr habe ich diese Links vermisst!) und zwotens:

Mit Drupal 7 rutscht ein Image-Modul in den Core, und der Content kann „von Hause aus“ Bilder verwalten. Die folgenden Module sind nun Core-Module: ImageAPI, ImageField, ImageCache und FileField. [guido-muehlwitz.de]

"Bravo!" ruft derjenige, der sich bisher mit diesen Modulen und ihrer Konfiguration rumgequält hat. "Gääääähn..." wendet sich der Wordpress-(oder Wolke-)Nutzer gelangweilt ab. Drupal hat das Problem, aber halt auch den Vorteil oder kurz: das Konzept, daß es 'offen' bleiben will. Schon mit dieser Art der Bilderverwaltung legt Drupal sich ja auf eine ziemlich undrupalesque Weise fest. Möchte der Nutzer Filmchen einbauen oder einen WYSIWYG-Editor nutzen, so gibt es im Gegensatz zu Wordpress nach wie vor nicht von Haus aus. Ganz in diesem Drupal-Sinne (und im Gegensatz zur Bilderverwaltung) ist beispielsweise das

(...) Blog-API-Modul aus dem Core verbannt worden. Dies wird vor allem Blogger verwundern aber von einem gewissen Standpunkt aus ist das ok: Die Module sind für einen speziellen Einsatz von Drupal (nämlich als Blog) und nicht für Drupal als Ganzes wichtig. [guido-muehlwitz.de]

Sollte sich allerdings dieser Trend:

Wer sich ein wenig auf drupal.org herumtreibt, wird bemerkt haben, dass die Installationsprofile wieder aus der Versenkung aufgetaucht sind. [guido-muehlwitz.de]

fortsetzen, dann könnte Drupal einen sehr guten Kompromiss zwischen 'offen' und 'Benutzerfreundlichkeit für Einsteiger à la Wordpress' hinkriegen. Wär sehr schön, wenn diese Distributionen 'kultiviert' würden. "Aber Drupal ist ja in einem professionellen Umfeld zu Hause, wo sowas nicht sooooo wichtig ist", wird der ein oder andere einwenden. Doch ich entgegne: Wenn man mit 'Webprodukten' auch in diesem Umfeld erfolgreich sein will, so sollte man, wie man bei bspw. bei Wave gesehen hat, für seinen Erfolg trotzdem nicht die Akzeptanz bei der breiten, an der Professionaliät der Ansätze nicht sonderlich interessierten Masse unterschätzen. Und damit sind wir beim nächsten Thema:

The fittest modules should survive?

Erwähnt seien noch zwei große Nachteile (nicht erst seit D7), von denen einer allerdings sogar ein Vorteil für Drupal sein könnte:

1. Updates: Ich hatte vor dem offiziellen Release diese Woche eine RC-Version installiert. Irgendwo hatte ich gehört (ohne dem bisher genauer nachgegangen zu sein), daß man zukünftig, d.h. jetzt mit D7, (Sicherheits-)Updates wenigstens innerhalb einer Version automatisch einspielen kann. Als nun D7 'offiziell' wurde, wollte ich das gleich mal ausprobieren und Drupal meldete:

Manuelles Aktualisieren erforderlich
Eine Aktualisierung der Drupal-Grundfunktionen wird derzeit nicht unterstützt.

Ist schon klar: Einem geschenkten Gaul... aber das ist wirklich etwas ärgerlich und m.E. auch unter Sicherheitsaspekten bzw. des Sicherheitsimages ein richtig doofer Drupal-Nachteil. Die oben erwähnte breite Masse hat keinen Bock auf manuelle Sicherheits- oder sonstige Updates und Drupal bekommt (wie andere Software) ganz schnell den Stempel 'unsicher'. Ganz, ganz oberflächlich übrigens ein Grund weshalb ein Haufen Drupalblogger wieder auf eigene Blogsysteme setzen – ja ja, schon klar: längst nicht nicht der einzige Grund und das hat nix mit Drupal zu tun, kurz: sie hätten es auch dann gemacht, wenn es autom. Updates auch bei Drupal gäbe. Ich hoffe, ein einfaches Update-Management ist immerhin angedacht und wird sich schon mit dem Übergang von 7.0 auf 7.1 ändern (genauer informiert hab ich mich nicht). Immerhin: Bei den Modulen ist es offenbar möglich, hab's allerdings nicht ausprobiert.

2. Abwärtskompatibilität: Wie auch im oben verlinkten Artikel angesprochen: Alles sehr nett mit Drupal 7, aber wenn die es zukünftig nicht hinkriegen, abwärtskompatibel zu sein, dann könnte es für Drupal mittelfristig problematisch werden. Zum Migrieren von Inhalten gibt es wahrscheinlich immer schnell Module, mit denen man das machen kann (wobei man selbst darauf eigentlich überhaupt keinen Bock hat). Aber so groß die Freude sein mag: Drupal 7 ist ernsthaft jetzt noch nicht einsetzbar. Ganz viele Module (als ein Beispiel sei Calendar/Events genannt) sind noch nicht 'hinterherentwickelt', oft noch in der dev- oder alpha-Phase. Da verpufft die Begeisterung, sofern sie denn vorhanden ist, schon wieder etwas. Andererseits könnte dieser Nachteil, wenn sich Drupal mittelfristig hält, langfristig dann auch eine Vorteil sein (ich red mir ja immer alles schön ;): So setzen sich vielleicht nur die 'guten' Module durch und so ein Versionsupdate bereinigt den ziemlich unübersichtlichen Modul-Zoo wieder etwas. Irgendwie ist es schon jetzt ganz befreiend, daß man nicht mehr irgendwelchen 'eingeschlafenen' Drupal-5-Modulen evaluieren muss, von denen man nicht weiß, was man sich mit ihnen aufhalst. Um den Gedanken mal evolutionär zu formulieren: Maybe the fittest modules should survive? Dennoch möchte ich den Nachteil für den Einzelnen gar nicht schönreden: Wer ein umfangreicheres Projekt in Drupal x.y realisiert, kann nur hoffen, daß diese Drupalversion möglichst lange unterstützt wird oder daß die verwendeten Module Drupal-Versionsupdates 'überleben'.

Doch Abwärtskompatibilität hin oder her: Diese Gefahr besteht... nein: Es ist letztlich irgendwie immer klar, daß bei Software, ja überhaupt bei allen digitalen Daten (ja überhaupt bei allen Daten?) irgendwann das Ende der Fahnenstang erreicht ist und man in irgendeiner Form neu anfangen muss; Software ist halt ein Wegwerfprodukt. Weshalb, wie oben erwähnt, viele Leutchen, wenn sie können, heimgehen und auf in ihrer Einfachheit langfristig angelegte, möglichst softwareunabhängige Konzepte setzen und sich auf das beschränken, was sie brauchen anstatt mit Drupal/Wordpress/Joomlakanonen auf Hypertext-Spatzen zu schießen.