Wann wird add_action ('init') vs add_action ('wp_enqueue_scripts') verwendet?

In der functions.php meines Themas rufe ich eine add_action auf, um ein gewisses Maß an Kontrolle darüber zu erlangen, wo jquery geladen wird (in der Fußzeile zusammen mit den anderen Skripten meines Themas).

Das Problem, das ich habe, ist, dass wenn ich add_action ('wp_enqueue_scripts') verwende, es nur dann ausgelöst wird, wenn keine Plugins geladen sind. Die Methode add_action ('init') funktioniert jedoch in allen Fällen.

Ich kann mich nicht erinnern warum, aber ich glaube, dass add_action ('wp_enqueue_scripts') in diesem Fall bevorzugt wird. Wenn das stimmt, wie kann ich es in allen Fällen zum Laufen bringen?

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

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

}

Die zweite Methode, die add_action ('wp_enqueue_scripts') verwendet, wird anscheinend nicht unter Bedingungen ausgeführt, unter denen ein Plugin vorhanden ist, das Skriptabhängigkeiten zum Thema schreibt.

Viele Plugin-Entwickler machen die Dinge nicht richtig. Der richtige Weg ist, sich anzuschließen, wp_enqueue_scriptswie Sie es versuchen.

Hier ist jedoch die Reihenfolge der Hooks, die in einer typischen Anforderung ausgeführt werden:

• muplugins_loaded
• registrierte_Taxonomie
• register_post_type
• plugins_loaded
• sanitize_comment_cookies
• setup_theme
• load_textdomain
• after_setup_theme
• auth_cookie_malformed
• auth_cookie_valid
• set_current_user
• drin
• 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
• ... eine Menge mehr

Die Sache ist, dass ursprünglich mehreren Entwicklern gesagt wurde, sie sollten sich anschließen, initum ihre Skripte in die Warteschlange zu stellen. Bevor wir einen wp_enqueue_scriptHaken hatten, war dies die "richtige" Art, Dinge zu tun, und Tutorials, die die Praxis fortsetzen, schweben immer noch im Internet herum und korrumpieren ansonsten gute Entwickler.

Meine Empfehlung wäre, Ihre Funktion in zwei Teile aufzuteilen. Machen Sie Ihr wp_deregister_script/ wp_register_scriptam initHaken und verwenden Sie den wp_enqueue_scriptsHaken, wenn Sie jQuery tatsächlich in die Warteschlange stellen.

Dies hält Sie in der Welt des "richtigen Handelns" für das Einreihen Ihrer Skripte und schützt Sie vor den Hunderten von Entwicklern, die es immer noch "falsch machen", indem Sie jQuery gegen Ihre verkettete Version austauschen, bevor sie es der Warteschlange hinzufügen .

Sie möchten auch Ihren initHaken mit einer hohen Priorität hinzufügen :

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

Hier gibt es mehrere Probleme, die miteinander zusammenhängen.

1. Der richtige Aktions-Hook zum Einreihen von Skripten ist wp_enqueue_scripts
2. Um Skripte in der Fußzeile über zu drucken wp_enqueue_script(), setzen Sie den $footerParameter auftrue
3. Ihre add_action( $hook, $callback )Anrufe sollten in nichts eingewickelt sein; Lassen Sie sie direkt von ausführenfunctions.php
4. Sie sollten Ihre is_admin()bedingten Prüfungen in Ihren Rückruf einfügen
5. Sie sollten Core-Bundle-Skripte aus irgendeinem Grund nicht von einem Theme abmelden. Selbst wenn Ihr Zweck die Skriptverkettung ist, ist dies das Gebiet des Plugins .
6. Wenn Sie müssen deregistrieren jquery, dann wp_enqueue_scriptsist zu spät . Teilen Sie Ihren Abmelde- / Registrierungscode in einen Rückruf auf, der angeschlossen ist init.
7. Einig Aufruf andere Skript „jquery“ ist auch wahrscheinlich keine gute Praxis. Ihre bessere Wahl wäre einfach, jQuery aus der Warteschlange zu entfernen und dann Ihr benutzerdefiniertes Skript zu laden.
8. Stellen Sie sicher, dass Ihr Rückruf eine niedrige Priorität hat, damit Sie Plugins überschreiben
9. Verwenden Sie get_template_directory()eher alsTEMPLATEPATH

Alles zusammen:

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

Aber nochmal: Dies ist wirklich nicht der beste Ansatz. Am besten entfernen Sie einfach die Rückrufe des Plugins add_action (), mit denen die Registrierung von Core-jQuery aufgehoben wird, oder verwenden Plugins, die nicht so rücksichtslos sind wie das Ersetzen von Core-Bundled-jQuery.