Quando usar add_action ('init') vs add_action ('wp_enqueue_scripts')

Question

Quando usar add_action ('init') vs add_action ('wp_enqueue_scripts')

#1 resposta do EAMann (25 votos)
#2 resposta do Chip Bennett (3 votos)

9

No functions.php do meu tema, estou chamando um add_action para obter uma medida de controle sobre onde o jquery é carregado (no rodapé junto com os outros scripts do meu tema).

O problema que estou tendo é que quando eu uso add_action ('wp_enqueue_scripts'), ele só aparece para disparar se nenhum plugin for carregado. No entanto, o método add_action ('init') funciona em todos os casos.

Não me lembro por quê, mas acredito que add_action ('wp_enqueue_scripts') seja preferido neste caso. Se isso for verdade, como posso fazê-lo funcionar em todos os casos?

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

Em 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');

}

O segundo método, usando add_action ('wp_enqueue_scripts'), aparentemente não é executado em condições em que existe um plugin que grava dependências de script no tema.

theme-development actions

por N2Mystic 20.06.2012 / 16:55

2 respostas

3

Existem vários problemas aqui, inter-relacionados.

O gancho de ação correto a ser usado para enfileirar scripts é wp_enqueue_scripts
Para imprimir scripts no rodapé via wp_enqueue_script() , defina o parâmetro $footer como true
Suas chamadas add_action( $hook, $callback ) não devem ser agrupadas em nada. deixe-os executar diretamente de functions.php
Você deve colocar suas verificações condicionais is_admin() dentro do seu retorno de chamada
Você não deve cancelar o registro de scripts do pacote principal de um tema, por qualquer motivo. Mesmo que sua finalidade seja a concatenação de scripts, esse é o território do plug-in .
Se você precisar cancelar o registro do jquery, então wp_enqueue_scripts é tarde demais . Divida seu código de registro / cancelamento de registro em um retorno de chamada conectado a init .
Chamar algum outro script "jquery" provavelmente não é uma boa prática. Sua melhor aposta seria simplesmente remover a fila do jQuery e carregar seu script personalizado.
Certifique-se de colocar uma prioridade baixa no seu retorno de chamada, para substituir os plug-ins
Use get_template_directory() em vez de TEMPLATEPATH

Colocando tudo junto:

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

Mas novamente: essa não é a melhor abordagem. Sua melhor aposta é simplesmente remover plug-ins callbacks de add_action () que cancelam o registro do jQuery principal - ou usar Plugins que não fazem algo tão imprudente como substituir o jQuery principal.

por Chip Bennett 20.06.2012 / 17:50

Tags theme-development actions

Como adicionar espaço reservado para o formulário de contato7 para o menu suspenso? [fechadas] Contando o número de posts (tipo de post personalizado) Problemas de consulta

score 25 · Accepted Answer

Muitos desenvolvedores de plug-ins não fazem as coisas da maneira certa. A maneira correta é ligar a wp_enqueue_scripts como se você estivesse tentando fazer.

No entanto, aqui está a ordem dos ganchos executados em uma solicitação típica:

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
init
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
wp
template_redirect
get_header
wp_head
wp_enqueue_scripts
wp_print_styles
wp_print_scripts
... muito mais

O problema é que vários desenvolvedores foram instruídos a usar init para enfileirar seus scripts. Antes que tivéssemos um gancho wp_enqueue_script , essa era a maneira "correta" de fazer as coisas, e os tutoriais que perpetuam a prática ainda estão circulando na Internet, corrompendo desenvolvedores bons.

Minha recomendação seria dividir sua função em duas partes. Faça seu wp_deregister_script / wp_register_script no gancho init e use o gancho wp_enqueue_scripts quando você realmente enfileira o jQuery.

Isso o manterá no mundo de "fazer certo" para enfileirar seus scripts, e ajudará a proteger você das centenas de desenvolvedores que ainda estão "fazendo algo errado" ao trocar o jQuery pela sua versão concatenada antes de adicioná-lo para a fila.

Você também deseja adicionar seu gancho init com uma prioridade alta:

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