Use o wp init hook para chamar outros ganchos?

Quero saber se é uma boa prática de acordo com o tema WordPress ou o desenvolvimento de plugins.

add_action('init','all_my_hooks');

function all_my_hooks(){

// some initialization stuff here and then

add_action('admin_init',-----);
add_action('admin_menu',----);

// more like so

}

obrigado

— atinder
fonte

Respostas:

Em geral: Sim, aguarde um gancho dedicado para iniciar seu próprio código. Nunca basta lançar uma instância de objeto no espaço para nome global. Mas initraramente é necessário.

Você liga o mais tarde possível. Se o seu primeiro código for executado wp_head, não use um gancho anterior. Você pode até usar ganchos em cascata :

add_action( 'wp_head', 'first_callback' );

function first_callback()
{
    // do something
    // then
    add_action( 'wp_footer', 'second_callback' );
}

Em relação ao initgancho: use em wp_loadedvez disso. Isso é executado depois inite depois ms_site_check()foi chamado. Dessa forma, você evita executar seu plug-in em um subsite inválido em uma instalação de vários sites. Tudo o resto é o mesmo.

— fuxia
fonte

+1 para wp_loadede informações do MS.

— kaiser

muito obrigado pela sua resposta, ainda há uma dúvida, qual é melhor carregar todos os outros ganchos dentro do wp_loaded ou carregá-los separadamente? Gostaria de saber se eu adicionar ganchos em wp_loaded eles serão enganchados mais cedo em vez de serem enganchados após admin_init ou admin_menu?

— atinder 9/10/12

ganchos em cascata não é um problema?

— atinder

Não, por que deveria ser? Ligue para o segundo gancho somente se o primeiro foi útil.

— fuxia

Não vejo os grandes benefícios dessa prática, por estes motivos:

Suas funções de retorno de chamada não são chamadas ao registrar

As funções add_actione add_filteradicionam apenas uma entrada à variável global $wp_filterque contém todos os filtros e ações. Veja fonte . Não chama sua função. Seu código será executado somente quando o do_actione apply_filtersfor chamado (com o nome apropriado do gancho), o que acontece muito tarde no local em que esses ganchos devem estar.

Você pode dizer que isso fará com que a variável global $wp_filterfique maior => mais memória necessária. Mas acho que criar uma nova função tem o mesmo problema.

Código organizador

Colocar tudo em uma função obriga a lembrar todos os ganchos em todos os arquivos do seu tema / plugin. Você não faria algo assim:

in header.php: adicione ganchos e funções de retorno de chamada para que as coisas aconteçam no cabeçalho (como menu, script de registro)
in content.php: adicione ganchos e funções de retorno de chamada para filtrar conteúdo
admin-menu.php: adicione ganchos e funções de retorno de chamada para adicionar o menu de administração

(suponha que esses arquivos sejam colocados no seu tema / plugin)

Em vez disso, você deve:

colocar apenas funções de retorno de chamada em header.php, content.php,admin-menu.php
e colocar todos os ganchos em uma função separada em outro arquivo

=> Isso tornará difícil saber o que acontece quando você analisa o conteúdo do header.phparquivo. Você precisa pesquisar para saber quando esses retornos de chamada são acionados.

E pense na situação quando você tiver várias classes no seu tema / plugin. Você coloca todos os ganchos de todas as classes em um só lugar? Ou cada classe possui uma função de invólucro que contém todos os ganchos? É muito redundante!

Acima desse motivo, acho que é estilo pessoal :). Vejo alguns frameworks como o Hybrid que faz o que você disse. Às vezes, é difícil me aprofundar nessas estruturas!

— Anh Tran
fonte