Wer ein bisschen erfahrung mit softwäjhr-projekten hat, der weiß das schon: Die funkzjonalität und komplexität einer softwäjhr wäxt so lange, bis die entwickler den überblick verlieren. Danach wäxt nur noch der kohdumfang, weil sich gleichermaßen jene funkzjonen ansammeln, die kein mensch braucht und weil der kohd durch hingestrokelte "work arounds" aufgebläht wird, die die angesammelten probleme nicht beheben können.
Diese fase ist bei WordPress erreicht, und zwar lange schon. Aber mit der veröffentlichung der versjon 2.5 ist es offensichtlich geworden.
Aus einem einst nützlichen stück softwähr zum bloggen ist ein aufgeblähtes monstrum geworden, das gegenwärtig mit 78943 zeilen PHP-kohd und 23766 zeilen javascript (!) daher kommt (mit find und wc gezählt in der deutschen versjon). Von der ursprünglichen idee, ein kleines system zu entwickeln, das mit plackins nach bedarf aufgemotzt werden kann, ist nichts mehr übrig. Zu allem überfluss funkzjoniert die jauche auch nicht richtig. Noch nie konnte man so dankbar sein, dass auch andere blogsysteme aktiv entwickelt werden.
Als wenn das nicht reichte, wurde eine bisherige stärke von WordPress einfach aufgegeben: Die neue benutzerführung ist eine verschlechterung. Wer sich diesen schrotthaufen in der gegenwärtigen versjon installiert, bekommt also jede menge neuer fehler und eine schlechtere benutzerführung. Ich kann jedem blogger nur die empfehlung geben, diese zumutung nicht hinzunehmen und darauf zu drängen, dass die an sich brauchbare softwäjhr WordPress wieder für menschen entwickelt wird.
Welches die neuen fehler sind?
Nun, das folgende sind nur ein paar beispiele für die gegenwärtige seuche in WordPress, da mir vieles wohl gar nicht aufgefallen ist:
WordPress funkzjoniert nicht mit dem opera-brauser: Wer opera verwendet, muss sich jetzt zum bloggen einen anderen brauser suchen, wenn er in seinen beiträgen auch bilder einbetten will oder dateien zum download stellen will. Die ganze AJAX-scheiße, die dafür frisch gehäckt wurde, läuft nicht mit opera. Ich habe es mangels mäck nicht probiert, aber ich möchte wetten, dass es mit einem safari problem geht; schließlich benutzt Matt persönlich ja einen mäckintosch. Und der hat schon geschrieben, dass er über tausend bilder damit hochgeladen hat und dass alles funkzjoniert. Wenn ich in meine statistik schaue, stelle ich fest, dass etwa 10 prozent meiner leser einen opera verwenden, hingegen nur etwas mehr als ein prozent einen safari – das stellt die proporzjonen schon ganz gut dar. Aber man hält es dort nicht für weiter schlimm, eine veröffentlichung zu machen, die für ein gutes zehntel (zumindest der deutschen) webnutzer nicht benutzbar ist.
WordPress gibt unzutreffende HTTP-fehlerkohds aus: Wenn jemand einen kommentar zu einem beitrag schreibt und die felder nicht richtig ausfüllt, gibt WordPress einen HTTP-fehler 500 zurück, einen internen sörver-fehler. Die bedeutung dieses fehlers ist nicht, dass eine benutzereingabe falsch ist und korrigiert werden muss, sondern dass der sörver ein schweres problem hat. Der internet explorer hat dafür eine eigene, "benutzerfreundliche" darstellung und viele proxysörver schreiben hier ebenfalls eine eigene meldung, so dass der anwender nicht einmal mehr den text der fehlermeldung sieht. Der eindruck, der beim kommentieren entsteht, ist nicht, dass man eine falsche eingabe gemacht hat, sondern dass etwas im sörver oder im blog kaputt ist. Da wird wohl kaum jemand einen zweiten versuch machen. Es ist geradezu unfassbar, dass da leute an WordPress herumhäcken, denen die bedeutung der fehlerkohds nicht klar ist. Vielleicht sollten sie sich einfach mal den RFC 2616 durchlesen, der ist nicht so ganz unwichtig, wenn man eine solche anwendung schreibt. Aber nein, der umbau der grafischen gestaltung ist wesentlich wichtiger als eine semantisch korrekte fehlerbehandlung. Schreibt eigentlich microsoft bei WordPress mit?
Der kwalitätsanspruch der aktuellen häcks tendiert gegen null: Ein gutes beispiel dafür sind die plackins, die von den WordPress-Entwicklern selbst erstellt werden. Das spämmerkennungs-plackin "akismet" wurde erst vor ein paar tagen in einer neuen versjon veröffentlicht, bei der die grundfunkzjonen fehlerhaft sind. Angesichts der tatsache, dass spämmschutz für einen heutigen blogger von elementarer wichtigkeit ist, sollte man hier ja eine gewisse kwalität erwarten. Wer der aufforderung aus dem "Dashboard" gefolgt ist, ein aktuelles akismet-plackin zu installieren, hat jetzt bei hohem spämmaufkommen keine schangse mehr, falsch erkannte spämms händisch freizuschalten. Das ist ziemlich arm.
Die groß angekündigten neuen funkzjonen waren zuvor schon als plackins verfügbar: Wir erinnern uns. Als WordPress 2.3 erschien, wurde ganz groß auf die kacke gehauen, dass WordPress jetzt auch "tags" kann. Dafür gab es zwar schon gut entwickelte plackins, die eine komplette verwaltung implementierten, aber das hat die entwickler nicht weiter interessiert, sie haben es von grund auf neu entwickelt. Und zwar schlechter, nämlich ohne die möglichkeit einer "tag"-verwaltung. Aber dafür so, dass die alten plackins nicht mehr funkzjonierten. Wer vorher "tags" verwendet hat (es war eine minderheit), der hatte mit der neuen versjon die schlechtere lösung, wer sie nicht verwendet hat, brauchte die neue funkzjon wohl gar nicht. Deutlicher kann man nicht zeigen, dass man sich keine gedanken über die nutzer macht. Aber wenn man sich ohne jede not unter zeit- und versjonsdruck setzt, denn muss man eben immer wieder melden, welche tollen, neuen beglückungsideen in der neuen versjon verbastelt wurden. Genau das gleiche gilt in der aktuellen versjon für die gravatare, die jetzt vom kern unterstützt werden; auch dafür gab es gute plackins – zumal der kohd dafür wirklich überschaubar ist. Er ist jedenfalls überschaubarer als die änderungen im kernsystem, die immer wieder dazu geführt haben, dass die grundfunkzjonen des blogs fehlerhaft wurden. Mal geht der beitragseditor nicht mehr, und ein anderes mal werden keine mäjhls mehr aus dem blog verschickt.
Dass die deutsche versjon von WordPress mit einem kwelltext ausgeliefert wurde, der einen syntaxfehler enthielt, passt da gut ins bild einer entwicklung, die weder auf kwalität achtet noch dazu bereit ist, vor der veröffentlichung auch nur den einfachsten test zu machen. Denn ein einfacher aufruf der startseite des blogs nach den änderungen hätte gereicht, diesen fehler offenbar zu machen; an stelle des blogs wäre eine nüchterne und recht hässliche fehlermeldung erschienen. Na ja, das können ja ruhig ein paar zehntausend blogger entdecken! Was für eine haltung!
Und diese haltung, sie hat mittlerweile "tradizjon". Schon, als WordPress 2.3 anfing, nach hause zu telefonieren, zeigte sich die inappelable ignoranz der entwickler gegenüber den benutzern. Schon damals war mir klar, dass WordPress durch sehr trübes wasser fahren wird. So langsam fängt es eben an, unangenehm schlammig zu werden, so "hübsch" das neue "Dashboard" auch farbig gestaltet wurde.
Aber muss man nicht appdäjhten wegen der aktuellen angriffe auf WordPress-blogs?
Nein, das muss man nicht. Es kann nämlich sein, dass das nicht hilft.
Denn im moment weiß niemand, wie es den angreifern gelingt, die blogbeiträge mit spämm zu versalzen. Das Problem betrifft eine ganze bandbreite verschiedener versjonen und konfigurazjonen. Kein einziger WordPress-entwickler hat bislang stellung dazu bezogen, das einfallstor für die kräcker beschrieben und angekündigt, dass er eine abhilfe programmiert hat. Das heißt aber nicht, dass man nicht etwas ähnliches geschrieben hätte. Zum beispiel, dass jetzt doch angesichts der angriffe der beste zeitpunkt für einen appdäjht auf die neue versjon sei. Was diesen worten jede glaubwürdigkeit nimmt, ist allerdings die tatsache, dass zu dieser zeit auch und gerade die aktuelle versjon von den angriffen betroffen war. Da sieht man gut, welcher stil der kommunikazjon von einigermaßen "offizieller" seite gepflegt wird, es ist, als würde einem als blogger immer wieder ins gesicht gespuckt.
Ein verheerendes problem, und keine "richtige" stellungnahme auf der offizjellen WordPress-internetzseite. Diese würde ja den hinweis enthalten, dass man eventuell etwas gründlich verbockt hat, dass man mit seinen ehrgeizigen plänen gescheitert ist. Statt dessen schweigen und stimmen aus der zweiten reihe, die schwachsinn erzählen, obwohl sie es eigentlich besser wissen müssten.
Es wird höchste zeit, WordPress wieder den benutzern, den bloggern zurückzugeben! Wer eine so breit verwendete softwäjhr mitprogrammiert, sollte sich schon darüber klar sein, dass dies kein platz für seine spielereien und für das ausprobieren "kuhler" ideen als selbstzweck ist. (Es gibt ja auch eine plackin-schnittstelle dafür.)
Ich denke jetzt schon seit über einer woche darüber nach, ob ich einen fork mache. Was mich abhält, ist vor allem meine gegenwärtige lebenssituazjon; ich bin obdachlos, lebe vom betteln und habe keinen dauerhaft verfügbaren internetz-zugang. Damit erscheint es mir unmöglich, diese aufgabe allein zu wuppen.
Aber ich weiß, was getan werden muss (und auch, wie man es tut, denn ich kann häcken):
- Der gesamte kwelltext von WordPress ist so gut wie undokumentiert. Es ist damit für einen programmierer sehr schwer, einen einstieg in die konzepte zu erhalten. Deshalb ist zunächst der stand (ich würde von 2.3.3 ausgehen) mit kommentaren zu versehen, aus denen sich mit hilfe eines tuhls wie doxygen eine dokumentazjon für programmierer erstellen lässt. Dabei fällt auch gleich eine automatisch erstellte dokumentazjon der "template tags" ab, die für designer eine erleichterung wäre. Denn der jetzige stand im WordPress-codex ist eher als fragmentarisch zu bezeichnen, so dass ich mich beim gestalten immer wieder auf grep zurückgeworfen fühle, um in den kwelltext zu schauen. Wenn man es schafft, diesen bereich unverändert zu lassen, haben auch WordPress-gestalter etwas von der doku, und der fork hat schnell einen guten vorrat bestehender dihseings.
- Die API für den zugriff auf die datenbank gehört verändert. Die verantwortung für das kwoten von variablen muss zentralisiert werden, etwa, indem man platzhalter in einem formatstring mit der abfrage einbettet. Dabei kann auch gleich das jeweilige tabellen-präfix durch einfache textersetzung hinzugefügt werden, so dass nicht mehr für jede abfrage die entsprechende instanz-variable verwendet werden muss. Anschließend müssen die bestehenden 1164 datenbankabfragen des gegenwärtigen kerns in die neue API übertragen werden. Diese änderung führt zu einer inkompatibilität, die aber wiederum dazu führt, dass die verantwortung der abwehr von SQL-injections an einer stelle im kohd liegt. Das wird zu einer größeren sicherheit der gesamten anwendung führen.
- Ein möglichst großer teil der funkzjonalität sollte aus dem kernsystem herausgenommen und in plackins ausgelagert werden, um einem blogger die möglichkeit zu geben, ein sehr schmales system aufzusetzen. Zumal einige dieser funkzjonen definitiv unerwünscht sein können. Sowohl die seit vier jahren fehlerhaften "geschönten" anführungszeichen als auch die automatische vergällung der links mit dem "nofollow"-attribut wird intern über die plackin-schnittstelle eingebunden. In der folge schreibe ich ein plackin, um ein "plackin" des WP-kerns außer kraft zu setzen, das kann es doch wirklich nicht sein. Meiner meinung nach sollte auch der ziemlich fette WYSIWYG-editor opzjonal sein, aber ich weiß, dass man darüber streiten kann.
- Die gesamte gegenwärtige plackin-implementation gehört gesichtet und überarbeitet. Zurzeit habe ich noch keine gute idee, aber die käme mir bei der durchsicht. Dass die gefühlten milljonen fertiger WordPress-plackins eventuell einer anpassung bedürfen, halte ich eher für ein kleineres problem.
- WordPress gehört ein bisschen deAJAXifiziert. An einigen stellen ist AJAX wirklich sinnvoll eingesetzt worden, an anderen stellen stellt es sich nur in den weg. Wer nur einmal versucht hat, seine widgets mit hilfe von opera neu anzuordnen, der weiß, dass hier eine andere schnittstelle besser gewesen wäre. (Es geht, aber wirklich nicht besonders gut.) Das automatische speichern von texten beim schreiben ist hingegen eine prinzipiell gute idee, die beibehalten werden kann.
- Natürlich muss entweder das "tagging" aus WP 2.3.3 in ein plackin verlagert oder die kernfunktion um eine gute möglichkeit zur verwaltung der "tags" ergänzt werden. Ich persönlich wäre für letzteres, da es mir sinnvoll erscheint, das taxonomie-konzept in der datenbank zu belassen und da "tagging" dabei wie von alleine abfällt. Aber ob "tags" in die kernfunkzjonen gehören, das ist eine frage, über die man durchaus nachdenken darf.
- Für mich die wichtigste sache überhaupt: Ich bin nicht der meinung, dass eine anwendung in den brauser gehört, und ich glaube, dass vieles von der "aufgeblähtheit" in WordPress darauf zurückzuführen ist, dass hier eine anwendung im brauser zum laufen gebracht wird. Die immer noch bestehenden inkompatibilitäten der verschiedenen brauser führen hier ein maß an zusätzlicher komplexität ein, das offenbar immer weniger beherrschbar wird. Besser wäre es, eigens für diesen fork von WordPress eine speziell auf die möglichkeiten zugeschnittene desktop-anwendung zu erstellen und sie so zu implementieren, dass es versjonen für alle gängigen betriebssysteme gibt. (Hierzu könnte man wxWindows nehmen, wenn es eine binärversjon werden soll, es kann aber auch gern "nacktes" GTK sein oder vonmiraus auch Java.) Wichtig wäre mir dabei eine vollständige verwaltungsfunktion (einschließlich "tags", benutzerverwaltung und vielleicht sogar ferngesteuerter appdäjht von plackins und kernsystem, letzteres allerdings über ein wirklich ausgereiftes und sicheres protokoll). Die installazjon dieser software muss einfach sein, die performanz auch auf lahmen mühlen befriedigend. (Ich will keine technologische mauer gegenüber bloggern aus armen verhältnissen bauen, weil ich selbst aus armen verhältnissen komme.)
Wenn jemand diese gedanken interessant findet und an einem solchen projekt mitwirken möchte, denn bitte ich um eine kurze mitteilung. Wegen meiner lebensumstände kann es allerdings manchmal etwas länger dauern, bis ich antworte, ich bin nicht regelmäßig onlein.
Auf jeden fall kann ich profezeihen, dass es viele monate dauern wird, den stand von WordPress 2.3.3 zu konsolidieren und frühere schwächen im entwurf zu korrigieren. Aber ich glaube auch, dass da draußen einige menschen sind, die darüber sehr froh sein werden.