Der Umzug ist also vollbracht. Die Wortpresse wurde gegen den Tropfen ausgetauscht und die Farbe glänzt noch feucht an den Wänden.
Eigentlich ein wirrer Entschluss, dieser Umzug. Denn wenn man darüber nachdenkt, habe ich ein auf das Bloggen spezialisiertes System gegen ein mächtigeres Allround-System eingetauscht um… ja, um weiterhin zum größten Teil schlicht zu Bloggen. Aber ich will ja überhaupt schon ein bisschen mehr haben und nutzen, als einfach „nur“ ein Blog. Ohne mich dabei jedoch von dieser Grundform übermäßig weit zu entfernen.
WordPress ist gut, wenn man schlicht bloggen möchte. Auch ist es wunderbar geeignet für Freizeitschrauber wie mich. Man muss kein PHP-/HTML-/CSS-Experte sein, um fix beabsichtigte Modifikationen unterzubringen. Man muss nicht allzu tief im System versinken um relativ schnell individualisieren zu können. Das ist zugleich aber auch das Kreuz an der ganzen WordPress-Sache: Es ist eben ein spezialisiertes System, dass zwar vermehrt CMS-Ansätze bietet, sich aber in dieser Hinsicht im Grunde nicht von seinen Blogwurzeln zu weit entfernen kann.
Inhalte, Inhalte, Inhalte
Was aber, wenn man das Blog erweitern möchte? Wenn man neben den „regulären“ andere Inhalte einschließen möchte? Buchrezensionen, Links, Twitter-ähnliche Kurztexte, was auch immer? Man hätte in WordPress zwei Möglichkeiten: a) man würde sie einfach wie gehabt hinzufügen oder b) sie auslagern, d.h. in eine eigene Datentabelle oder dergleichen. Die erste Möglichkeit wäre – allein der Einheit halber – vorzuziehen. Soweit so gut, aber wo bleibt dann die Trennung? Die klare Definition (und wenn es nur die Definition für sich selbst ist) dieser Inhalte? WordPress kennt genau zwei Inhaltstypen: Blogposts und Seiten. Unterscheiden und Zuordnen kann man diese einzig mittels peripherer Merkmale wie Kategorien und Tags. Das funktioniert zwar und ist sicherlich eine legitime Vorgehensweise, aber letzten Endes doch recht unschön. Weil Umwege für die weitere Trennung dieser Inhalte von den regulären gegangen werden und mitunter Inhaltsformate, für die ein eigener Inhaltstyp idealer wäre, unweigerlich in das WP-Korsett gezwungen werden müssten. Bei Möglichkeit Nummer zwei umginge man im Prinzip das WordPress’sche Dach und würde Inhalte, die eigentlich zur Seite gehören, aus eben dieser auslagern — zwei separate Datensätze mit Inhalten, die doch zum gleichen Gesamtkonstrukt gehören sollten. Unschön.
Drupal hingegen ist auf genau solche Situationen ausgelegt. Inhaltstypen können klar definiert, erweitert und hinzugefügt werden. Man kann Inhalte also „trennen“ und beispielsweise für sich selbst oder den Nutzer individuell definieren, ohne sie mitunter aus dem eigentlichen System notgedrungen lösen zu müssen.
Flexibilität in der Versteinerung
Nun hat aber diese Flexibilität Drupals einen Preis. Einen wirklich, wirklich, wirklich paradoxen Preis. Zum einen läuft bei Drupal alles, aber wirklich alles, unter dem System, wird von Drupal kontrolliert. Einerseits erleichtert das viele Dinge (eigene Alias-Pfade definieren ist in Drupal Zucker, in WordPress ein kleiner Krampf), bringt andererseits jedoch unweigerlich eine Starre mit sich:
Will man in WordPress etwas verändern, beispielsweise die Syntax eines Formulars, eines Postings oder dergleichen, dann muss man lediglich (und in den meisten Fällen) an genau einer Stelle ansetzen, die gewünschten Änderungen vornehmen und schon hat man das gewünschte Ziel erreicht.
Drupal macht es einem mit dem bisweilen mehrfach verschachtelten modularen Aufbau, gerade als WordPress-Umsteiger, nicht ganz so leicht. Will man zum Beispiel das Markup eines Formulars (sagen wir mal, das des Kommentarformulars) gezielt verändern, dann muss man gleich an mehreren Punkten ansetzen: Der eigentliche Formularinhalt. Dieser wird modifiziert, indem man sich per PHP-Funktion (xxxformalter) in die Formulardaten einklinkt bevor sie Drupal ausgibt, sie dort entsprechend den eigenen Wünschen verändert und diese Veränderungen wiederum Drupal zurückgibt, damit es daraus das Formular bastelt. Nun setzt aber Drupal voreingestellt über das Kommentarfeld eine liebliche „Post new comment“-Überschrift. Um diese zu streichen, muss man eine neue Funktion (xxx_box) nutzen und verändern, welche (u.a.) vor der Ausgabe des Kommentarfeldes angewandt wird. Will man umschließendes Markup bearbeiten, gibt es zusätzlich noch diverse Templatedateien, die aber wiederum nichts mit z.B. jener Titelvergabe zu tun haben (obwohl es sich gerade hier anbieten würde, diese zwei Sachen hier zu vereinen) … und so weiter und so weiter. Drupal macht es also demjenigen nicht gerade leicht, der ganz eigene Vorstellungen vom passenden Markup hat oder nicht ständig d’accord mit den Standardausgaben gehen möchte.
Das ist eine Schwachstelle von Drupal. Es ist aus Nutzersicht ein kleines Ärgernis. Drupal bräuchte (will man gerade Neulinge und Umsteiger ansprechen und den Umgang erleichern) einen einheitlichen Layer, eine vereinte Anlaufstelle, um all diese unterschiedlichen modularen Schichten in einem Rutsch ansprechen und gegebnenfalls modifizieren zu können. Hauptaugenmerk und Ziel eines CMS – eines jeden Publikationssystems – muss das namensgebende Publizieren sein. Natürlich kann ich auch nach der Drupalinstallation im Prinzip sofort loslegen und meine Inhalte veröffentlichen. Aber der Weg hin zur Individualisierung des eigenen Systems ist im Gegensatz zu WordPress bei Drupal nicht so geradelinig und beschwerlicher. Eine Art Kompromiss in Form eines oben erwähnten Layers aus drupalschem modularem Aufbau und der wordpress’schen „One-Edit“-Methode wäre wünschenswert.
Daher gilt bei Drupal gerade für Umsteiger „Chaos zu Beginn“. Drupal erschlägt geradezu mit seinen APIs. Im Gegenzug herrscht aufgrund dieser One-Edit-Vorgehensweise bei WordPress – und bei WP ist nun wirklich, das muss man zugeben, vieles nicht Gold, was glänzt – in meinen Augen ständig ein (potentielles) „Chaos immerfort“ vor. Eben weil man soviele Dinge in eine WordPress-Installation reinknüppeln kann, welche zwar mit dem System funktionieren, von diesem aber formal vollkommen losgelöst sind.
Während der Einstieg bei WordPress für den Nutzer gelungen ist, versagt das System dann, wenn man auch nur ein bisschen mehr will und sich dafür tiefer unter die Oberfläche begeben muss. Drupal versagt beim Einstieg, bei der Lernkurve neuer Nutzer, hingegen fast auf ganzer Linie – bietet dafür aber unter der Oberfläche im Vergleich eine solidere Architektur. Nur, wie oben geschrieben, schaut da momentan leider auch nicht alles so goldig aus.
Schreibe einen Kommentar