Quand utiliser quelle méthode de sortie de plugin?

Question

Je suis un développeur Drupal, je me lance dans Wordpress. Autant que je sache, il existe différentes méthodes permettant à un plugin de diffuser du contenu sur un site Wordpress:

• Petit code
• API de réécriture
• API de widget
• "Balise de modèle" (c'est-à-dire demandant aux utilisateurs d'appeler une fonction PHP de votre plugin dans leur thème)
• API d'actions

Lequel utilisez-vous et quand? Existe-t-il de bons articles couvrant un tel sujet?

Answer 1

Cela dépend fortement de ce dont vous avez besoin.

Réponse générale à la question

• L'API de réécriture effectue essentiellement toutes les opérations de réécriture d'URL.
• L'API Shortcode se veut une approche d'extension facile à utiliser pour les personnes qui souhaitent étendre leurs publications/contenus avec l'éditeur text/html. En guise d'alternative, vous utilisez/utilisez également les boutons de balises rapides de TinyMCE pour insérer le code court (calque au-dessus de la couche shortcode-abstraction-layer).
• L'API Widget est normalement utilisée pour créer de petits plug-ins qui vont dans dynamic_sidebar()s dans les modèles de thèmes, offrant ainsi une telle possibilité.
• L'API Actions/Filter (les actions sont des filtres de bas niveau) vous permet d'insérer ou de modifier tout élément de base/themes/plugins/widgets/muplugins/dropins offrant des filtres do_action()- ou apply_filter( 'name', $args_1, $args_etc )-. Vous pouvez les utiliser avec add_action( 'name', 'callback_function_name' ); (méthode de la classe: add_action( 'name', array( $this, 'callback_method_name' ) );).

Vous pouvez donc utiliser tout ce que vous voulez, mais vous devez essayer de le rendre aussi simple que possible pour l'utilisateur. Offrir des balises de modèle n'est généralement pas une bonne idée. Il est préférable d’attacher votre fonction principale à un point d’accès que l’utilisateur doit ajouter à son modèle: do_action( 'plugin_special_hook' );. De cette façon, vous éviterez les erreurs et les avertissements/avis au cas où votre plugin ne serait pas activé.

Si vous utilisez des widgets, vous disposez d'une interface utilisateur que l'utilisateur peut utiliser pour ajuster les options possibles.

Si vous utilisez les boutons Shortcodes ou TinyMCE, vous avez une autre possibilité d’ajuster la sortie.

Si vous avez des filtres ou des points d'ancrage, la sortie est générée sans implication des utilisateurs. Ou vous avez une page d'administration de l'API de configuration, où l'utilisateur peut ajuster la sortie.

L'API de réécriture n'a rien à voir avec ce qui a été mentionné ci-dessus - il ne s'agit pas de sortie, mais de demandes de routage.

Les noms sont juste pour l'organisation ... et les crochets

Les MU-Plugins viennent juste après les DropIns en ordre de chargement et ont accès au dernier hook muplugins_loaded. Ensuite, vous avez des plugins avec le hook plugins_loaded. Ensuite, il y a le hook after_setup_theme pour les plugins. Puis tout le reste suit avec init.

Normalement, la règle empirique consiste à déposer tout ce qui n'est pas une interface utilisateur dans un plugin. S'il a des options, utilisez un plugin normal, sinon utilisez un plug-in mu. Le reste entre dans un thème. Ou un thème enfant (possibilité de remplacer les fichiers de thèmes parents sans perdre les modifications apportées aux mises à jour du thème parent).

Remplacer les pièces principales

Si vous avez besoin de modifier une fonction pluggable.php, vous utilisez un DropIn. Astuce: Ne remplacez pas les plug-ins, car cela est généralement trop sujet aux erreurs.

APIs où que vous regardiez

Il y a aussi quelques autres API, comme par exemple la WP API HTTP, et autres . Assurez-vous de les utiliser, sinon le ciel vous tomberait sur la tête (tôt ou tard).