Jeder Vorteil der Verwendung von wp_scripts und is_IE beim Einreihen von Skripten


7

Ich habe in den WP-Dokumenten gelesen, die darauf hinwiesen, dass der richtige Weg, Stile für den IE in die Warteschlange zu stellen , die Verwendung von ist $wp_styles. Ich vermute, dass dies dann auch für Skripte gilt.

Nehmen Sie diese Beispiele zum Beispiel ...

Option Eins - Verwendenwp_scripts

add_action('wp_print_scripts', function() {
    global $wp_scripts;
    wp_enqueue_script( 'html5shiv', 'https://oss.maxcdn.com/html5shiv/3.7.2/html5shiv.min.js', array( 'bootstrap' )  );
    $wp_scripts->add_data( 'html5shiv', 'conditional', 'lt IE 9' );
} );

Option Zwei - Verwenden Sie wp_scriptszusammen mitis_IE

add_action('wp_print_scripts', function() {
    global $wp_scripts, $is_IE;
    if($is_IE) {
        wp_enqueue_script( 'html5shiv', 'https://oss.maxcdn.com/html5shiv/3.7.2/html5shiv.min.js', array( 'bootstrap' )  );
        $wp_scripts->add_data( 'html5shiv', 'conditional', 'lt IE 9' );
    }
} );

Option Drei - Echo es einfach im Kopf:

add_action('wp_head', function(){
    echo '<!--[if lt IE 9]><script src="https://oss.maxcdn.com/html5shiv/3.7.2/html5shiv.min.js"></script><![endif]-->' . "\n";
});

Option 4 - In die Warteschlange einführen:

add_action('wp_print_scripts', function(){
        wp_enqueue_script( 'html5shiv', 'https://oss.maxcdn.com/html5shiv/3.7.2/html5shiv.min.js', array( 'bootstrap' )  );
});

Die zweite Option. scheint cool zu sein, weil es in Nicht-IE-Browsern etwas sauberer aussieht. Aber ich bin mir nicht sicher, ob es tatsächlich einen Geschwindigkeitsvorteil hat oder ob die Prüfung allein ihn mehr verlangsamt. Abgesehen davon kann ich keinen Grund herausfinden, warum Option eins besser ist als Option 3 oder 4.


Der Grund für diese Frage

Ich verwende das Genesis-Framework und sie enthalten HTML5shiv wie das folgende Beispiel, das mir einfach nicht richtig erschien:

add_action( 'wp_head', 'genesis_html5_ie_fix' );
/**
 * Load the html5 shiv for IE8 and below. Can't enqueue with IE conditionals.
 */
function genesis_html5_ie_fix() {
    if ( ! genesis_html5() )
        return;
    echo '<!--[if lt IE 9]><script src="//html5shiv.googlecode.com/svn/trunk/html5.js"></script><![endif]-->' . "\n";
}

Antworten:


5

Um den @ gmazzap- Vorschlag zu erweitern, keine Globals zu verwenden, wenn Sie ihn verwenden können wp_scripts(), gibt es eine Verknüpfung wp_scripts()zum Hinzufügen von aufgerufenen bedingten Kommentaren wp_script_add_dataund ebenfalls wp_style_add_datafür bedingte Stile.

Die korrekte Verwendung von Bedingungen ab Wordpress 4.2 lautet also wie folgt:

/**
 * IE enqueue HTML5shiv with conditionals
 * @link http://tiny.cc/html5shiv
 */
function wpse_213701_enqueue_html5shiv()  {
    wp_enqueue_script( 'html5shiv',
        'https://oss.maxcdn.com/html5shiv/3.7.2/html5shiv.min.js',
        array(),
        false,
        false
    );
    wp_script_add_data( 'html5shiv', 'conditional', 'lt IE 9' );
}
add_action('wp_enqueue_scripts', 'wpse_213701_enqueue_html5shiv');

Im obigen Beispiel wird jedoch HTML5shiv verwendet, was eine einzigartige Situation darstellt. Da es in den Kopf geladen werden muss, können Sie im nächsten Beispiel so etwas tun, wenn Sie sich Sorgen machen, dass ein Plugin wie Roots Soil alle Skripte aus dem Kopf entfernt.


Höchstwahrscheinlich werden Sie jedoch nicht in eine solche Situation geraten. Dies ist sehr instabil, da viele Skripte zum Laden in den Kopf erforderlich sind. Das Einfügen von Skripten in die Fußzeile sollte erfolgen, indem die $in_footerVariable beim Einreihen von Skripten auf true gesetzt wird. Wenn Sie also Roots oder ein Cache-Plugin verwenden, planen Sie nicht, dass alles genau so funktioniert, wie Sie es möchten.

Hier ist ein hässliches Beispiel dafür, was Sie tun können:

add_action( 'wp_head', 'wpse_213701_check_html5shiv', 1 );
function wpse_213701_check_html5shiv() {
    remove_action( 'wp_head', 'genesis_html5_ie_fix' );
    if ( !has_filter( 'wp_head', 'wp_enqueue_scripts' ) && !wp_script_is( 'html5shiv', 'done' ) ) {
        add_action('wp_head', 'wpse_213701_echo_html5shiv');
        wp_dequeue_script('html5shiv');
    }
}
function wpse_213701_echo_html5shiv() {
    echo '<!--[if lt IE 9]><script src="https://oss.maxcdn.com/html5shiv/3.7.2/html5shiv.min.js"></script><![endif]-->' . "\n";
}

Dies ist jedoch übertrieben und es ist immer noch keine Garantie dafür, dass es funktioniert. In den letzten 4 Jahren hat html5shiv viele Namen angenommen, was dazu geführt hat, dass es mit verschiedenen Handles registriert / in die Warteschlange gestellt wurde (html5, html5shiv, html5shim, Themenname-html5shiv, html5-ie-fix und html5-polyfill, um nur einige zu nennen ). Darüber hinaus wird es häufig mit modernizr gebündelt . Wenn Sie das obige Beispiel für lächerlich halten, sollten Sie das Skript wp_headin Ihrem untergeordneten Thema hinzufügen, da ein Plugins- HTML5shiv- Handle höchstwahrscheinlich einen anderen Namen trägt.

Update (Verschieben von Skripten in die Fußzeile mit diesem Ansatz):

Dies löste einige Aktionen auf der Roots / Soil Github-Seite aus. Hier ist wahrscheinlich der beste Weg, dies zu tun (wie von @grappler vorgeschlagen ) und trotzdem Skripte in die Fußzeile zu verschieben. Ein ähnlicher Ansatz wurde vor einigen Jahren auf @ kaisers Blog veröffentlicht .

function grappler_move_js_to_footer() 
    $scripts = wp_scripts();
    foreach( $scripts->registered as $script ) {
        if ( 'html5' == $script->handle ) {
            wp_script_add_data( $script->handle, 'group', 0 );
        } else {
            wp_script_add_data( $script->handle, 'group', 1 );
        }
    }
}
add_action( 'wp_enqueue_scripts', 'grappler_move_js_to_footer', 99 );

Was Mark Kaplan vorschlägt und was hier erwähnt wird , sollten Sie nicht die $ is_IE-Methode von Option 2 verwenden . Wenn der HTTP-Header Vary: User-Agent nicht gesendet wird, senden Sie anscheinend die falsche Ausgabe an Benutzer hinter einem Cache, wodurch diese für diese Benutzer unterbrochen wird. In Bezug auf die browserseitige Erkennung finden Sie hier eine lange Reihe von Beispielen, wie dies getan werden könnte. Sogar die clientseitige Erkennung hat ihre Tücken.


Letztendlich ist es vielleicht die beste Antwort, keine dieser Methoden zu verwenden und ältere Browser zu vergessen, da Microsoft die Unterstützung für sie ab dem 12. Januar eingestellt hat .


3
Vergessen Sie ältere Browser, da Microsoft die Unterstützung für sie ab dem 12. Januar eingestellt hat . Ich dachte, das würde niemals passieren. Kein Mist mehr, der Dinosaurier unterstützen muss, JA !!!!
Pieter Goosen

4

Und Option 5 besteht darin, auf der Clientseite zu erkennen, um welchen Browser es sich handelt, und ein Skriptelement für Ihr Skript direkt im Dom zu erstellen, wie dies bei Google Analytics und einem FB SDK der Fall ist.

Dies hat den Vorteil, dass die Browsererkennung nur an der Stelle durchgeführt wird, an der dies erfolgen soll, nämlich im Browser, und dass die IE-spezifischen Skripte nur bei Bedarf geladen werden.

Im Geiste ist es Ihrer dritten Option sehr ähnlich, nur allgemeiner.

Nebenbemerkung: is_IEWie bei allen anderen serverseitigen Browsern sollte die Erkennung vermieden werden, da sie das Caching unterbrechen .


4

Im Allgemeinen sollten Skripte und Stile niemals direkt auf eine Seite gedruckt werden.

Der Grund dafür ist, dass ein anderes Plugin oder Thema möglicherweise dasselbe Skript erneut hinzufügt und Sie dasselbe Skript mindestens zweimal hinzufügen.

Wenn Sie das Asset ordnungsgemäß in die Warteschlange stellen und ein anderer Code dasselbe Asset erneut in die Warteschlange stellt, wird es einmal hinzugefügt.

Aus diesem Grund sollten Sie die Optionen 3 und 4 überspringen.

2 in Bezug auf Option, wie Mark Kaplun wies darauf hin , macht es die Verwendung von serverseitigen Browser - Erkennung, die nie sehr erschwinglich, und auch wenn es würde ist, lassen Sie nicht die Version des Browsers und in Ihrem Fall wählen sie gehören das Skript auch in modernen IE-Versionen, die es nicht brauchen.

Tatsächlich ist die Option 1 die beste unter den von Ihnen vorgeschlagenen.

Die einzigen Änderungen, die ich vornehmen würde:

  • Verwenden Sie 'wp_enqueue_scripts'Aktion anstelle von'wp_print_scripts'
  • Verwenden Sie die wp_scripts()Funktion, anstatt auf global zuzugreifen

Etwas wie:

add_action('wp_enqueue_scripts', function() {
    wp_enqueue_script(
       'html5shiv',
       'https://oss.maxcdn.com/html5shiv/3.7.2/html5shiv.min.js',
       array( 'bootstrap' ),
       '3.7.2',
       false
    );
    wp_scripts()->add_data( 'html5shiv', 'conditional', 'lt IE 9' );
} );

Wenn Sie ein anderes Plugin-Enqueue- 'html5shiv'Skript erneut verwenden, wird es nur einmal hinzugefügt.

Beachten Sie, dass mit dem obigen Snippet Folgendes gedruckt wird:

<!--[if lt IE 9]>
<script type='text/javascript' src='https://oss.maxcdn.com/html5shiv/3.7.2/html5shiv.min.js'></script>
<![endif]-->

Diese Bedingung wird vom Browser (Client-Seite) und nicht vom Server analysiert. Sie ist daher erschwinglich und ermöglicht es Ihnen, das Skript nur für die IE-Version hinzuzufügen, auf die Sie abzielen möchten.

Wenn Sie mehr über die Client-Plattform wissen möchten (Betriebssystem, Bildschirmtyp und Auflösung, spezifische detaillierte Version des Browsers ...), können Sie diese Details nur mit Javascript abhören und das Skript dynamisch zum DOM hinzufügen (gemäß) Mark Kaplun- Lösung), aber wenn Ihnen die Kenntnis der "Browser-Familie" und der Hauptversion ausreicht, ist mein Vorschlag, diese Lösung zu verwenden.


Danke für die gut erklärte Antwort! Das einzige, was ich mich frage, ist, wovon der Nutzen vorbei wp_enqueue_scriptsist wp_enqueue_scripts. Der einzige Grund, den ich verwendet habe, wp_print_scriptswar, dass es später geladen wurde, ähnlich wie es Bootstrap macht.
Bryan Willis

1
@BryanWillis wp_enqueue_scriptsist der Standard-Hook zum Einreihen von Assets. Bei wp_print_scriptsBränden sollten alle Skripte bereits in der Warteschlange stehen, und andere Plugins können dies annehmen. Nehmen Sie zum Beispiel github.com/roots/soil . Eines seiner Module verschiebt alle Skripte in die Fußzeile. Zu diesem wp_print_scriptsZweck werden Aktionen vollständig entfernt , vorausgesetzt, alle Skripte befinden sich in der Warteschlange wp_enqueue_scripts. Ihr Code ist mit diesem Plugin nicht kompatibel. Verwenden Sie daher, insbesondere wenn Sie Ihren Code teilen / verkaufen möchten, immer Standard-Hooks, um die Kompatibilität zu verbessern.
gmazzap

das macht definitiv Sinn. Ironischerweise war der Boden einer der Gründe, warum ich diese Frage gestellt habe, weil er diesen Code tatsächlich bricht. Damit htm5shiv ordnungsgemäß funktioniert, muss es irgendwo zwischen dem öffnenden und dem schließenden </head>Tag geladen werden . Ich persönlich benutze seit einigen Jahren Erde, abzüglich der soil-js-to-footerThemenunterstützung, da dies häufig Probleme verursacht, wenn ein Skript in den Kopf geladen werden soll.
Bryan Willis

Dies wurde nur in Erde erzogen, würde gerne Ihre Meinung hören. github.com/roots/soil/issues/33
Bryan Willis
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.