web-dev-qa-db-fra.com

Combien de points de filtrage/action sont sains?

Rendre mon plugin extensible est le prochain moyen de résoudre les problèmes de la plupart des gens. Et je sais que je peux placer de nombreux crochets de filtre et d’action ici et là pour rendre les choses plus dynamiques. Mais pour moi, c'est trop compliqué.

Récemment, un utilisateur de mon plugin a demandé à modifier le texte de l'infobulle, et dans leur cas, ce n'est pas une si mauvaise raison. Il y a 6 à 8 info-bulles sur cette page. Je sais que je peux placer des crochets de filtre pour chacun d'eux. Mais devrais-je?

Existe-t-il un inconvénient, un problème de performance lors de la pose de nombreux crochets?

filtershooksactions
7
Mayeenul Islam

Tant que les crochets ne sont pas accrochés, ils ne font rien, c'est presque rien et n'ont pas d'effet considérable sur l'exécution. Cela devient très différent lorsque les choses sont accrochées et qu'il y a beaucoup d'appels.

Puisque vous parlez de personnalisation de chaînes, le bon exemple serait gettext hook in core. Chaque chaîne localisée la traverse.

Donc en théorie c'est un crochet très flexible qui permet de filtrer du texte presque n'importe où. En pratique il peut déclencher des milliers de fois et si vous vous y accrochez sans réserve, le site complexe sera rapidement arrêté.

Vous ne couvrez pas suffisamment votre cas d'utilisation pour recommander une implémentation spécifique. En général, vous avez plusieurs choix pour organiser cela:

  • apply_filters( 'prefix_tooltip', $text ) est le cas de base, le filtre devrait déterminer si le texte correspond exactement pour déterminer le contexte, donc fragile.
  • L'argument supplémentaire apply_filters( 'prefix_tooltip', $text, 'type/location' ) vous permet de spécifier le type d'info-bulle que le filtre peut cibler. Ainsi, même si le texte change, le type l'identifie toujours.
  • apply_filters( 'prefix_tooltip_' . $type, $text ) nom de hook dynamique, qui change avec la valeur de la variable; c'est très flexible pour les cas de types nombreux/générés, le problème est principalement que les hooks dynamiques sont plus difficiles à découvrir dans le code et sont bien pires pour l'autodocumentation;
  • apply_filters( 'prefix_tooltips', $texts_array ) seul filtre pour compléter set des info-bulles utilisées.

Avec un nombre de 6 à 8 entrées, il n’y aura pas vraiment de différence de performance significative entre celles-ci.

Ce qui est important pour vous, c’est d’apprendre ici quelles approches sont et que vous devez choisir avec soin celle qui convient le mieux à chaque cas, pour qu’elle soit significative et pratique pour vous et les développeurs en aval.

6
Rarst

Il y a vraiment deux questions ici 1. Quel est l’impact d’un crochet? et 2. Si vous étendez juste des crochets partout

  1. L'impact est proche de zéro. Si rien n’est accroché à l’action/au filtre, les appels à do_action/apply_filters seront presque immédiatement renvoyés. Il n’y aura donc aucun impact notable sur les personnes qui n’utilisent pas le crochet et il n’est donc techniquement pas mauvais de les ajouter (si vous donnez toute raison semi raisonnable d’ajouter des crochets au noyau, cela sera probablement ajouté par le thème principal).

  2. Mais est-ce intelligent en tant que pratique de développement logiciel? Les crochets sont des API et les API signifient votre engagement à les maintenir sur le long terme. Par conséquent, comme toute API "officielle" que vous créez, vous devriez penser que c'est quelque chose de logique pour votre plugin à long terme et vous ne le faites pas simplement pour rendre un utilisateur de plugin heureux.

D'après votre description, si vous pensez qu'un texte doit être personnalisé, vous devriez peut-être envisager d'utiliser un type d'écran de paramètres pour cela. C'est évidemment aussi une sorte d'API, mais elle est plus visible et accessible pour les utilisateurs finaux.

3
Mark Kaplun

La personnalisation est toujours une pierre d'achoppement (processus douloureux). D'un côté, nous avons une réelle demande (problèmes) des utilisateurs qui compte toujours. D'autre part, toutes ces options supplémentaires peuvent transformer votre beau thème, plugin ou produit abstrait en diable. Alors, que pouvons-nous faire en tant que développeur?

Tout d'abord. Ecrit un code extensible avec possibilité de modifier certaines parties de votre code - code réutilisable. Les classes, les interfaces, les traits et juste diviser le code long-faux en petites méthodes (fonctions). Une partie des utilisateurs peut facilement les utiliser sans modifier votre produit. Par exemple, quelqu'un peut créer un widget avec ses propres besoins et utiliser la fonction please_echo_the_plugin_awesome_stuff() du plugin interne.

Ajouter les nouveaux filtres et actions n’est pas une mauvaise idée . De nombreux plugins populaires tels que Jetpack ou bbPress ont des centaines de filtres dans leur code. Parfois même excessivement. Chaque nouveau filtre (ou action) sans aucun gestionnaire ne génère généralement pas de temps système important. C'est une microseconde.

10 ^ −3 s milliseconde ms 10 ^ −6 s microseconde µs

Bien plus important est ce que vous faites dans cette action en ajoutant de nouveaux gestionnaires via add_action() ou add_filter(). Par exemple, les demandes adressées au serveur de base de données (parfois non évidentes, comme l’obtention de l’option non autoload par get_option()). Et vous pouvez le mesurer. L'exemple le plus simple:

$start = microtime(true);
// Do some stuff here
$end = microtime(true);
echo $start, PHP_EOL, $end, PHP_EOL, $end - $start, PHP_EOL,

C'est une technique très simple et parfois la mieux adaptée pour profiler votre code. En passant, WordPress a un "chronomètre" interne, checkout timer_start() et timer_stop().

Ou vous pouvez utiliser XDebug. Cela peut sembler très complexe à configurer. Mais vous pouvez utiliser VVV ou tout autre serveur prêt à l'emploi. Tous ont déjà configuré correctement Xdebug et vous pouvez simplement l'utiliser - ça sonne bien, n'est-ce pas ?. Si vous utilisez VVV, appuyez simplement sur quelques commandes:

vagrant ssh
xdebung_on

C'est tout! Basculez vers votre IDE et profilez votre code. Ou utilisez les services internes VVV tels que WebGrind. Pour en savoir plus sur ces techniques, consultez le site Code Débogage Wiki . N'oubliez pas que l'utilisation de Xdebug a un effet sur les performances, mais vous pouvez trouver du code lent (goulot d'étranglement).

Et troisième. La dernière chose. La philosophie de WordPress est Décisions, pas Options .

3
Kolya Korobochkin