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:

Ihr verwendet ein anderes Plugin
Ihr schreibt ein ganz eigenes Plugin
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.

Kau-Boys

Webentwicklung und mehr