Wie erstelle ich eine API für mein Plugin?

Ich habe Plugins für WordPress entwickelt, die meisten von mir entwickelten Plugins verwenden zwei oder drei Klassen, daher nicht so umfangreich wie Buddypress oder WooCommerce.

Ich plane, zwei Open-Source-Plugins zu entwickeln, um eine Art komplexes System bereitzustellen (Details können derzeit nicht geteilt werden, aber später während der Entwicklung), in dem andere Entwickler Funktionen anpassen können und das System für sie mit Buddypress und WooCommerce identisch sein muss .

Während ich diese Plug-in-Dateien überprüfe, stelle ich fest, dass sie ihre eigenen Aktionen und Filter registriert haben, die Entwickler nach Bedarf ändern können. Mein Problem ist jedoch, dass ich nicht vollständig verstehen kann, wie ich ein Plugin schreiben soll, bei dem andere die Flexibilität haben, Funktionen zu überschreiben und eigene Funktionen hinzuzufügen.

Ich weiß, dass es schwierig ist, eine eindeutige Antwort zu geben, aber ich brauche eine Art Starthilfe, damit ich in die richtige Richtung gehen kann. Muss ich meine eigenen Aktionen und Filter registrieren? Wenn ja wie? Wenn nicht, welche Möglichkeiten habe ich?

Ihr Rat wird mir sehr helfen ... Danke

Die API, die Sie in einem Plugin oder Thema anbieten, hängt von der Logik des jeweiligen Codes ab. Es gibt wahrscheinlich keinen Leitfaden, der für alle Situationen gilt.

Ich arbeite für mehrere Plugins mit APIs mit und habe bisher Folgendes gelernt:

1. Bieten Sie keine API an, bis Sie wirklich wissen, wie die Leute Ihren Code verwenden.

   Geben Sie die ersten zwei oder drei Versionen ohne API frei. Wenn möglich, keine benutzerdefinierten Aktionen oder Filter, keine öffentlichen Methoden oder Funktionen (und keine globalen Variablen). Warten Sie auf Anfragen Ihrer Benutzer, aber fügen Sie den Code erst hinzu, wenn Sie wissen, dass Ihre innere Codestruktur auf lange Sicht funktionieren wird.

   Die Aufrechterhaltung der Abwärtskompatibilität einer API ist schwierig . Dies könnte notwendige Verbesserungen an anderen Stellen verhindern. Denken Sie an alle globalen Variablen, die WordPress heutzutage nicht entfernen kann. Das ist eine schlechte API, und wir bleiben viele Jahre daran hängen, weil die Leute sie bereits verwenden .

2. Ziehen Sie in Betracht, Ihre API vom Rest des Codes zu trennen (eine Idee finden Sie unter dem vorherigen Link).
   Ihre API sollte nicht nur für Entwickler von Drittanbietern nützlich sein, sondern auch für Sie. Fügen Sie keine Einschränkungen für sich selbst hinzu, wenn Sie dies nicht müssen.

3. Iss dein eigenes Hundefutter.
   Wenn Sie benutzerdefinierte Hooks anbieten, verwenden Sie diese in Ihrem Code. Dies wird anderen Entwicklern nützliche Beispiele geben und Sie können mögliche Fehler früh genug erkennen.
   Wenn der WordPress-Kern die sogenannte Einstellungs-API intern verwenden würde, hätten wir dieses Chaos heute nicht. Vielleicht.

4. Mit gutem Beispiel vorangehen.
   Verwenden Sie die guten Teile der WordPress-Core-API in Ihrem Plugin. Vermeiden Sie anonyme Objekte , Konstanten, globale Variablen und unvorhersehbaren Code .

5. Stellen Sie sicher, dass Sie ein konsistentes Benennungsschema verwenden (kein solches Durcheinander ), und legen Sie alles in Ihrem eigenen Namespace ab.

6. Schreiben Sie zuerst die Dokumentation. Geben Sie später einen neuen (Teil einer) API frei.
   Erstellen Sie nützliche Beispiele für alles. Sie werden erstaunt sein, wie viele Löcher und Redundanzen Sie finden werden.

7. Vermeiden Sie Rückruf Hölle.
   Bieten Sie spezielle Tools zum Debuggen Ihrer API an, wenn die Dinge nicht wie gewünscht funktionieren (einschließlich nicht minimierter Skripts und Stylesheets). Ich habe ein Beispiel für das Debuggen von AJAX geschrieben , um zu veranschaulichen, wie kreativ Sie hier sein können. Auch diese Tools sollten in Ihrer Dokumentation erläutert werden, bevor Sie sie freigeben.

8. Eine Alternative zum Callback-Paradigma von WordPress könnte das Observer-Muster sein . Dies würde die Barriere für Entwickler von Drittanbietern erhöhen, könnte jedoch zu einem besseren Code auf beiden Seiten führen.