私はWP docsを読みました。 この要旨を示しました _ IEのスタイルをエンキューする正しい方法は$wp_styles
を使うことです。これはスクリプトにも当てはまると思います。
オプション1 - wp_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' );
} );
オプション2 - wp_scripts
とis_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' );
}
} );
オプション3 - 頭の中でそれをエコーするだけです:
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";
});
オプション4 - 先頭にエンキューする:
add_action('wp_print_scripts', function(){
wp_enqueue_script( 'html5shiv', 'https://oss.maxcdn.com/html5shiv/3.7.2/html5shiv.min.js', array( 'bootstrap' ) );
});
2番目の選択肢IE以外のブラウザでは少しきれいに見えるので、かっこいいようです。しかし、実際に速度上の利点があるのか、それともチェックだけで速度がさらに遅くなるのかはわかりません。それ以外は、オプション1がオプション3または4よりも優れている理由を理解できないようです。
私はGenesisフレームワークを使用しています、そして それらはHTML5shivを含んでいます 以下の例のように/私には正しくないようです:
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";
}
wp_scripts()
を使用できる場合に @gmazzap を使用してグローバルを使用しないという提案を拡張するには、wp_script_add_data
という条件付きコメントを追加するためのwp_scripts()
、および条件付きスタイル用のwp_style_add_data
のショートカットがあります。
/**
* 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');
ただし、上記の例ではHTML5shivを使用していますが、これは特有の状況です。 は を頭にロードする必要があるので、 Roots Soil のようなプラグインが心配な場合は次の例のようにすることができます。/ /頭からすべてのスクリプトを削除します。
たぶん、あなたはこのような状況に遭遇しないでしょう。頭の中でロードするには多くのスクリプトが必要とされるため、これは非常に不安定なことです。スクリプトをフッターに入れるには、スクリプトをエンキューするときに $in_footer
変数をtrueに設定します。そのため、もしあなたがその問題に対してルートやキャッシュプラグインを使用するのであれば、箱から出してすぐに欲しい方法をすべて実行することを計画しないでください。
これはあなたができることの醜い例です:
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";
}
これはやり過ぎですが、それでもまだ機能することを保証するものではありません。過去4年間でhtml5shivは、いくつかの異なるハンドル(html5、html5shiv、html5shim、themename-html5shiv、html5-ie-fix、およびhtml5-polyfill just)を使用して登録/エンキューされた多くの名前を使用してきました。いくつか挙げると)。加えて、しばしば modernizrにバンドルされています 。そのことを念頭に置いて、上記の例がばかげていると思うなら、プラグインhtml5shivハンドルはおそらく何か他の名前を付けるので、あなたはあなたの子供のテーマでwp_head
にスクリプトを追加するだけでうまくいきません。
これは Roots/Soil Githubページでいくつかの行動を引き起こしました。おそらくこれが( @grappler で示唆されているように)これを実行し、それでもスクリプトをフッターに移動するための最善の方法です。同様のアプローチが @ kaiser's blog に数年前に投稿されました。
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 );
Mark Kaplanが提案したこと、そしてここで述べたtoscho、 に関しては、オプション2の$ is_IEメソッド を使うべきではありません。明らかに、HTTPヘッダVary:User-Agentが送信されないと、間違った出力をキャッシュの背後にいるユーザに送信して、それらのユーザにとっては壊れてしまうでしょう。ブラウザ側での検出に関して これは長いスレッドの例です それがどのように行われるかもしれないかについて。クライアント側の検出でも落とし穴があります。
Microsoftは1月12日の時点でそれらのサポートをやめたため - Microsoftはこれらの方法のどれも使わないで、古いブラウザを忘れるのが最善の解決策かもしれない。
そして5つ目の選択肢は、Google AnalyticsやFB SDKのように、クライアント側でそれがどのブラウザであるかを検出し、スクリプトのスクリプト要素を直接DOMに作成することです。
これには、ブラウザ検出を行うべき唯一の場所であるブラウザ検出、および必要な場合にのみIE特定のスクリプトのロードを実行するという利点があります。
精神的には、これはあなたの3番目の選択肢と非常によく似ていますが、より一般的です。
サイドノート:is_IE
は他のすべてのサーバーサイドブラウザ検出と同様にキャッシングを壊すので避けるべきです。
一般的に言って、スクリプトやスタイルは決してページに直接印刷されるべきではありません。
その理由は、別のプラグインまたはテーマが同じスクリプトを再度追加する可能性があり、同じスクリプトが2回以上追加されることです。
適切な方法でアセットをエンキューした場合、他のコードが同じアセットを再度エンキューした場合は、一度追加されます。
このため、オプション3と4はスキップしてください。
オプション2に関しては、 Mark Kaplun 指摘された のように、それはサーバサイドのブラウザ検出を利用します。ブラウザのバージョン、そしてあなたの場合それはそれを必要としない最新のIEバージョンでさえスクリプトを含みます。
したがって、実際には、選択肢1が、あなたが提案した選択肢の中で最も優れています。
私がするだろう唯一の変更:
'wp_enqueue_scripts'
の代わりに'wp_print_scripts'
アクションを使うwp_scripts()
functionを使用する何かのようなもの:
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' );
} );
そのようにして、別のプラグインが'html5shiv'
スクリプトを再度エンキューする場合、それは一度だけ追加されます。
上記のスニペットを使用して、ページに印刷されるものは以下のとおりです。
<!--[if lt IE 9]>
<script type='text/javascript' src='https://oss.maxcdn.com/html5shiv/3.7.2/html5shiv.min.js'></script>
<![endif]-->
この条件はブラウザ(クライアント側)で解析され、サーバ側では解析されないため、手頃な価格でターゲットにするIEバージョンにのみスクリプトを追加できます。
クライアントプラットフォーム(OS、画面の種類と解像度、ブラウザの特定の詳細バージョンなど)についてもっと知る必要がある場合は、javascriptを使用してこの詳細を傍受し、スクリプトをDOMに動的に追加するしかありません。 Mark Kaplun solution)しかし、 "ブラウザファミリ"とメジャーバージョンを知っていれば十分な場合は、このソリューションを使用することをお勧めします。