Allerdings können solche Vorgehensweise auch zu strukturellen Problemen führen. Zum Beispiel, dass die letzten Haupt-Releases von merklich schlechterer Qualität sind. Auch hatte das vorher mit dem “Aktuell halten” nicht mehr geklappt, da viele User Angst davor hatten, ihre Site würde nach dem Update nicht mehr funktionieren (Plugins, Themes). Da hat dann das Projekt allen mal Angst gemacht sie könnten gehackt werden und die User haben in Scharen geupdated – mit dem entsprechenden Chaos.

Ich habe zu wenig Erfahrung in Projekten solcher Grösse um sagen zu können wie Strukturprobleme dann rein faktisch ein Projekt behindern. Was man merkt ist, dass die Entwicklung mitlerweile wesentlich langsamer voranschreitet als noch vor einem Jahr. Viele Dinge bleiben unerledigt (Offene Tickets in WordPress Trac) und es gibt immer mehr frutstrierte Entwickler im Projekt.

Und diese Speicherfreigabe ist default und nicht von mir beabsichtig minimal gehalten. Und ich bin mir ziemlich sicher, dass bei vielen shared hosting Paketen der memory_limit so klein ist.

Ansonsten schließe ich mich Don an. Dogmatisches “Nur OOP bringts” ist nicht die Lösung. “Etwas hinrotzen” ist _nicht_ “der PHP Weg”, sondern höchstens der Weg der entsprechenden Entwickler. Man verurteilt kein Paradigma, indem man nur Beispiele liefert.

Ein ganz wesentlicher Faktor meiner Ansicht nach: Bei “ordentlicher” Software muss man als entwickler erstmal die Architektur lernen um was beitragen zu können – und wehe die Architektur sieht die eigene Änderung nicht vor. Bei einer un-Architektur hackt man da eher mal krum rein um schnell nen Erfolg zu haben und gibt den Patch weiter. Der muss zwar dann vom Betreuer des Projektes sicher modifiziert werden, aber die Hemmschwelle unsauber rein zu gehen is geringer … und nur mit mit geringer Einstiegshürde bekommt man schnell viele Contributoren.

Behaupte ich einfach mal als These ohne Belege

Das eigentliche Problem und der häufigste Grund für Ärger ist die Architektur von WP. Damit meine ich z.B. den Umgang mit Funktionsnamen. Seit jeher gibt es z.B. the_time() und get_the_time(). the_time() gibt die Zeit als String aus, get_the_time() gibt die Zeit als Variable zurück.
Nun könnte man meinen das gleiche würde analog auch mit the_date() und get_the_date() funktionieren. Tut es aber nicht, denn es gibt keine Funktion get_the_date(). Das ist herzlich unlogisch, zieht sich aber wie ein roter Faden durch viele WP-Funktionen.
Ein weiterer Quell ewiger Freude sind deprecated functions. Nur weil irgendjemand nach 6 Jahren meint Funktion XY() gefällt ihm nicht mehr (weil es angeblich nicht logisch ist oder sonst was), heißt exakt die gleiche Funktion eine Version später plötzlich AB(). Mehrere Versionen lang wird dann eine umständliche Fehlerbehandlung mit rum geschleppt die dem Entwickler sagt das Funktion XY() veraltet sei und er statt dessen nun AB() verwenden solle. Klar das dann gerade ältere Plugins oft ohne ersichtlichen Grund nicht mehr so funktionieren wie sie sollen.
In Version 2.9 ist es besonders witzig. Denn seit 2.9 ist die Funktion _c() veraltet, man solle besser _x() verwenden. Die WP-Entwickler haben sich aber selber nicht darum gekümmert und _c() rund 8.864 in 406 verschiedenen Dateien verwendet.

Solche Dinge sind es die viele WP-Benutzer und letzten Endes auch die Plugin-Entwickler entnervt aufgeben lässt. Und das sind nun mal Sachen die man recht einfach verhindern kann.
Es hätte WP wesentlich besser getan statt den vielen kleinen Versionssprüngen mit vielen kleinen Änderungen ab und zu einen klaren Schnitt zu machen. Plugin X funktioniert dann zwar noch mit WP-Version 2, jedoch nicht mehr mit WP-Version 3. Das ist klar, logisch und auch für unerfahrene Anwender nachvollziehbar.

Wenn ich ein technisch unwissender Nutzer wäre, würde ich wohl mit dieser Meldung überhaupt nichts anfangen können, und das bei einem Feature wie dem Core Update, dass finde ich schon ziemlich kritisch!