Comment créer une API pour mon plugin?

J'ai développé des plugins pour WordPress, la plupart des plugins que j'ai développés utilisent deux ou trois classes, donc pas aussi énormes que Buddypress ou WooCommerce.

Je prévois de développer deux plugins open source pour fournir une sorte de système complexe (ne peut pas partager de détails pour le moment mais plus tard pendant le développement) où d'autres développeurs peuvent personnaliser les fonctions et le système pour eux doit être le même que Buddypress et WooCommerce .

En vérifiant ces fichiers de plugins et en réalisant qu'ils ont enregistré leurs propres actions et filtres que les développeurs peuvent modifier selon leurs besoins. Cependant, mon problème est de ne pas pouvoir comprendre complètement, comment je devrais écrire un plugin où d'autres ont la possibilité de remplacer les fonctions ainsi que d'ajouter les leurs.

Je sais qu'il est difficile de donner une réponse définitive, mais j'ai besoin d'une sorte de guide de démarrage pour pouvoir aller dans la bonne direction. Dois-je enregistrer mes propres actions et filtres? Si oui comment? sinon, quelles sont mes options?

Vos conseils m'aideront beaucoup ... Merci

L'API que vous proposez dans un plugin ou un thème dépend de la logique de ce code spécifique. Il n'y a probablement aucun guide qui s'applique à toutes les situations.

Je contribue à plusieurs plugins avec des API, et ce que j'ai appris jusqu'à présent est:

1. Ne proposez pas d'API tant que vous ne savez pas vraiment comment les gens utilisent votre code.

   Libérez les deux ou trois premières versions sans aucune API. Aucune action ou filtre personnalisé, aucune méthode ou fonction publique (et jamais aucune variable globale) si possible. Attendez les demandes de vos utilisateurs, mais n'ajoutez pas le code avant de savoir que votre structure de code interne fonctionnera à long terme.

   Il est difficile de maintenir la compatibilité descendante d'une API . Cela pourrait empêcher les améliorations nécessaires ailleurs. Pensez à toutes les variables globales que WordPress ne peut pas supprimer de nos jours. C'est une mauvaise API, et nous sommes coincés avec elle depuis de nombreuses années, car les gens l' utilisent déjà .

2. Pensez à séparer votre API du reste du code (voir le lien précédent pour une idée).
   Votre API devrait être utile non seulement pour les développeurs tiers, mais aussi pour vous. N'ajoutez pas de restriction pour vous-même si vous n'y êtes pas obligé.

3. Mangez votre propre nourriture pour chien.
   Si vous proposez des crochets personnalisés, utilisez-les dans votre code. Cela donnera aux autres développeurs des exemples utiles, et vous pourrez voir assez tôt d'éventuels défauts.
   Si le noyau WordPress utilisait en interne la soi-disant API de paramètres , nous n'aurions pas ce gâchis aujourd'hui. Peut être.

4. Mener par l'exemple.
   Utilisez les bonnes parties de l'API WordPress core dans votre plugin. Évitez les objets anonymes , les constantes, les variables globales et tout type de code imprévisible .

5. Assurez-vous que vous utilisez un schéma de dénomination cohérent (pas un tel gâchis ) et placez tout sous votre propre espace de noms.

6. Écrivez d'abord la documentation. Libérez une nouvelle (partie d'une) API plus tard.
   Créez des exemples utiles pour tout. Vous serez étonné de voir combien de trous et de redondances vous trouverez.

7. Évitez l'enfer de rappel.
   Offrez des outils spécifiques pour déboguer votre API lorsque les choses ne fonctionnent pas comme elles le devraient (y compris les scripts et les feuilles de style non minifiés). J'ai écrit un exemple pour déboguer AJAX , juste pour illustrer à quel point vous pouvez être créatif ici. Encore une fois, ces outils doivent être expliqués dans votre documentation avant de les publier.

8. Une alternative au paradigme de rappel de WordPress pourrait être le modèle Observer . Cela augmenterait la barrière pour les développeurs tiers, mais cela pourrait entraîner un meilleur code des deux côtés.