Vor etwas über einem Jahr habe ich einen Artikel geschrieben, warum ich mich für Drupal und gegen WordPress entschieden habe. Mittlerweile habe ich die Entscheidung bereut und bin auf WordPress umgeschwenkt, nachdem ich alle meine Inhalte, die in Drupal gespeichert waren, manuell in WordPress übergeführt habe. Die Entfremdung von Drupal war ein schleichender Prozess, hier die einzelnen Gründe:

1. Merkwürdigkeiten und Bugs

Von Anfang an sind mir so einige Merkwürdigkeiten bei Drupal aufgefallen, die ich teilweise umschiffen konnte, teilweise akzeptieren musste:

• Die Einbindung von Bildern in Artikel ist eigenwillig, ganz besonders wenn die Bilder verkleinert werden und per Mausklick dann in Originalgröße dargestellt werden sollen – die einfachste Möglichkeit dafür war ein Ausgabefilter: Das Bild in seiner ganzen Größe im WYSIWYG-Editor einbinden, dann über die Bildeigenschaften im Abschnitt „Style“ die gewünschte Größe  mit width und height angeben (und an die Proportionen natürlich vorher denken). Dann wird automatisch ein entsprechendes Vorschaubild in der gewünschten Größe generiert und eingebunden. Ist so umständlich wie es klingt und hat zwei Nachteile:
  1. Zum einen sieht man im WYSIWYG-Editor zunächst nicht, wie der Artikel aussehen wird – erst nachdem der Artikel gespeichert und die verkleinerte Fassung gespeichert wurde, was direkt zum 2. Punkt führt:
  2. Drupal führt kein Buch darüber, welche (Vorschau-)bilder in welchem Artikel verwendet werden. Wenn durch Trial&Error endlich die gewünschte Größe des Vorschaubildes ermittelt wurde, bleiben die ganzen anderen generierten Versionen des Bildes (z.B. in 320×200, 480×240, was auch immer) gespeichert und vermüllen so die Verzeichnisse.
• Das Kategoriemenü („Taxonomy“)  in Kombination mit dem Mehrsprachigkeitsmodul war einige Zeit sehr buggy: so wurden auf Deutsch auch englische Kategorien eingeblendet (und umgekehrt) und es war damit fast unbrauchbar. Das hat sich irgendwann durch ein Update behoben.

2. Performance

Mit jedem installiertem Modul schien die Performance massiv abzunehmen – und es dauerte teilweise elendig lange bis man zwischen den Administrationsebenen hin- und hergeschaltet hat. Um das Problem zu beheben, sollte man den PHP-Beschleuniger APC einschalten, was für mich zu eher disaströsen Ergebnissen geführt hat: Die Seite funktionierte nämlich nur eine gewisse Zeit lang, danach musste der Apache neugestartet werden! Nach Deaktivierung des APCs in Drupal lief alles wieder korrekt, aber gewohnt träge.

3. Updates & Module

Das war schließlich der Tropfen, der das Fass zum Überlaufen gebracht hat. Updates un die Installation von Modulen unter Drupal waren immer schon ein wenig heikel – zum Teil reichte die Installation eines Moduls nicht aus, es musste noch manuell Dateien/Bibliotheken ins Dateisystem kopiert werden, aber das hier toppte alles bisher erlebte – der Versuch, das OpenLayers-Modul zu aktualisieren:

In der neueren Version gab es plötzlich eine Abhängigkeit zu einem weiteren Modul (Proj4JS), das natürlich nicht beim Update installiert wurde. OK, auch installiert. Danach – und dem Reaktivieren des Modules – war die Seite nicht mehr erreichbar, Fehler 500!

Es stellte sich dann heraus, dass besagtes OpenLayers-Modul nämlich auch noch eine neuere Version (2.1 statt installiert 1) einer installierten Library erwartete und ansonsten die ganze Seite in den Abgrund gerissen hat (und nicht nur die Artikel, wo entsprechender OpenLayer-Inhalt vorhanden ist). 😡 Die Aktualisierung besagter Library war natürlich nicht ganz so einfach – weil die Administrationsoberfläche, über die Module verwaltet wurden, auch nicht erreichbar war! 👿  Nach einer manuellen Installation (auf Dateiebene) ging die Webseite teilweise wieder.

Schließlich hatte ich die Nase voll, habe mittels Einspielen eines Backups (Es zahlt sich aus, alle 4 Stunden mit rsnapshot und mylvmbackup Backups zu erstellen 😀 ) den Status vor dem Einspielen des missratenen Updates hergestellt und den Entschluss gefasst, von Drupal zu WordPress zu migrieren.

Achja… es handelte sich um ein Riesenversionssprung bei dem Update, nämlich von 2.0-beta3 auf 2.0-beta5, bei so einem Quantensprung ist natürlich mit solchen Problemen zu rechnen 😈

Fazit

Meiner Erfahrung nach – nach Installation von WordPress, den entsprechenden Modulen von WP, usw – ist Drupal weit fragiler, benutzer- und administrationsunfreundlicher und resourcenfressender als WordPress. Das Problem des kürzlich erfolgten Angriffs auf WordPressinstalltion habe ich auf meine Art gelöst, dazu später etwas dazu.