Comment créer une API pour mon plugin?

20

Je développe 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 pouvant pas partager les détails pour le moment mais plus tard au cours du développement), où les autres développeurs peuvent personnaliser les fonctions et dont le système doit être identique à Buddypress et WooCommerce.

Lorsque je vérifie ces fichiers de plugins et s’aperçois qu’ils ont enregistré leurs propres actions et filtres que les développeurs peuvent modifier selon leurs besoins. Cependant, mon problème est d’être incapable de comprendre complètement comment je devrais écrire un plugin où d’autres auront la possibilité de remplacer des fonctions et 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 vont beaucoup m'aider ... Merci

    
posée pixelngrain 08.05.2013 - 12:23

1 réponse

24

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

Je suis un contributeur pour plusieurs plugins avec des API, et ce que j'ai appris jusqu'à présent, c'est:

  1. Ne proposez pas une API tant que vous ne savez pas vraiment comment les utilisateurs utilisent votre code.

    Libérez les deux ou trois premières versions sans aucune API. Pas d'actions personnalisées ou de filtres, pas de méthodes ou de fonctions publiques (et jamais de variables globales) 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 conserver la compatibilité avec les versions antérieures d'une API. Cela pourrait empêcher des 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 cela fait plusieurs années que nous sommes coincés là-dessus, car les utilisateurs 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 aux développeurs tiers, mais également à vous. N'ajoutez pas de restriction pour vous-même si vous n'y êtes pas obligé.

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

  4. Donner l'exemple.
    Utilisez les bonnes parties de l'API de base WordPress 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 nommage cohérent (et non un tel désordre ) et mettez tout sous votre propre espace de noms.

  6. Écrivez d'abord la documentation. Publier une nouvelle (partie d'une) API ultérieurement.
    Créez des exemples utiles pour tout. Vous serez surpris de voir combien de trous et de redondances vous allez trouver.

  7. Évitez les rappels.
    Proposez des outils spécifiques pour déboguer votre API lorsque les choses ne fonctionnent pas correctement (y compris les scripts et feuilles de style non spécifiés). J'ai écrit un exemple expliquant comment déboguer AJAX , 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 soulèverait la barrière pour les développeurs tiers, mais il pourrait en résulter un meilleur code des deux côtés.

réponse donnée fuxia 08.05.2013 - 20:36

Lire d'autres questions sur les étiquettes