Child Plugins: Zusammenfassung der Themenreihe

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.

Empfohlene Vorgehensweise bei der Anpassung

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.

1. Hooks, API und Template-Strukturen des Plugins nutzen

Die beste Möglichkeit zur Anpassung bieten Hooks, also Filter und Actions, die das Plugin aktiv dem Entwickler zur Verfügung stellt. Bei komplexeren Plugins gibt es teilweise auch eine API, mit der man das Plugin auch abseits von Hooks anpassen kann. Weiterhin sollte man beim Anpassen von Templates auf die vorhandene Struktur. Hiermit kann man das Templating oft am besten anpassen. Auch Konstanten, die das Plugin anbietet können genutzt werden.

2. Den Entwickler um Hilfe bitten

Diesen Punkt vergessen leider viele Entwickler nur allzu oft. Man ist ja selbst Profi genug etwas anzupassen und das ist oft auch schnell passiert. Aber es besteht immer die Gefahr, dass die eigene Anpassung nach dem nächsten Plugin-Update nicht mehr funktioniert.

Solltet ihr also bei einem Plugin keinen Hook finden, den ihr nutzen könnt, dann bittet doch einfach den Entwickler mal darum, euch einen solchen zur Verfügung zu stellen. Den größten Erfolg habt ihr dabei, wenn ihr dem Entwickler gleich einen fertigen Patch schickt, den er nur noch auf den Code anwenden und einen neuen Release vorbereiten muss. Ich habe damit meistens sehr gute Erfahrungen gemacht. Am besten beschreibt ihr dabei auch detailliert, welchen Anwendungsfall des Plugins eure Erweiterung ermöglicht. Viele Entwickler sind über solche Vorschläge sehr dankbar, da sie eventuell gar nicht selbst darauf gekommen sind. Mir geht es mit meinem Plugins zumindest so 🙂

Ich würde euch vorschlagen, zuerst einmal bei GitHub, Bitbucket oder GitLab nach dem Plugin zu suchen. Findet ihr es dort, könnt ihr gleich einen Pull-Request eröffnen. Der Entwickler kann den Patch dann mit einem Mausklick einfach akzeptieren. Solltet ihr das Plugin dort nicht finden, dann erstellt einfach einen Patch und schick dem Entwickler diesen Patch zu. Ich speichere die Patches meistens in einem privaten Gist. Dies könnt ihr sogar ohne GitHub Account tun.

3. Hooks überschreiben

Erst wenn die ersten beiden Möglichkeiten keinen Erfolg gebracht haben, solltet ihr die Methode verwenden, die ich in meinem vorletzten Artikel beschrieben habe verwenden. Sie birgt aber die Gefahr, dass ein Plugin-Update zu Fehlern führt. Aber sie ist vermutlich noch sehr viel sicherer, als die letzte offene Möglichkeit.

4. Das Plugin forken

Sollte das Plugin keine Hooks anbieten, die ihr direkt verwenden könnt, sich der Entwickler nicht melden und ihr auch keine Hooks indirekt überschreiben könnt, dann bleiben nur drei Möglichkeiten offen:

  1. Ihr verwendet ein anderes Plugin
  2. Ihr schreibt ein ganz eigenes Plugin
  3. Ihr verändert das Originalplugin

Die ersten beiden Möglichkeiten sind hierbei zu bevorzugen. Falls ihr eine gute Alternative findet (die ihr eventuell besser anpassen könnt) oder falls das Plugin nicht zu komplex ist und ihr es anpassen könnt, dann versucht zuerst dies.

Sollte das aber nicht möglich sein, dann könnt ihr auch das Originalplugin anpassen. Hierbei sind einige Dinge zu beachten:

4.1 Das Plugin umbenennen

Damit eure Änderungen nicht beim nächsten Update des Originalplugins verloren gehen, müsst ihr das Plugin umbenennen. Dabei reicht es nicht aus, den Ordner umzubenennen (das müsst ihr nicht einmal). Vielmehr müsst ihr in der Hauptdatei des Plugins im “Plugin File Header” den Wert für “Plugin Name” ändern.

4.2 Einen Fork erstellen

Sollte das Plugin bei GitHub, Bitbucket, GitLab oder einem anderen Git/SVN Host verfügbar sein, dann erstellt hier einen Fork. Sollte dies nicht der Fall sein, dann erstellt euch selbst ein Git-Repository und versioniert den aktuellen Stand des Plugins (am besten mit einem Git Tag der aktuellen Verionsnummer). Erstellt dann einen Branch mit euren Anpassungen.

4.3 Den Fork aktualisieren

Ihr solltet in jedem Fall die Änderungen am Originalplugin verfolgen und euren Fork aktuell halten. Hierzu würde ich euch empfehlen, den “Development Log” RSS-Feed zu abonnieren, den ihr im Reiter “Developers” auf den Pluginseiten des WordPress.org Plugin-Repositories findet.

Sobald ein Plugin-Update es Originalplugins vorliegt, solltet ihr euch den neuen Stand in euren lokalen master-Branch laden und dann in den Branch mit euren Anpassungen mergen. So könnt ihr sicherstellen, dass euer Plugin möglichst immer auf dem letzten Stand des Originalplugins ist und nur eure Anpassungen enthält. Ihr profitiert damit von Fehlerbehebungen und geschlossenen Sicherheitslücken im Originalplugin.

4.4 Den Entwickler erneut anschreiben

Habt ihr euer Plugin auf einer Git-Hosting-Plattform veröffentlicht und ihr seid auch nach einigen Versionen noch immer der Meinung, dass die Änderungen ins Originalplugin gehören, dann schickt dem Entwickler doch einfach einen Link. Vielleicht ist er ja jetzt offener für die Anpassung.

4.5 Das eigene Plugin als Klon veröffentlichen

Wenn sich euer Plugin mit der Zeit so stark verändert hat, dass es sich in vielen Punkten vom Originalplugin unterscheidet, dann spricht auch nichts dagegen, es als eigenständiges und neues Plugin im offiziell Plugin Repository zu veröffentlichen. Die Lizenz lässt dies ja ausdrücklich zu. Dabei sind aber ein paar Regeln zu beachten. Zum einen sollte der Unterschied schon groß genug sein. Sonst habt ihr auch wenig Chancen, dass es angenommen wird.

Viel wichtiger ist aber, dass ihr in der Readme und der Beschreibung angebt, woher der eigentliche Code stammt. Ihr solltet also am besten eine kleine Danksagung an den Entwickler verfassen. Außerdem solltet ihr sehr genau herausstellen, an welchen Stellen sich euer Plugin vom Originalplugin unterscheidet.

Fazit

Ich hoffe euch hat meine kleine Themenreihe zu Child Plugins gefallen. Sollte euch jetzt noch eine Frage dazu einfallen, dann hinterlasst gerne einen Kommentar und ich versuche diese in einer Antwort oder einem weiteren Artikel zu beantworten.

Zuletzt noch einmal die Liste alle Artikel, die ich in dieser Themenreihe geschrieben habe:

Ab nächster Woche könnt ihr euch dann auf ein neues Thema freuen. Vermutlich wird es dabei um Elasticsearch gehen, dann am Donnerstag werde ich auf dem WP Meetup Berlin einen kleinen Vortrag dazu halten.

Child Plugins: Templates eines Plugins überschreiben

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.

Templates: Im Theme oder im Plugin?

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.

Weiterlesen →

Child Plugins: Plugins ohne Actions und Filter anpassen

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.

Hooks mit eigenen Funktionen überschreiben

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.

Weiterlesen →

WordCamp Europe 2016 – Mein erstes WordCamp als Volunteer

wceu-2016-square-volunteer

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.

Zurück in Wien nach 18 Jahren

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 😉

Weiterlesen →

Das verflixte siebte Jahr ist überstanden

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 😉

Weiterlesen →