Когда нужно использовать add_action ('init') vs add_action ('wp_enqueue_scripts')

В функции functions.php моей темы я вызываю add_action, чтобы получить контроль над тем, где загружается jquery (в нижнем колонтитуле вместе с другими сценариями моей темы).

Проблема, с которой я сталкиваюсь, заключается в том, что когда я использую add_action ('wp_enqueue_scripts'), он появляется только в том случае, если плагины не загружаются. Однако метод add_action ('init') работает во всех случаях.

Я не могу вспомнить, почему, но я считаю, что add_action ('wp_enqueue_scripts') является предпочтительным в этом случае. Если это правда, как я могу заставить его работать во всех случаях?

В 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'); } 

В 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'); } 

Второй метод, использующий add_action ('wp_enqueue_scripts'), по-видимому, не выполняется в условиях, когда присутствует плагин, который записывает зависимости сценария к теме.

Solutions Collecting From Web of "Когда нужно использовать add_action ('init') vs add_action ('wp_enqueue_scripts')"

Многие разработчики плагинов не делают все правильно. Правильный способ – подключиться к wp_enqueue_scripts как вы пытаетесь сделать.

Однако вот порядок выполнения крючков в типичном запросе:

  • muplugins_loaded
  • registered_taxonomy
  • registered_post_type
  • plugins_loaded
  • sanitize_comment_cookies
  • setup_theme
  • load_textdomain
  • after_setup_theme
  • auth_cookie_malformed
  • auth_cookie_valid
  • set_current_user
  • в этом
  • widgets_init
  • register_sidebar
  • wp_register_sidebar_widget
  • wp_default_scripts
  • wp_default_stypes
  • admin_bar_init
  • add_admin_bar_menus
  • wp_loaded
  • parse_request
  • send_headers
  • parse_query
  • pre_get_posts
  • posts_selection
  • в.ч.
  • template_redirect
  • get_header
  • wp_head
  • wp_enqueue_scripts
  • wp_print_styles
  • wp_print_scripts
  • … гораздо больше

Дело в том, что нескольким разработчикам изначально было предложено подключиться к init для включения их скриптов. Еще до того, как у нас был крючок wp_enqueue_script , это был «правильный» способ сделать что-то, и учебники, увековечивающие практику, все еще плавают в Интернете, развращая в противном случае хороших разработчиков.

Моя рекомендация состояла в том, чтобы разделить вашу функцию на две части. Сделайте свой wp_deregister_script / wp_register_script на крючке init и используйте wp_enqueue_scripts когда вы на самом деле ставите в очередь jQuery.

Это позволит вам в мире «сделать это правильно» для установки ваших сценариев и поможет защитить вас от сотен разработчиков, все еще «делая это неправильно», путем обмена jQuery для вашей конкатенированной версии, прежде чем добавить ее в очередь ,

Вы также захотите добавить свой крючок init с высоким приоритетом:

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

Здесь есть несколько проблем, связанных между собой.

  1. Правильный крючок действия для использования в сценариях wp_enqueue_scriptswp_enqueue_scripts
  2. Чтобы распечатать сценарии в нижнем колонтитуле через wp_enqueue_script() , установите для параметра $footer значение true
  3. Ваши add_action( $hook, $callback ) не должны быть обернуты ничем; пусть они выполняются непосредственно из functions.php
  4. Вы должны поместить свои условные проверки is_admin() внутри вашего обратного вызова
  5. По какой-то причине вы не должны отменить регистрацию сценариев с основным набором из Темы. Даже если ваша цель – конкатенация скриптов, это территория плагина .
  6. Если вы должны wp_enqueue_scripts регистрацию jquery, то wp_enqueue_scripts будет слишком поздно . Разделите свой код регистрации / регистрации на обратный вызов, подключенный к init .
  7. Вызов другого скрипта «jquery» также, вероятно, не является хорошей практикой. Ваша лучшая ставка просто заключалась бы в деактивации jQuery , а затем в загрузке вашего пользовательского скрипта.
  8. Не забудьте поставить низкий приоритет на ваш обратный вызов, поэтому вы переопределяете плагины
  9. Используйте get_template_directory() а не TEMPLATEPATH

Объединяя все это:

 <?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 ); 

Но опять же: это действительно не лучший подход. Ваша лучшая ставка заключается в том, чтобы просто удалить обратные вызовы add_action (), которые отменяет регистрацию ядра jQuery, или использовать плагины, которые не делают что-то настолько безрассудное, что заменяют jQuery, связанный с ядром.