Quand utiliser add_action ('init') vs add_action ('wp_enqueue_scripts')

9

Dans le functions.php de mon thème, j'appelle une add_action afin d'obtenir un contrôle sur l'endroit où jquery est chargé (dans le pied de page avec les autres scripts de mon thème).

Le problème que je rencontre est que lorsque j'utilise add_action ('wp_enqueue_scripts'), il ne semble se déclencher que si aucun plug-in n'est chargé. Cependant, la méthode add_action ('init') fonctionne dans tous les cas.

Je ne me souviens pas pourquoi, mais je pense que add_action ('wp_enqueue_scripts') est préférable dans ce cas. Si cela est vrai, comment puis-je le faire fonctionner dans tous les cas?

  

Dans functions.php

//if(!is_admin()){add_action('init', 'my_theme_init');} //THIS WORKS ALL THE TIME
//add_action('wp_enqueue_scripts', 'my_theme_init'); //THIS ONLY WORKS WHEN NO PLUGINS PRESENT

if(!is_admin())
{
    require_once(TEMPLATEPATH . '/functions_public.php');   
}
  

Dans functions_public.php

function my_theme_init()
{

/* PREVENT DUPLICATE COPIES OF JQUERY FROM PLUGINS
**************************************************/
wp_deregister_script('jquery');

/* LOAD THE LOCAL WORDPRESS COPY OF JQUERY AND THEME CUSTOM SCRIPTS IN THE FOOTER
***********************************************/
wp_register_script('jquery', get_bloginfo('template_directory').'/scripts.mythemescripts.js',false,false,true);

wp_enqueue_script('jquery');

}

La deuxième méthode, qui utilise add_action ('wp_enqueue_scripts'), n'est apparemment pas exécutée dans les conditions où un plug-in est présent et écrit les dépendances de script dans le thème.

    
posée N2Mystic 20.06.2012 - 16:55

2 réponses

25

Beaucoup de développeurs de plugins ne font pas les choses correctement. Pour right , vous devez vous connecter à wp_enqueue_scripts comme vous essayez de le faire.

Cependant, voici l'ordre des hooks exécutés dans une requête typique:

  • muplugins_loaded
  • taxa_enregistré
  • type enregistré_post
  • plugins_loaded
  • sanitize_comment_cookies
  • setup_theme
  • load_textdomain
  • after_setup_theme
  • auth_cookie_malformed
  • auth_cookie_valid
  • set_current_user
  • init
  • widgets_init
  • register_sidebar
  • wp_register_sidebar_widget
  • wp_default_scripts
  • wp_default_stypes
  • admin_bar_init
  • add_admin_bar_menus
  • wp_loaded
  • demande de parse
  • send_headers
  • parse_query
  • pre_get_posts
  • posts_selection
  • wp
  • template_redirect
  • get_header
  • wp_head
  • scripts wp_enqueue
  • wp_print_styles
  • wp_print_scripts
  • ... beaucoup plus

Le fait est que, à l'origine, plusieurs développeurs avaient été invités à se connecter à init pour mettre leurs scripts en file d'attente. Auparavant, nous avions un crochet wp_enqueue_script . C’était la manière "correcte" de faire les choses, et des tutoriels perpétuant la pratique flottent toujours sur Internet, corrompant des développeurs autrement performants.

Ma recommandation serait de scinder votre fonction en deux parties. Faites votre wp_deregister_script / wp_register_script sur le hook init et utilisez le hook wp_enqueue_scripts lorsque vous mettez en file d'attente jQuery.

Cela vous gardera dans le monde du "faire correctement" pour la mise en file d'attente de vos scripts et vous aidera à vous protéger des centaines de développeurs qui "continuent à mal faire" en échangeant jQuery pour votre version concaténée avant de l'ajouter. à la file d'attente.

Vous voudrez également ajouter votre init hook avec une priorité élevée:

add_action( 'init', 'swap_out_jquery', 1 );
function swap_out_jquery() {
    // ...
}
    
réponse donnée EAMann 20.06.2012 - 17:38
3

Il existe plusieurs problèmes liés entre eux.

  1. Le crochet d'action à utiliser pour mettre en file d'attente les scripts est wp_enqueue_scripts
  2. Pour imprimer des scripts dans le pied de page via wp_enqueue_script() , définissez le paramètre $footer sur true .
  3. Vos appels add_action( $hook, $callback ) ne doivent pas être encapsulés; laissez-les exécuter directement à partir de functions.php
  4. Vous devez mettre vos is_admin() vérifications conditionnelles dans votre rappel
  5. Vous ne devez pas désenregistrer les scripts fournis par un noyau d'un thème, pour une raison quelconque. Même si votre objectif est la concaténation de scripts, il s’agit du territoire du plugin .
  6. Si vous devez annuler l'enregistrement de votre requête, wp_enqueue_scripts est trop tard . Divisez votre code de désenregistrement / enregistrement en un rappel relié à init .
  7. Appeler un autre script "jquery" n’est probablement pas une bonne pratique. Votre meilleur choix serait simplement de retirer de la file d'attente jQuery , puis de charger votre script personnalisé.
  8. Assurez-vous de donner une priorité basse à votre rappel, afin de remplacer les plug-ins
  9. Utilisez get_template_directory() plutôt que TEMPLATEPATH

Rassembler tout cela:

<?php
function wpse55924_enqueue_scripts() {
    if ( ! is_admin() ) {

        // Dequeue jQuery
        wp_dequeue_script( 'jquery' );

        // Register/enqueue a custom script, that includes jQuery
        wp_register_script( 'mythemescripts', get_template_directory_uri() . '/scripts.mythemescripts.js', false, false,true );
        wp_enqueue_script( 'mythemescripts' ); 
    }
}
add_action( 'wp_enqueue_scripts', 'wpse55924_enqueue_scripts', 99 );

Mais encore une fois: ce n’est vraiment pas la meilleure approche. Votre meilleur choix consiste simplement à supprimer les rappels de plug-ins add_action () qui annulent l'enregistrement de jQuery - ou à utiliser des plug-ins qui ne font rien de plus téméraire que le remplacement de jQuery fourni avec le noyau.

    
réponse donnée Chip Bennett 20.06.2012 - 17:50

Lire d'autres questions sur les étiquettes