Kategorien
WordPress – The php way
Vor ein paar Tagen hatte ich ja ein WordPress Buch aus dem Franzis Verlag vorgestellt. Es war solide und beschrieb genau den Weg, den WordPress einen vorschreibt, wenn man Themes und Templates erstellen will. Wie so oft bei solchen Themen kam eine Diskussion auf, ob denn jetzt WordPress das fieseste Stück Software ist, das man zur Zeit finden kann. Ich habe mir natürlich so meine Gedanken darüber gemacht. Bin mir aber nicht sicher, dass ich meine Meinung nicht auch ändern würde, wenn jemand ein paar gute Argumente hat.
Fangen wir aber einfach mal an. WordPress ist nicht sauber OO programmiert. Es gibt z.B. eine functions.php und die ich alles reinschreiben kann, was ich gerne aufgerufen haben will, wenn mein Theme initialisiert wird. Dort ist es sehr einfach mit ein paar Funktionen nette Features hinzubekommen.
Worauf ich hinaus will: WordPress macht es einem ziemlich einfach „unschönen“ Code zu schreiben. An die ganzen Events, die von der Blogsoftware gefeuert werden, kann ich mich per callback dranhängen. Funktionen über Funktionen also, das Leben mit Objekten wird einen hier nicht vorgelebt. Aus diesem Grund beschimpfen auch viele OOP Anhänger das WordPress System. Was ich auch auf der einen Seite verständlich finde.
Jetzt kommt natürlich das ABER. Als ich früher noch Basketball gespielt habe gab es den Satz „Wer trifft hat Recht“. Es war also egal, wie idiotisch deine Bewegung war, wenn der Ball drinnen war, hattest du es richtig gemacht. Ich schweife ab? Nö. WordPress hat ungefähr eine Quadzilliade Plugins, obwohl sie sich schrecklich bewegt haben. Anscheinend scheinen sie also doch war richtig zu machen. Aber was?
WordPress geht absolut den von PHP vorgesehenen Weg. Wenn ich etwas „hinrotzen“ will, dann kann ich das. Wenn ich etwas gut strukturiert und wartbar bauen will, dann kann ich das auch. WordPress hindert mich ja nicht daran, dass ich mir meine Objekte zusammenbastel. Genau so ist es ja in PHP auch gedacht. Diese Blogsoftware verkörpert also so ein wenig die Idee hinter PHP. Wer PHP mag, sollte sich also auch mit WordPress anfreunden können.
Warum hat aber WordPress mit seiner doch recht „simplen“ Plugin und Erweiterungsstrategie genau ins schwarze getroffen? Naja meiner Vermutung kann jeder Hinz und Kunz Plugns schreibe, auch wenn er absoluter Anfänger ist. Er muss nicht wissen was ein Plugin Interface ist und wie an mit Singletons oder anderen Pattern umgeht. Jeder DAP (dümmster anzunehmender Programmierer) kann sich hier austoben.
Die schiere Masse an potentiellen Entwicklern ist also riesig. Das bedeutet aber auch, dass es eine riesige Anzahl von Plugins gibt, was die Anzahl der Nutzer erhöht, was es wiederum noch interessanter macht Plugins zu bauen. Ein Teufelskreis.
Was haben wir gelernt? WordPress ist kacke, aber irgendwie faszinierend. Manchmal scheint es auch legitim zu sein, die Einstiegshürde möglichst gering zu halten und somit auf vielleicht akademisch unsauberen Code zurück zu greifen. Vielleicht aber auch nicht. Lasst es uns also ausdiskutieren.
Was mir gerade noch einfällt. Heute ist der letzte Eintrag vor Weihnachten (morgen zählt für mich als Feiertag). Ich wünsche euch als schöne Festtage ein gesegnetes Fest.
In unserer Firma ist der Euphemismus für ein solches System ‚organisch gewachsen‘.
WordPress wurde 2003, vor knapp 7 Jahren, das erste Mal veröffentlicht. Und ist heute noch PHP4-kompatibel. Mit solch einem historischen Ballast genannt Rückwärtskompatibilität und tausenden von Plugins welche darauf aufbauen, kann man gewisse Jugendsünden einfach nicht mehr so einfach ausmerzen. Also bitte etwas Verständnis für das alte Skript.
Das ist natürlich kein WordPress-typisches Problem. Frag mal Microsoft wie beliebt neue Betriebssysteme sind, welche Applikationen kaputt machen.
Und hat früher oder später natürlich die Konsequenz dass ein neuer Ansatz, ein neues Rewrite entsteht. Wie so oft aber nicht unter dem alten Namen, sondern als neues, eigenständiges Projekt. Und natürlich erfordert, dass dafür sämtliche Plugins neu geschrieben werden müssen.
Ein anderer Gedanke: Typo3 und Gallery 3 kommen bald schon mit ihren eigenen Framworks ausgeliefert (Flow / Kohana), welche das Entwickeln von Plugins unterstützt. Das ist potentiell sehr mächtig. Aber kaum ein Feature, an welches du in der Version 0.1 deiner Software gedacht hättest. Und wenn du es wie bei Gallery in der Version 3 einführst, hast du bereits wieder den ganzen Legacy-Code am Hals.
(Ah, schöne Weihnachten noch…)
Das schöne an WordPress ist doch, dass ich eine grundsolide Basis bekomme und mich durch die vielen Callbacks und Einsprungspunkte überall einklinken kann.
Meinen eigenen Code lagere ich in ein Plugin oder auch ins Theme aus und bin damit unabhängig vom Rest des vielleicht unschönen Codes.
Die Schnittstellen nach „außen“ hin sind stabil und im Vergleich zu anderen PHP Anwendungen im hauseigenen „Codex“ sehr gut dokumentiert und mit Beispielen bestückt.
Das hat auch den Vorteil, dass ich wie bei der Veröffentlichung von einer neuen WordPress-Version einfach meine Installation aktualisieren kann ohne mir Gedanken um einen Funktionsverlust machen zu müssen.
Aber recht hast du natürlich. Objektorientiert ist das nicht, auch wenn man an vielen Stellen mit kleineren Objekten arbeitet, ist der Kern doch funktional programmiert.
Es ist m.E. nicht entscheidend wie (oder auch in welcher Sprache) ein „Framework“ geschrieben ist. Solange ich als Entwickler in meiner Arbeit nicht eingeschränkt werde und meinen Job machen kann, die Anforderungen umgesetzt bekomme, ist es mir egal, wie der Code hinter der Schnittstelle aussieht. Das ist doch auch genau das, was ich auch von einem stabilen Framework erwarte: Es nimmt mir die lästige Grundarbeit ab, bietet mir Möglichkeiten ins System einzugreifen und letztlich noch das Resultat zu darzustellen, wie ich das gerne haben möchte.
Ob man die Idee & das Konzept hinter WordPress so auf andere Projekte übertragen sollte ist sicher fraglich. Doch lernen kann man von WordPress doch ne Menge, vor allem das Schnittstellendesign.
Ich mag WordPress. Es ist leichtgewichtig, einsteigerfreundlich – sowohl für den Anwender als auch für den Entwickler – und sehr flexibel einsetzbar.
http://j.mp/4x8cS9
http://j.mp/6ppgH0
http://j.mp/5Ktfr8
Ich frage mich gerade, ob jQuery intern nicht genauso aufgestellt ist mit all den Callbacks etc?
Oh Oh, einige Rechtschreibfehler drin 😉
War da gestern jemand zu lange weg? 😛
Ansonsten netter Artikel.
Auch wenn mir ein OOP-WP lieber wäre
@Simon: Das sie die Weihnachtsfehler, die entstehen, wenn man in der vollen U-Bahn sitzt und tippt.
Ich glaube ein OOP-WP würde es gar nicht so weit gebracht habe. Aber man könnte das Plugin System ja mal aufbohren auf OOP und schauen was passiert.
Da muss ich leider widersprechen.
WordPress ist einfach nicht bewusst so schlecht programmiert worden! Es kann nicht sein, dass ich in meinem WordPress Backend innerhalb von 5 Minuten 6 Errors bekomme, darunter sogar fatale.
Das ist für mich einfach ein Beweis, dass hier schlecht programmiert wurde. Ob OOP oder nicht, solche Sachen kann und muss man abfangen!
Gruß Sebastian
Ah, hab’s gefunden: Ein paar ehemalige WordPress-Kontributoren waren ebenfalls mit der Struktur des Projekts frustriert und haben 2007 einen neuen Versuch gestartet: http://habariproject.org/en/
@Sebastian: Ich habe noch nie einen fatal error von wordpress bekommen. Bei mir läuft es stabil seit einer ganzen Weile.
@Christian: Danke für den Link. Da sieht man, dass gute Architektur nicht immer Ausschlag für den Erfolg eines Internet Projektes gibt.
Alle Jahre wieder die Diskussion ob Quick-and-Dirty, no-OOP etc. nicht gut genug ist.
Klar zählt, wie auch beim Fussball und allen anderen, nicht nur sportlichen Dingen das Ergebnis.
Aber es geht auch um Wahrscheinlichkeiten – der Fehlerhäufigkeit und -anfälligkeit und der schwierigeren Wartbarkeit.
Und der negative Effekt entsteht in der Regel schneller bei solchen „heiß gestrickten“ oder „freigeistlich programmierten“ Projekten als mit den strukturierten Programmen (was auch immer das heißt).
Aber ist das nicht überall so? Kriegen wir nicht oftmals viele Dinge „mal eben so“ hin, wissen aber ganz genau, dass es auf Dauer nicht gut sein kann. Und auf der anderen Seite reicht oftmals die einfache Lösung, weil sie eben nicht komplex und damit wiederum anfällig ist.
Ach, ach…welch Paradoxien sich hier auftun.
Diese Diskussion birgt erhebliches philosophisches, ethisches und auch soziales Gefahrgut 😉
Manche Themen sterben nie aus…
Cheers!
@Nils: http://img704.imageshack.us/img704/7928/bildschirmfoto20091223u.png
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!
Ich glaube nicht das die unsaubere Programmierung der Kern des Ärgers ist. Plugins kann man abschalten bzw. austauschen. Zusätzlich hat man als Benutzer noch die freie Wahl ob man ein unsauber geschriebenes Plugin einsetzt oder nicht. Gezwungen wird man ja nicht.
Auch der „unsaubere“ Code von WP ist nicht wirklich das Problem. Es stimmt schon: Es funktioniert und das reicht.
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.
Insgesamt finde ich es faszinierend, dass es oft „schlechte“ software ist, die Erfolgreich ist. Trifft ja nicht nur auf wordpress zu, und geht sogar über PHP hinaus.
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 😉
@Sebastian: Das ist ein Fehler, der von einer Anwendung garnicht abgefangen werden kann. Eine Anwendung kann höchstens vorher (und das bei jedem Request) prüfen, ob der Wert „eventuell“ ausreicht. Aber ehrlich: 20MB ist doch etwas arg wenig 😉
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.
@ KingCrunch: gerade wenn ich sowas wie ein Update habe, wo ich schon vorher weiß, dass das eng im Speicher wird, könnte ich ja mal einen Vergleich meiner zu erwartenden Speicherfresser und dem freigegebenen Speicher machen. Genau das selbe auch im Plugin Editor. Das muss einfach nicht sein und bei einer so großen Software darf es meiner Meinung nach auch nicht sein.
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.
Wenn du ein Spiel kaufst, wo drauf steht „ab Windows XP“, wunderst du dich auch. wenn es bei deinem Mac nich läuft?
Ich finde den Artikel gut weil der einen wichtigen Punkt benennt der meines erachtens stimmt: Der Zweck heiligt nun mal die Mittel. Und man kann ja auch selber sauberen Code in seinen Plugins und Themes schreiben. Das geht sehr gut.
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.