Ein Beitrag den ich schon lange Mal schreiben wollte. Eigentlich aber nur, um meinem Frust gegenüber der Entwicklung unter WordPress mal ein wenig Luft zu machen. Die Ironie: Das Blog hier läuft ja ebenfalls unter WordPress (wie viele andere Seiten auch). Nur habe ich sehr wenig selbst entwickelt und das meiste einfach eingekauft und zusammengebaut.
Der Source ist eine Katastrophe. Eigentlich müsste man alles von null anfangen, als eine Art Enterprise-Edition für „Nicht-Bastler“.
global
Keine Funktion ohne global. Das muss so sein! Ansonsten kann man ja nicht entwickeln. Falls etwas fehlt, einfach per global ziehen. Das macht den Code schließlich sehr leserlich und man weiß immer ob und mit was die Variable gefüllt ist. Geniale Idee! Zudem kommen noch tausende globale Funktionen, welche man einfach kreuz und quer nutzen kann.
Eigentlich ganz praktisch. So muss man sich wenigstens Gedanken über Prefixes machen! Ansonsten wäre das Leben ja langweilig und man könnte gar keinen spannenden Seiteneffekte generieren, die niemals jemand nachvollziehen kann.
Man kann alles als Post abbilden
Ein Tabellenplugin? Das ist ein Post! Caching? Einfach als Post! Was strukturiert sein muss, kommt einfach als serialisierter String in die Datenbank, damit man bloß nichts richtig suchen kann. Somit wird UPDATE als SQL-Befehl überflüssig. Vorteil: Man muss nicht so viele Tabellen anlegen. Tabellen sind schlecht. Alles ist ein Post / Post-Type. So kann man die ganze Welt erklären.
Updates, Updates und Updates
Wer eine Extension auf dem Markt anbietet, hat diese binnen einer Woche mindestens zwei Mal zu aktualisieren. Ansonsten gilt diese als inaktiv! Bedeutet: Wenn man zwei Wochen im Urlaub ist, ist die Instanz entweder gehackt, oder man muss 32948 Updates nachholen. Einfach mal alles ein Jahr liegen lassen und nichts tun? Unmöglich.
Aber keine Sorge, in ein paar Tagen kommt schon die neue WordPress-Core-Version raus. Dann wieder 1-2 Zero-Day-Exploits und automatische Patches, aber dann ist alles wieder in Ordnung. Lieber ein Update mehr, als direkt anständigen Source abliefern.
Mehr PlugIns für mehr Sicherheit
WordPress mit vielen PlugIns zu betreiben ist von Haus aus nicht so schlau, da jeder Kobold da draußen denkt, er sei Entwickler. Also gibt es im Netz tausend Beiträge, wie man seine WordPress-Installation sicherer bekommt. Als erstes bitte dies, und dann das PlugIn installieren. Dann noch hier eine .htaccess, hier ein paar Verzeichnis-Berechtigungen umbiegen und am Ende hat man: Sicherheit! Yeah.
Klassenverbot!
Wer eine Klasse unter WordPress definiert, wird wohl gesteinigt (oder so). Im Core sind davon ja nicht so viele zu finden. Statt dessen findet man auch hier nur globale Funktions-Sammlungen. Das wär ja gar nicht so schlimm, wenn man nicht vorher eine ausführen müsste, um eine andere ausführen zu können. Passt auch super zum global-Konzept.
Debugging ist übrigens verboten – oder wird es automatisch. Setzt man einen Breakpoint, bekommt man im aktuellen Kontext so viele Variablen, dass die IDE am liebsten direkt kotzen möchte.
The Loop
Wer sich den Kram ausgedacht hat, der sollte wirklich den Beruf wechseln. Das hat mit Softwaredesign nicht mehr viel zu tun.