Um keine falschen Erwartungen zu wecken: Es geht hier nicht um Programmiertechniken, sondern um Details im WordPress Plugin-Verzeichnis, auf Github und meinen Recherchen dazu. Es reicht also ein Plugin im Verzeichnis und/oder auf Github zu haben, um aus dem folgenden Artikel seinen Nutzen zu ziehen.

Ich habe unter anderem ein Plugin namens Normalizer im Plugin-Verzeichnis und auf Github. Ich werde es demnächst aktualisieren, dazu später mehr, aber erst einmal starte ich mit dem Aufhübschen der Github-Seite.

Auffindbarkeit und Verlinkung bei Github

Aktuell sieht der Header etwas kahl aus:

Aber da stehen ja zwei Links: Zum einen ein „Edit“-Button und ein „Manage Topics“-Link. Praktischerweise bietet Github gleich ein paar Vorschläge an und hat zudem eine Autocomplete-Funktion.

Nach einer kleinen Recherche bei anderen Plugins haben sich ein paar Schlagworte eingebürgert: wordpress und wordpress-plugin sind somit schon mal gesetzt, der Rest wird je nach Funktion des Plugins vergeben.

Nun noch den Edit-Button angeklickt. Die Beschreibung hatte ich schon ausgefüllt (wer das noch nicht gemacht hat, kann das jetzt nachholen!), aber hinter der Beschreibung kann zusätzlich noch optional ein Link angegeben werden. In unserem Fall macht es natürlich Sinn, den Link zum offiziellen Plugin-Verzeichnis anzugeben.

Sponsorship und Wikis – Aufräumen und Erweitern

Wo wir schon dabei sind, den Header aufzuräumen: Wer nicht alle Funktionen von Github nutzt, der kann sie auch deaktivieren. Ich habe zum Beispiel das Wiki gar nicht befüllt, also ab in die Einstellungen und weg damit. Es kann ja jederzeit wieder aktiviert werden, wenn es doch genutzt werden soll.

Nun wird es spannender. Auf Github kann auch ein Sponsor-Button eingerichtet werden.

Auch das muss in den Einstellungen erst einmal aktiviert werden:

Praktischerweise gibt Github uns direkt einen Button zum Einrichten der notwendigen funding.yml-Datei. Dabei unterstützt Github ein paar Dienste out-of-the-box, wie zum Beispiel Patreon. Aber es können aber auch einfach individuelle Links angegeben werden:

Das Ergebnis ist ein schöner Sponsor-Button im Header:

Beim Klick öffnet sich ein Modal mit den Links:

Noch mehr Informationen via Badges bereitstellen

Und weiter geht es mit Badges für unser Plugin. Dazu nutze ich eine Readme.md-Datei. Das WordPress-Plugin-Verzeichnis kann zwar auch (eingeschränkt) mit dem Markdown umgehen, so dass nur eine Datei ausreichen würde, aber da die readme.txt bevorzugt wird, empfehle ich die Nutzung der readme.txt nur für WordPress.org und die Readme.md für Github. Es gibt viele Möglichkeiten das Github-Repo so etwas aufzuwerten. Diverse Dienste bieten Badges an, die eingebunden werden können. Besonders einfach und praktisch finde ich https://shields.io/. Dieser Dienst fragt mehrere Punkte der WordPress.org-API ab und stellt diese Info als Badge dar.

Dazu wird einfach der Slug des Plugins in ein Formular eingegeben. Für mein „Normalizer“-Plugin also einfach „normalizer“. Der Link zum Badge-Bild kann dann einfach unten mit einem Klick auf den Button kopiert werden.

Die Inhalte und das Styling werden über die URL definiert. Abgefragt werden kann zum Beispiel die Downloadzahlen und aktiven Installationen:

Oder die Bewertung (als Zahl oder mit Sternen):

Auch die Version kann abgefragt werden:

Sowie die erforderliche und die getestete WordPress-Version

Das Ergebnis müsste dann in etwa so aussehen:

Bonustipp: Korrekte Versionen angeben!

Für jedes Plugin kann angegeben bis zu welcher WordPress-Version es getestet ist (Tested up to:) und welche WordPress-Version mindestens benötigt wird (Required at least:). Dabei gibt es zwei wichtige Infos zu berücksichtigen. Zum einen darf kein Text davor stehen (WP oder WordPress zum Beispiel) und zum anderen soll die letzte Ziffer, also die Minor Version, weggelassen werden:

Make note that the Tested up to field ignores minor versions, as plugins shouldn’t break with a minor update. This means you only need to define the major version it is tested against and the WordPress.org plugin directory will automatically add the minor version for you. This should be numbers only, so ‘4.9’ and not ‘WP 4.9’
offizelle Doku

Ich habe mich gefragt, wie viele Plugins das wohl korrekt angeben. Mit Stand heute geben 32.093 (!) von 55.613 Plugins auch die Minor Version bei Tested up to: an. Herausgefunden mit dem wahnsinnig praktischen Tool WPDirectory, welches Theme- oder Plugin-Verzeichnis via regulärem Ausdruck durchsuchen kann: https://wpdirectory.net/search/01E3CFYMTXZDGW4767EE8EYN1A

Und auch zusätzlicher Text ist sehr häufig zu finden. Über 300 Plugins geben WP oder WordPress zusätzlich an: https://wpdirectory.net/search/01E2VC73TTN26TEE80BNKMX1QM.

Vor allem BuddyPress-Entwickler missbrauchen das Ganze für ein Dependenz-Management, welches Plugin leider nicht anbietet: https://wpdirectory.net/search/01E40VXX5314NANTD211MT8ZGS

Es gab mal ein Feature-Plugin-Projekt, was leider nicht vollendet wurde. Es bestand aus einem Basis-Plugin, welches die Funktion nachrüstet eine zusätzliche Zeile im readme.txt-Header anzugeben. Mit Depends: BuddyPress, Debug Bar wird zum Beispiel angegeben, dass das Plugin die Plugins BuddyPress und Debug Bar voraussetzt.

Da sehr wenige Entwickler mitgemacht haben und so das Plugin nicht durchgestartet ist (Henne-Ei-Problem), wurde ein Helfer-Plugin gestartet, welches für die größten Plugins die Abhängigkeiten schon mal bereit hält.

Und auch die Requires at least:-Angabe ist sehr häufig fehlerbehaftet, dabei gibt es mit dem „Plugin Doctor“ einen großartigen Dienst, der einem die Arbeit abnimmt, den Wert korrekt zu bestimmen.

Seit Mitte März ist der Pluginfilecheck auch wieder auf dem aktuellen :

Fazit

Ich finde es wirklich erstaunlich wie viele Plugins diese einfachen Mittel nicht nutzen. Obwohl sie relativ einfach einzurichten sind.

Kennst du noch mehr solche praktischen Möglichkeiten ein Plugin (oder Theme) aufzuwerten? Oder beliebte Fehler, die Entwickler und Entwicklerinnen gerne mal machen? Dann ab damit in die Kommentare!