Mein kleiner 2015er WordPress-Rant
23. Januar 2015
Beginnen wir mit steilen Thesen: WordPress ist schwierig, obwohl es einfach erscheint. WordPress ist für Standardwebsites, obwohl es alle Arten von Websites betreiben kann. WordPress ist eine kurzsichtige CMS-Wahl, obwohl es Weltmarktführer ist.
In letzter Zeit verdichten sich bei Kunden, Kollegen und Freunden die Hinweise, dass es vielleicht doch keine so gute Idee war, komplett auf WordPress zu setzen, als es um die Umsetzung eines neuen Webprojektes ging. Ich will versuchen zu erklären, warum das so ist.
Seit zehn Jahren ist WordPress nun dabei, sich von einer kleinen Bloggingsoftware zum weltweit meistgenutzten Website-Baukasten zu entwickeln. Diese Entwicklung ist weitestgehend abgeschlossen, auch wenn noch viel Legacy-Code und eine ganze Reihe von Paradigmen an die gute alte Blogging-Zeit erinnert. Alle Funktionen, die WordPress zu einem „großen“ CMS machten, stecken allerdings in Themes und Plugins. Grundsätzlich ist natürlich gegen einen relativ schlanken Core und relativ mächtige Plugins nichts einzuwenden. Das fundamentale Problem ist jedoch die verfluchte Vielfalt und die Konkurrenz innerhalb der Plugin-Szene. Ich habe aufgehört zu zählen, wieviele Plugins es für die Verwaltung von Custom Post Types und Custom Fields gibt. Derzeit scheinen CTP UI und ACF brauchbare Plugins zu sein, aber wer weiß schon, wann diese wieder explodieren oder neue WP-Versionen nicht mehr unterstützen? Ihr wisst, was ich meine. Man kann ja froh sein, dass WordPress mit den Schnittstellen für Custom Post Types, Custom Fields und Custom Taxonomies eine Art Standard innerhalb des System geschaffen hat, doch dieser Standard ist so rudimentär, dass alle entsprechenden Plugins trotzdem zusätzliche Schichten an Logik und Daten ablegen müssen, um halbwegs benutzerfreundlich zu sein.
Natürlich besteht bei allen CMSen das Problem, dass zu viel festgelegte Funktionalität im Core schädlich ist, und dass man auf Plugins angewiesen ist. Doch in den meisten Fällen existieren für die wichtigsten und am häufigsten benötigten Anwendungsfälle auch gewisse „große“ Standardplugins, welche eine hohe Qualität aufweisen, oftmals auch vom Core-Team entwickelt werden und von daher zu allem kompatibel sind, und auf jeden Fall weiterentwickelt werden, wenn sie nicht – wie im Falle von Drupal – schlussendlich in den Core wandern. Eine gewisse Standardisierung der Core-Schnittstellen schafft Verlässlichkeit und Orientierung bei den Plugin-Entwicklern und Vertrauen bei den Benutzern, weil die Wahrscheinlichkeit, dass Plugin A mit Plugin B gut zusammenarbeitet, hoch ist.
Bei WordPress hat sich dieses Kompatibilitätsproblem zu einem absurden Schauspiel entwickelt. Plugins machen damit Werbung, dass sie zu bestimmten, populären Themes kompatibel sind, Plugin A setzt Plugin B voraus, aber warnt davor, Plugin C gleichzeitig installiert zu haben. Magazin-Themes empfehlen den Einsatz eines bestimmten Plugins, weil sonst bestimmte Features nicht funktionieren würden, kommen aber selbst mit 3 Tonnen Plugin-ähnlichem Code daher, so dass inzwischen die Unterscheidung zwischen Theme und Plugin kaum mehr gegeben ist. Es ist ein Dschungel.
Und weil sowohl Themes als auch Plugins so pupseinfach zu installieren ist, macht es jeder Amateur ohne Hemmungen, und kombiniert munter Dinge, die sich überkreuzen und gegenseitig kaputt machen. Ansprüche an das Design, die Ladezeiten, ein elegantes Markup oder zumindest halbwegs aufgeräumten Code sind dabei schon lange nicht mehr vorhanden.
WordPress also nur ein populäres Amateur-System? Ja und nein. Inzwischen bin ich der Meinung, dass es genau zwei verschiedene, valide Anwendungsfälle gibt:
1. Die reine Laiennutzung: Fertiges Theme installieren und mit Bordmitteln anpassen, einige Plugins dazu klicken, die nicht allzu krasse Dinge anstellen, fertig. Bei dieser Nutzungsart ist es sehr wichtig, dass man keine zu hohen Ansprüche hat, was einerseits die Ästhetik, andererseits die Machbarkeit bestimmter Funktionen angeht. Wer individuelle Wünsche hat, die über das normale Standardblog oder die kleine Standardwebsite hinausgehen, findet entweder ein Plugin, welches sofort perfekt passt, oder lässt es sein.
2. Die reine Profinutzung: Ein eigenes Theme wird von Grund auf neu aufgebaut. Jedes Plugin wird sorgfältig auf Professionalität, Langlebigkeit, Stabilität und Kompatibilität geprüft. Im Zweifel lieber selber im Theme die gewünschte Funktionalität programmieren. Jeder Wunsch nach individuellen Funktionen wird zweimal in Frage gestellt und dem Kunden möglichst ausgeredet. Das Versprechen einer funktionierende Website erlischt, sobald Kunden eigenständig Plugins installieren (Ja, damit sind vor allem SEO- und Social-Media-Button-Plugins gemeint!).
Zwischen diesen Extremen gibt es nicht viel. Wir haben sehr schlechte Erfahrungen gemacht mit dem Anpassen von fertigen Themes, trotz Childtheme-Technik, insbesondere bei responsiven Themes. Die Möglichkeit, „schnell mal eben“ gigantische Funktionsumfänge in Form von praktischen Plugins herbeizuzaubern, ist verführerisch, doch zu welchem Preis? Die Kunden wollen immer mehr von der Sorte, werden falsch erzogen!
Ach, wenn das so einfach ist mit den eigenen Widget-Bereichen, dann will ich gleich sechs Stück haben. Wissen Sie was? Ich installier mir einfach ein Plugin und knall mir gleich 14 Widgetbereiche rein!
Es ist diese verführerische Illusion, dass alles so einfach ist. Die Themes, Plugins und Widgets greifen doch alle ineinander, ergänzen sich, lassen sich sogar anpassen, und alles ohne Code! Was muss dann erst eine richtige, erfahrene Webagentur aus dem System herausholen können? Doch leider arbeiten erfahrene Webagenturen meist ein bisschen anders, verlassen sich ungern auf Baukastenmodule mit unbekanntem Code und wollen alles unter Kontrolle haben beziehungsweise auf eine stabile CMS-Codebasis setzen, deren Paradigmen und Schnittstellen gut dokumentiert und zukunftsicher sind. Nur so kann man Webprojekte umsetzen, die mit den Wünschen der Kunden mitwachsen, ohne irgendwann die Grätsche zu machen.
Uns fällt es immer schwerer, im vollen Bewusstsein neue Projekte mit WordPress anzufangen. Zu oft ahnen wir, dass die Kunden immer mehr wollen, wenn sie einmal das Schaufenster mit den Süßigkeiten gesehen haben, oder dass sie mit den besprochenen, minimalem Anpassungen an das Standard-Theme nicht zufrieden sind. Doch ganz ehrlich: Meist sind es wir selber, die keine Lust auf den Stress haben, die ganze Arbeit von Anwendungsfall 2 für das Budget aus Anwendungfall 1 zu erledigen.