In sechs Beiträgen haben ich euch in den vergangenen Wochen die Möglichkeiten aufgezeigt, wie man ein Plugin anpassen kann. Heute möchte ich die Reihe mit einer kleinen Zusammenfassung beenden.
Jeder der vorangegangenen Artikel hat versucht, eine einzelne Möglichkeit zu beschreiben. Wer sich nun fragt, wie man am besten vorgehen sollte, hier meine persönliche Vorgehensweise bei der Anpassung von Plugins.
In den letzten Beiträgen zu dieser Artikelreihe ging es meistens um technische Anpassungen an Plugins. Heute möchte ich mich mit Änderungen an Template Dateien beschäftigen und an einem Beispiel zeigen, wie oft dies bei gute programmierten Plugins möglich ist.
Als Beispiel habe ich mir WooCommerce vorgenommen. Es war das erste Mal, dass ich es installiert habe und ich war recht beeindruckt, wie gut man durch die ersten Einrichtungsschritte geführt wird. Aber darum soll es ja heute nicht gehen.
Viele Plugins haben die Eigenschaft „Kompatibel mit WooCommerce“. Ein passendes Theme zu wählen, dass für die Darstellung von Shops erstellt wurde bietet sich auf jeden Fall an. Aber selbst mit dem TwentySixteen Theme konnte ich alle Schritte einer Bestellung durchgehen.
Die WordCamp Saison macht für mich erst einmal eine Pause und daher kann ich mich wieder meiner kleinen Child Plugin Artikelserie widmen. In den letzten drei Beiträgen hatte ich mich ja intensiv mit Hooks, also mit Actions und Filtern beschäftigt. Im heutigen Beitrag möchte ich euch zeigen, welche Möglichkeiten ihr habt, wenn keine Actions oder Filter angeboten werden.
Wenn ein Plugin gut programmiert ist, dann sollte es euch Hooks anbieten. Aber manchmal hat der Plugin-Entwickler einfach euren Anwendungsfall nicht bedacht und es fehlt ein passender Hook. Sofern sich der Entwickler aber an ein paar Standards hält, könnt ihr eventuell trotzdem das Plugin verändern, ohne den Originalcode verändern zu müssen.
Am vergangenen Wochenende fand das bisher größte WordCamp aller Zeiten in Wien statt – das WordCamp Europe 2016. Für mich war es das erste WordCamp, bei dem ich als Volunteer dabei war. Bisher hatte ich „nur“ dreimal ein Camp organisiert und auf einigen gesprochen. Ich war also sehr gespannt, wie man ein WordCamp so als Volunteer erlebt.
Das erste und einzige Mal war ich damals in der 9. Klasse in Wien. Selbstverständlich haben wir damals alle wichtigen touristischen Dinge gemacht. Aber mir war nicht mehr bewusst, wie schön die Stadt doch war. Vor allem die vielen alten Gebäude haben mich wieder schwer beeindruckt.
Im Gegensatz zu meinem letzten Besuch war es in diesem Jahr in Wien sehr heiß. Das Thermometer kletterte auf etwa 34°C und auch in den Räumen war es gemütlich warm 🙂 Nicht ganz so schlimm wie in Sevilla letztes Jahr, aber doch recht anstrengend. Glücklicherweise gab es in den Sälen eine Klimaanlage 😉
Ja, sieben Jahre ist es heute auf den Tag genau her, dass ich diesen Blog gestartet habe. Wie auch in den Jahren zuvor möchte ich heute wieder ein wenig die letzten 12 Monate Revue passieren lassen und auch einen kleinen Ausblick auf die Zukunft geben.
An dieser Stelle habe ich in den letzten Jahren immer eingestehen müssen, dass ich es wieder nicht geschafft habe, mein Versprechen einzulösen und mehr zu bloggen. Im letzten Jahr habe ich dieses Versprechen sogar zurückgezogen, weil ich dachte, dass sich so schnell nichts ändern würde. Denn auch das letzte Blogjahr hatte wieder sehr schlecht gestartet. Von Juni bis November habe ich nur 3 richtige Artikel geschrieben sowie einen weiteren, in dem ich meine Folien vom WordCamp Berlin veröffentlicht habe. Das waren immerhin schon so viele Artikel wie im Jahr zuvor, aber natürlich nicht wirklich befriedigend. Aber dann kam der Dezember 😉
Eigentlich müsste ich ja heute gar keinen Artikel schreiben, denn meine Schuldigkeit für das #projekt52 habe ich eigentlich mit meinem englischen Artikel über das WordCamp Bilbao schon getan. Aber ich möchte natürlich meine deutschsprachigen Leser nicht enttäuschen und meine Artikelreihe zu Child Plugins fortführen 🙂
Im letzten Beitrag ging es ja um Actions und wie man diese findet. Die Funktion, die man dabei im Code suchen musste war die do_action() Funktion. Da die Funktionsnamen bei Filters und Actions sehr ähnlich sind, könnte man nun auf die Idee kommen, nach do_filter() zu suchen. Leider werdet ihr damit keinen Erfolg haben, denn die Funktion, die ihr suchen müsst lautet apply_filters() und man erkennt schon am Namen den Unterschied zwischen den beiden Hooks, die ich euch im vorletzten Artikel erklärt habe. Filter verändern einen übergebenen Wert (und das können eben mehrere Veränderungen sein, daher der Plural im Funktionsname), wohingegen Actions etwas ausführen, was in der Regel eine Ausgabe von HTML-Code oder ein anderer Seiteneffekt ist.
Im letzten Beitrag habe ich euch eine kleine Einführung in der Welt des WordPress Hook Systems gegeben und euch dabei auch zwei kleine Beispiele gegeben. Beide konnte ich aus der Dokumentation des Plugins entnehmen. Wie genau werden solche Hook aber eingebaut und wie kann man diese dann erkennen? Genau das möchte ich euch im heutigen Artikel kurz erklären.
Was macht man also, wenn es keine Dokumentation gibt, man aber trotzdem an einem Plugin Veränderungen vornehmen möchte. Ein Weg wäre es natürlich, nach der Problemstellung in einer Suchmaschine oder auf Portalen wie WordPress StackExchange danach zu suchen.
Ich schaue aber meistens direkt im Code nach, ob ich einen passenden Hook finde, an dem ich ansetzen kann. Im Fall von
Im ersten Beitrag zum Thema Child Plugins habe ich euch berichtet, wie man Konstanten einsetzen kann, um Plugins anzupassen. Darin habe ich auch erwähnt, dass man Konstanten als Entwickler eher vermeiden sollte. Heute möchte ich euch einen Weg vorstellen, wie man es besser machen kann.
Eines der mächtigsten Werkzeuge bei der Anpassung von WordPress sind die sogenannten Hooks. Dieser Oberbegriff meint die beiden Varianten Actions und Filters. Mit diesen beiden Hilfsmitteln kann man den WordPress Core, aber auch Themes und Plugins anpassen.
Um es gleich vorweg zu nehmen: So etwas wie „Child Plugins“ gibt es nicht 🙂 Wieso also komme ich auf diesen komischen Titel? Den Anstoß zu meiner neuen kleinen Artikelreihe gab ein Tweet von Phillip Roth:
Den meisten WordPress Entwicklern ist das Prinzip von Child Themes ein Begriff und sie wissen auch, wie man damit eigene Themes erstellen kann, die bei einem Update des Parent Themes nicht verloren gehen.
Das war ja eine Woche 🙂 Mein letzter Artikel hat ein sehr zwiespältiges Feedback erzeugt. Sehr viele haben mir für das Plugin gedankt und einige haben mir auch für den Appell gedankt, da ich ihnen damit aus der Seele gesprochen habe. Andere haben mir diesen Appell eher übelgenommen. So richtig böse war zum Glück fast kaum jemand 🙂
Aber der Reihe nach, was genau stand in dem Artikel. Hier nochmal kurz der Text, den ich mittlerweile dort entfernt habe (einfach um hier darüber zu einer Diskussion anzuregen):