web-dev-qa-db-fra.com

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

Dans le functions.php de mon thème, j'appelle un add_action afin d'obtenir un contrôle sur l'emplacement de chargement de jquery (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 plus pourquoi, mais je pense que add_action ('wp_enqueue_scripts') est préférable dans ce cas. Si c'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.

theme-developmentactions
9
N2Mystic

Beaucoup de développeurs de plugins ne font pas les choses correctement. La méthode right consiste à connecter wp_enqueue_scripts comme vous essayez de le faire.

Cependant, voici l'ordre des hooks dans une requête typique:

  • muplugins_loaded
  • taxe enregistrée
  • type_post enregistré
  • 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 parse
  • send_headers
  • parse_query
  • pre_get_posts
  • posts_selection
  • wp
  • template_redirect
  • get_header
  • wp_head
  • wp_enqueue_scripts
  • wp_print_styles
  • wp_print_scripts
  • ... beaucoup plus

Le fait est que plusieurs développeurs ont à l'origine été invités à se connecter à init pour la mise en file d'attente de leurs scripts. Avant, nous avions un hook 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 par ailleurs de bons développeurs.

Ma recommandation serait de diviser votre fonction en deux parties. Utilisez 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 les choses correctement" pour la mise en file d'attente de vos scripts et vous aidera à vous protéger des centaines de développeurs qui "continuent à faire des erreurs" en échangeant jQuery contre votre version concaténée avant de l'ajouter à la file d'attente. .

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

add_action( 'init', 'swap_out_jquery', 1 );
function swap_out_jquery() {
    // ...
}
25
EAMann

Il y a plusieurs problèmes ici, qui sont liés entre eux.

  1. Le hook d'action correct à 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 être emballés dans rien; laissez-les exécuter directement à partir de functions.php
  4. Vous devez placer votre is_admin() contrôles conditionnels dans votre rappel
  5. Vous ne devriez pas désenregistrer les scripts fournis par un noyau d'un thème, pour quelque raison que ce soit. Même si votre objectif est la concaténation de scripts, il s’agit du territoire du plugin .
  6. Si vous devez désinscrire jquery, alors wp_enqueue_scripts est trop tard . Divisez votre code de désenregistrement/enregistrement en un rappel relié à init.
  7. Appeler unautrescript "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é faible à votre rappel, afin de remplacer les plug-ins.
  9. Utilisez get_template_directory() plutôt que TEMPLATEPATH

Mettre tous ensemble:

<?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 principal - ou à utiliser des plug-ins qui ne font pas quelque chose d'aussi téméraire que de remplacer jQuery.

3
Chip Bennett