web-dev-qa-db-fra.com

Utilisation de filtres et d’actions pour l’API de plug-in?

Je souhaite intégrer une API publique à un plugin que je développe.

La manière habituelle pour les autres plugins d’intégrer des API est de définir des fonctions qui peuvent être appelées par n’importe quel thème ou plugin.

Cependant, je pense que c'est une mauvaise idée car cela causera des erreurs lorsque mon plug-in d'API n'est pas actif et j'ai eu l'idée d'utiliser des filtres et des actions pour l'API. Un peu comme ceci:

// Get some user specific data from my plugin:
$data = false;
if ( apply_filters( 'mp:is-active' ) ) {
    $data = apply_filters( 'mp:get-user-data' );
}

// Add a private notification for a single user:
do_action( 'mp:send-notification', $user_id, $message );

La question est:

Je n'ai encore jamais vu ce type d'API dans d'autres plugins, existe-t-il donc une bonne raison de ne pas l'utiliser (par exemple, de mauvaises performances, etc.)

Ou pensez-vous que c'est une bonne façon de faire?

plugin-developmenthooksapicustomization
5
Philipp

Certes, cette approche présente certains avantages, mais présente également certains problèmes.

Ce n'est pas vraiment facile à utiliser

Si la cible de votre plugin sont les développeurs WordPress, ils connaîtront très bien l’API du plugin, mais les utilisateurs finaux ne le sont pas.

Pour un non-développeur, quelque chose comme:

$data = give_me_the_data();

C'est plus facile à comprendre, à mémoriser et à taper que:

$data = apply_filters( 'give_me_the_data' );

Si vous regardez quelques-unes des questions de ce site, vous comprendrez à quel point il y a confusion entre action et filtres dans WordPress entre novices et non-développeurs.

Le problème "typo"

En tant que personne qui fait beaucoup de fautes de frappe, je sais qu'ils sont frustrants. Si vous écrivez une fonction avec une faute de frappe, une erreur est générée et l'utilisateur reconnaît immédiatement le problème. Une faute de frappe dans un nom d'action fera échouer l'API, mais il est assez difficile à reconnaître.

À titre d'exemple:

$data = apply_filters('mp:get-user-data'); // works

$data = apply_filters('mo:get-user-data'); // does not work, hard to find why

$data = mp_get_user_data(); // works

$data = mo_get_user_data(); // does not work and throws an error, immediately found

L'enfer mondial

Les actions et les filtres ne sont que des variables globales. Si vous les utilisez pour construire votre API, votre code peut être complété par n'importe quelle autre ligne de code présente dans le système.

Cela signifie qu'un bogue dans n'importe quel plug-in qui sait peut faire échouer votre plug-in sans raison apparente. Et la raison en est que ce n'est pas votre plugin à échouer.

Exemple:

do_action( 'mp:send-notification', $user_id, $message );

// somewhere else
add_action( 'all', 'do_something_bad_that_makes_your_plugin_fail');

De plus, tout le monde peut utiliser ces hooks et même si cela peut apporter beaucoup de flexibilité à votre API, cela introduit également beaucoup de complexité.

Par exemple, si vous utilisez des objets en tant qu'arguments, en tant qu'objets transmis par référence, il est possible qu'ils soient modifiés avant l'exécution de votre rappel.

Conclusion

Ce sont toutes les raisons qui me viennent maintenant à l’esprit, mais il existe peut-être d'autres raisons si cette approche n'est pas largement utilisée.

Pour moi, je n’utiliserais pas cette approche, en particulier pour le dernier point, mais je ne peux pas dire que c’est totalement faux dans le contexte WordPress.

Par conséquent, je ne veux pas vous décourager fortement de l'utiliser, mais simplement suggérer de prendre en compte tous les problèmes à l'avance, car une fois que vous publiez une API, il est très difficile de basculer.

5
gmazzap

Les deux approches ne sont pas mutuellement exclusives. Comme @gmazzap l'a dit, ne créez pas un enfer de rappel.

Mais vous pouvez fournir un point d’accès initial afin que les autres développeurs n’aient pas à s’appuyer sur les vérifications plutôt lentes function_exists().

Exemple

Dans votre plug-in, fournissez un point d’accès que d’autres développeurs peuvent utiliser pour appeler vos classes et fonctions en toute sécurité.

add_action( 'wp_loaded', [new Your_Plugin_Bootstrap, 'setup' ], 0 );

class Your_Plugin_Bootstrap {

    public function setup() {

        // set up your data and the auto-loader, then:
        do_action( 'your_plugin_loaded' );
    }
}

Désormais, un développeur tiers peut utiliser ce hook et poursuivre avec un PHP "normal".

add_action( 'your_plugin_loaded', function() {

    // safely use your plugin's classes here.
});

Nous faisons cela dans MultilingualPress , et les commentaires des autres développeurs ont été très bons jusqu'à présent. Il est facile à comprendre et vous devez apprendre qu’un seul crochet.

Voir aussi: Comment créer une API pour mon plugin?

6
fuxia