auch schlafen ist eine form der kritik

WordPress 2.9 – ein objektiver Rant

Über ein halbes Jahr setze ich hier für meinen Kritzelkram inzwischen Drupal ein. Dieser Tage erschien vom zuvor eingesetzten WordPress die Version 2.9 – zwei Versionen nach unserer Trennung. Da wollte ich doch mal sehen, wie es inzwischen im Hause der Wortdruckerei weitergegangen ist.

Zu der, unter anderem für die Trennung verantwortlichen, WordPress-Featuritis gesellen sich folgende – vermeintlich größere – Listenpunkte hinzu:

  • Papierkorb
  • Artikelbilder (”post thumbnails”)
  • „oEmbed“
  • Bildbearbeitung
  • Plugin-Massenaktualisierung
  • „Custom Post Types“-API

Im Einzelnen…

Papierkorb

Nun. Der Papierkorb erklärt sich von selbst. Zumindest gilt das für seine Funktionsweise. Mir ist nicht so klar, warum man so ein oberflächliches Feature einführen muss, wo es in WordPress doch wahrlich größere Baustellen gibt, aber gut. Ich gehöre dann wohl nicht zur mehrheitlichen Basis an CMS-Nutzern, die mit ihren potentiellen Inhalten anscheinend so gedankenverloren umgeht, dass eine Undo-Funktion nötig scheint. Geschenkt. Witzig ist hingegen ein Punkt, mit dem Matt im WP-Dev-Blog dieses Feature anpreist: „This also eliminates those annoying ‚are you sure‘ messages we used to have on every delete.“ Ja, genau…

„oEmbed“

„oEmbed“ ist im Prinzip ein nettes Feature. Will man Inhalte unterstützter Seiten (YouTube, flickr und Co. ohnehin, ansonsten alle, die es integriert haben) in die eigenen Artikel einbetten, reicht einzig die auf sie zeigende URL. Da es nichts am Markup modifiziert (es eventuell gar valide macht) und schlicht den embed-Code der jeweiligen Seiten in den Artikel pumpt, ist der Nutzen in der Tat lediglich bequemer Natur. Die Funktion kann in den Einstellung ein- und abgeschaltet werden. Immerhin. Nebenbei: Dass ich die entsprechende Option zuerst nicht finden konnte, mag vielleicht an der (zumindest für mich) dezent lustig-verwirrenden Übersetzung liegen — „Autoanhänge“. Ge-nau.

Bildbearbeitung

Die Bildbearbeitung. Hm. Das Teil ist im Prinzip gut integriert, schaut nicht schlecht aus und ist mitunter für sehr, sehr, sehr kleine Bildarbeiten nützlich. Aber es symbolisiert gleichzeitig für mich die Eigenschaften, die mich an WordPress angewidert haben. Man geht bei den WP-Entwicklern scheinbar nur vom DAU aus. Grundsätzlich. Die Bildbearbeitung-Light ist dann im Prinzip auch nur für solche Leute nützlich, die womöglich das Login in den Adminbereich gerade so hinbekommen. Ich sehe schon, wie die auf wordpress.com gehosteten Blogbetreiber 5MB große Bilder hochladen und bearbeiten wollen, an dem Upload-Limit scheitern und sich beschweren werden. I tell you… Und ja, natürlich ist das Teil der wordpress-s-s-…-schen Philosophie – ein System für die Masse – und legitim, gerade vor dem Hintergrund der Multimedialität. Aber dass soetwas schlicht und ergreifend in den Core gepackt wird, spricht Bände. Man bekommt die Nutzer, die man sich heranzieht.

Custom Post Types

Na, endlich haben sie auch bei WordPress realisiert, dass |node types| pardon post types eine dufte Sache sein können. Die bisherigen Typen (attachement, post, page, revision – wenn mich nicht alles täuscht) können nun durch weitere ergänzt und verfeinert werden. Was lange währt, wird… Einziger Wermutstropfen: Das ist zur Zeit nur für Plugin-Autoren interessant. Soweit ich es sehe, gibt es für den Endnutzer keinerlei Möglichkeiten, aus dem Admin-CP heraus Posttypen zu definieren oder zu verwalten. Soll wohl anscheinend frühesten mit der 3.0’er kommen. Ach, WP…

„post thumbnails“

Teaserbilder. Jup. Von Haus aus unterstützt? Natürlich, beschreiben es die WP-Jungs. So ganz stimmt das leider nicht. Um das „Feature“ auch tatsächlich zu Gesicht zu bekommen, muss eine Zeile Code in der functions.php manuell untergebracht und zudem ein entsprechendes Tag im Template gesetzt werden. Hey, letzteres geht vollkommen in Ordnung – irgendwo muss schließlich angegeben sein, wo die Bilder zu erscheinen haben. Aber wer, wer, wer?! hat sich den Dreck mit der functions.php ersponnen und warum haben die WP-Jungs das zumindest nicht bereits im Standard-Theme integriert? Davon würde ich als Nutzer doch ausgehen. So sucht man sich die Finger wund, wenn einem dieser Umstand nicht bewusst ist. Und überhaupt: Wer hatte denn die grandiose Idee, den entsprechenden Punkt zur Teaserbild-Definition im Write-Panel erst erscheinen zu lassen, wenn eben jene Zeile in der funtions.php steht? Das ist in meinen Augen ein Usability-Disaster, welches wohl vor Urzeiten mal einen logischen Ausgangspunkt hatte, von der Realität widerlegt worden ist und trotzdem beibehalten wurde. Entweder ich nutze Teaserbilder oder ich nutze sie nicht. Warum das Erscheinen des kleinen Link im Write-Panel von einer redundanten Codezeile abhängig machen? Featuritis mit Optionsverstopfung. Herje.

Und… sonst so?

Die ganzen kleineren Fixes und Integrationen kann man getrost beiseite legen, außer die eine. Ich verstehe nicht, warum sie die in den Ankündigungen lediglich nebenbei und als eine von vielen erwähnen.

A new commentmeta table that allows arbitrary key/value pairs to be attached to comments, just like posts, so you can now expand greatly what you can do in the comment framework.

WP-Dev-Blog

Na, hallo. Da springen sie jetzt aber allmählich doch auf den semantischen Meta-Zug auf. Witzig, genau dass hatte ich erst vor kurzem in Witzelsucht gefordert. Während das jedoch in der kommenden 7’er Ausgabe von Drupal schon Realität ist (wie man überhaupt mit dem CCK alles wird vermetaisieren können), beschränken die WP-Jungs das aber ebenso wie die post types erstmal nur auf eine API. Der Endnutzer darf noch warten.

WordPress wird immer mehr zur Schwertklinge. Zweischneidig. Denn einerseits zeichnen sich Entwicklungen ab, die man nur begrüßen kann – als da wären die gefühlte Zuwendung zu einem – zumindest in Ansätzen – besseren Grundgerüst für Meta-Angaben bzw. semantische Angaben. Die Posttypen waren und sind längst überfällig gewesen, die Metaangaben für Kommentare schlagen in die gleiche Kerbe und vielleicht sieht man über kurz oder lang noch eine Überarbeitung des Taxonomy-Gerüsts. Let’s hope.

Auf der anderen Seite steht jedoch die nach wie vor auf mich geradezu obszön wirkende Featuritis der Entwickler. Es ist, als ob sie ihrem Grundgerüst beständig zurufen (pardon my french): „Fick dich doch ins Knie, wir bauen lieber neue Sachen ein und auf dich drauf“. Natürlich – wie schon oben erwähnt – WordPress muss da als populäre Plattform schizophren sein, aber der Idealist in mir ist trotzdem der Überzeugung, dass man ein gutes; ein rundes und stabiles, ein formell sauberes System basteln kann, welches den diversen Anspruchsebenen genügen könnte – wenn man denn nur will. Wie hier schon einmal erwähnt, könnten die WP-Jungs sich einiges bei Drupal abschauen – sie sollten zum Beispiel mal für ein halbes oder ganzes Jahr rufen (pardon my french, again): „Fickt euch, regelmäßige Updates. Ihr musst jetzt einfach warten.“ Und es wäre toll, wenn sie sich zumindest für diesen Zeitraum eine „Abwärtskompatibilität ist für Weicheier“-Mentalität zulegen würden, um das System auf Vordermann zu bringen. Und wenn ich sage, dass sich beide System – Drupal und WordPress – voneinander einiges abschauen sollten, dann ist das kein Alibi. Drupal weiß, dass es ganz arge Usability-Probleme hat – gerade für Einsteiger. Die kommende 7’er Version schaut in der Hinsicht wie ein Fortschritt aus und zumindest ich kann mich des Eindrucks nicht wehren, dass die Drupal-Jungs da u.a. bestimmt hin und wieder zur WordPress-Oberfläche geschielt haben. Jetzt müssten die WordPress-Mannen es ihnen, auf längere Sicht gesehen, gleichtun. Die Welt der (Blog-)CMSe würde es ihnen danken.


4 Antworten

  1. Dies war schon immer WP’s größtes Problem, seine zu große Nutzerzahl und somit der fehlende Fokus der Entwickler. Man muss für die weniger blogafine Mutti, genauso wie für den Command-Line-Linux-Nerd entwickeln. Beide möchten völlig unterschiedliche Dinge von WordPress und so geht es auf vielen Schienen langsam voran, statt auf einer im schnellen Tempo. Jedes so offene und populäre Produkt bzw. Service leidet unter den gleichen Symptomen.

  2. ben_

    Fasznierende Entwicklung. Was mich aber selbst bei den „guten“ Sachen ja immer noch schaudern läßt, ist der Gedanke an den Quelltext. Das letzte Mal, dass ich mir WordPress im Quelltextangesehen habe (und das war Sonntagmorgen bei der Updatestarthilfe auf 2.9 eines befreundeten Bloggers) war das immer noch das gleiche Grauen wie eh und je. Die Vorstellung, dass ich diese Grauen immer weiter fortsetzt und vermehrt … erfüllt mich mit Grauen.

  3. Quelltextmäßig tuen sich beide Systeme nix. Ich kann mich nicht recht entscheiden welches ich gruseliger finde. Beides Code aus Mama Pastas Spaghetti Hölle, kann man finde ich echt nciht anders sagen.

  4. ben_

    Sven, ich weiß ja, dass Du ein großer Drupalskeptiker bist. Und nach allem, was ich von Dir gelernt habe, muss ich Dir in gewisser Weise ja sogar zustimmen. Die wahre Lehre ist das alles nicht. Aber Sven … WordPress, Sven, WORDPRESS!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert