Kategorien
Projektwerkstatt: OOPwp
Zuerst mal Danke für die vielen Zuschriften gestern. Der Artikel kam wohl gut an und wird auch noch ein oder zwei Nachfolger in der nächsten Zeit haben. Ideen habe ich dank eurer Mails jetzt genug. Jetzt aber zum eigentlichen Artikel.
OOPwp, was könnte das sein? Ist gar nicht so schwierig. Wie wir alle wissen, ist WordPress recht prozedural abgebaut. Das ist auch OK so. Ich kann ja meine Plugins, die ich dazu baue so objektorientiert wie ich will basteln. Ich weiß aber auch, dass sich viele daran stören, dass die Anknüpfpunkte an WordPress doch sehr einfach gehalten sind. Es gibt soviel ich weiß ein paar ehemalige Core-Wordpress-Entwickler die WP komplett OOP „nachprogrammiert“ haben. Das war aber wohl leider kein Erfolg. Jetzt kommt meine Idee.
Wie wäre es, wenn man ein Plugin bastelt, dass eine neue Plugin-Schnittstelle bietet und zwar eine mti einem wirklich sauberen OOP-Interface. Da müsste man sich jetzt natürlich Gedanken machen, wie das am besten auszusehen hat, aber dieses Plugin könnte man dann allen zur Verfügung stellen und die könnte dann eine OOP-Plugin Version basteln. Glaubt ihr sowas könnte genutzt werden? Ich hätte meine, ich komme zwischenzeitlich eigentlich ganz gut mit dem was mit WordPress zur Verfügung stellt zu Recht, aber als Anfänger kann es doch einfacher sein, wenn mir vielleicht sogar die IDE helfen kann, wenn ich wissen will, welche Events ich denn nun ansteuern kann.
Ich weiß, wirklich ausgegoren ist die Idee noch nicht, aber wenn sie für gut erachtet wird, dann kann man ja vielleicht noch mal ein wenig Brainstormen, wir das System denn aussehen könnte.
Es gibt Zendpress was nicht anderes als die Funktionalität von WordPress aus Basis des Zend Frameworks sein soll(http://www.zendpress.org/). Ob das gut ist und gelingen mag, weiß ich aber nicht. Im Großen & Ganzen ist doch WordPress eh nur Marketing-Quatsch! 😉
Im Grunde ist das eine sehr gute Idee, aber leider kann ich mir nicht vorstellen, dass das jemals genutzt wird.
Der Grund ist einfach, dass Plugin-Entwickler nicht davon ausgehen können, das OOPwp überall installiert ist, und somit entweder einen Fallback auf die normalen wordpress-hooks einbauen oder OOPwp mit jedem Plugin mitliefern muss.
Solange das nicht offiziell von künftigen WordPress-Versionen nativ unterstützt wird sehe ich da leider keine Zukunft…
Hm, gibts für WordPress nicht mittlerweile schon so ziemlich jede Erweiterung? Ich kann natürlich nicht in die Zukunft schauen, aber ich kann mir nicht vorstellen das es für die OOP-Schnittstelle reißende Downloadzahlen geben würde.
Dann müsste es schon irgendwie direkten Support von den WordPress-Leuten geben um das dann nicht in deiner Schublade verstauben zu lassen.
Aber wie gesagt, noch bin ich kein Hellseher 😉
Ich könnte mir vorstellen Plugins über das Event Collaboration Pattern – oder eine Abwandlung davon – anzubinden. Dann kann man diese vom Hauptsystem entkoppeln und nur die Events müssen bekannt sein.
Ist aber nur so eine Idee in der Kaffeepause – also sicher nicht unbedingt die beste Lösung 😀
Also ich stecke jetzt nicht so tief in WP drin. Aber man könnte doch eine Art Adapter bauen, der einem OO-Zugriff auf die wichtigsten Ressourcen und Events von WP gibt. Somit könnten Neulinge über diesen Adapter (der ja nix weiter als eine OO-Api darstellt) schnell und gezielt alle wichtigen Dinge ansteuern.
Das Projekt der ehemaligen WordPress-Entwickler heisst übrigens Habari. (Ich hab’s mir allerdings noch nie angesehen…)
ich arbeite recht viel mit WordPress, jedoch glaube ich kaum, dass ein solches Plugin genutzt werden würde. jedoch kann ich deinen Gedanken gut verstehen und habe auch schon mal drüber nachgedacht sowas zu implementieren.
Über einen anderen Ansatz bin ich übrigens vorhin gestolpert: Man integriert einfach ein bestehendes Framework in WordPress. Eine funktionierende Implementation gibt es für Kohana V3: http://www.kerkness.ca/kohana-for-wordpress/
Wie sehr die Kohana-Applikationen aber auf die Interna von WordPress zurückgreifen können, weiss ich nicht. Wesentlich schöner als direkten Zugriff auf die Datenbanktabellen wären schon gemeinsame Klassen.
Wow.
Bei Zendpress hat sich ja im Mai sogar etwas getan:D
Zwar nichts nennenswertes, aber als ich die letzten Male ins Rep. geschaut habe, war dort tote Hose.
Aber was wäre denn der Vorteil für den Anwender? Wenn das OOP-Plugin nur die sowieso vorhandenen Schnittstellen kapselt, handelt es sich doch um nichts weiter als eine Indirektionsschicht ohne echten Mehrwert. Also eine zusätzliche Fehlerquelle, die die Performance senkt und sonst nichts macht.
Interessante Idee. Ich würde nach dem Adapterprinzip die WordPressfunktionalitäten kapseln.
Is doch eigentlich mal wieder nur der Drang einzelner unbedingt alles in Klassen verpacken zu müssen. Ein prozeduraler Ansatz ist auch ein Design-Konzept und PHP — als Multiparadigmem-Sprach — untersützt es. Ich bezweifel das es Begeisterungsstürme auslöst.
Eigentlich eine schöne Sache. Etwas ähnliches habe ich auch mit anderen Systemen versucht…
Fazit: Zu viel Aufwand, ein paar Fehlerquellen mehr, schwerer zu debuggen, da man nie weiß, welche Schnittstelle nun genutzt wurde.
Dann habe ich dies gelesen…
http://www.phphatesme.com/blog/softwaretechnik/dont-fight-the-framework/
… und nun lasse ich es einfach sein, bzw. versuche so etwas halt sehr simpel zu halten.
Ja, ich sehe ein CMS, Blog usw. als eine Art Framework an.
Das hatte ich auch schon mal versucht. Bei Interesse lasse ich dir den Quellcode zukommen. Hat ne Abstraktionsschicht für verschiedene WP Versionen gemacht. Aber das ist im Grunde aussichtslos, aber sicherlich nicht verkehrt mal damit zu experimentieren.
Meine letzte Idee in der Richtung war, eine abstrakte Grundklasse zu generieren, diese als konkrete Plugin klasse zu erweitern. Die konkrete Klasse muss dann nur die im Interface festgelegten Schnittstellen benutzten um auf WP Core Funktionalitäten zuzugreifen (zB. Filter und Hooks durch Annotations um mal Spass zu haben), zugriffe auf Optionswerte etc. pp..
Evtl gleich nen Set an Klassen für Backend-Pages, Widgets etc. pp. .
Das wäre noch einigermassen Portabel, lediglich ein wenig doppelter Code wenn man mehrere Plugins der eigenen Sorte auf den Server bringt. Aber sicherlich schneller zu realisieren und stabiler auf Dauer. Ausserdem macht es den eigenen Code wesentlich besser wart- und testbar.