WordPressのwp_add_inline_scriptは外部fileの依存関係を決めてから使う

WordPressでinline JavaScriptを追加するときは、どの外部scriptの前後で動かすかを先に決めます。wp_add_inline_script()は、登録またはenqueueしたscriptに関連する短いJavaScriptを追加するためのfunctionです。page内へscript tagを散らすための近道ではありません。

WordPress 4.5 Beta 1の公式案内は、script loaderの変更としてwp_add_inline_script()を導入し、wp_add_inline_style()と同様にinline JavaScriptを扱えること、scriptのheaderとfooterのdependency supportが改善されることを案内しています。beta版は本番siteで使わずtest siteで試します。

このfunctionを使う場面では、どのscriptに関連する設定なのかを先に決めます。例えば、sliderを動かす外部fileに必要な画像URLや表示枚数を渡すなら、そのslider用のscript handleへ関連付けます。別のpageで使うlibraryや共通のanalytics scriptへ無関係な設定を足すと、後から何のための値か分からなくなります。inline scriptの短さではなく、外部fileとの関係が追えることを優先します。

また、WordPressがscriptを管理するhandleと、browserが読み込むfile名は同じ意味ではありません。handleはWordPress側で依存関係を指定するための名前です。file名を変えた、versionを変えた、読み込み場所をheaderからfooterへ変えたという変更は、それぞれ別に確認します。画面でJavaScriptが動いたとしても、どのhandleがどのfileを出したかが分からなければ、次の更新で重複して読み込むことがあります。

設定値と処理を同じscriptへ詰め込まない

inline JavaScriptには、theme固有のURL、表示条件、短い初期設定などを渡す場面があります。画面を動かす処理そのものまで長く書くと、どのfileを直せばよいか分からなくなります。

例えば外部fileがwindow.siteConfigを読んでから動くなら、その値を作るinline scriptは外部fileより前に必要です。逆に、外部fileで作ったfunctionを呼ぶなら、呼び出しは後ろに置きます。どちらも同じに見えますが、実行順が逆です。

実行順を確認するときは、設定値だけを見ません。外部fileが読み込むlibrary、外部file本体、inline scriptの三つを順に書きます。libraryが先に必要なのに後から出れば、外部fileは動きません。設定値を先に作る必要があるのに後へ出れば、外部fileは空の値で始まります。外部fileが作ったfunctionを呼ぶinline scriptを前へ出せば、functionがまだ存在しません。errorの文言だけを直すのではなく、何が先に必要かを追います。

一つのpageだけで使うscriptは、そのpageだけで出します。全pageへ出すと、関係のない画面でerrorが出たり、同じ名前の設定が他のpluginと重なったりします。投稿pageだけ、問い合わせpageだけ、特定のtemplateだけという条件があるなら、PHP側で対象を分けます。コードを一つにまとめるために、不要なscriptまで全体へ送らないようにします。

test siteで一つずつ確認する

1. 外部fileが先に必要とする値と、読み込み後に実行する処理を分ける。
2. script handleとdependencyを記録する。
3. test siteで対象pageを開き、browser consoleのerrorを確認する。
4. scriptを使うpageと使わないpageの両方を開く。
5. headerとfooterのどちらで読み込まれるかを確認する。

scriptの変更を外部へ頼む場合も、theme file、plugin、管理画面のどこがscriptを出しているかを残します。URLを一つ直す作業でも、同じ設定が複数のfileに散れば、次の更新で食い違います。

test siteでは、scriptを使うpageだけでなく、使わないpageも開きます。対象pageで動くことを確認しても、共通のheaderやfooterへ出しているscriptが他のpageでerrorを起こす場合があります。逆に、対象外のpageでscriptが出ていなければ、条件分岐が意図どおりに働いているかを確認できます。scriptを追加したことではなく、必要な場所だけで必要な順に動くことを確認します。

browser consoleにerrorが出たときは、内容を消す前にURL、操作、どのpageで出たかを残します。設定値がないのか、libraryがないのか、外部fileが二回出ているのかで、直す場所は違います。consoleを見ずにinline scriptを追加して動かしたように見せると、元の読み込み順の問題が残ります。testで再現できる状態を作り、変更を一つずつ戻して確認します。

inline scriptをcache対策だけに使わない

JavaScriptの更新が反映されない問題は、file名、version、browser cache、読み込み順など複数の理由で起きます。inline scriptを足して見かけ上動かしても、元の外部fileをどの版で読み込んでいるか分からなければ、保守できません。

cacheの問題と実行順の問題も分けます。古いfileがbrowserへ残っているなら、正しい順番でscriptを出していても、以前の処理が動きます。反対に新しいfileが届いていても、設定値やlibraryの順番が違えばerrorになります。どちらかを直すための変更を、もう一方の原因の説明に使わないようにします。確認時には、読み込まれたfileのversion、consoleのerror、設定値が出る順番を別に記録します。

作業を引き継ぐときは、script handle、外部file、dependency、page条件、inlineで渡す値、出力する前後の順番を一覧にします。管理画面の設定だけを変えればよいのか、themeのPHPを直すのか、外部JavaScriptを直すのかが分かれば、小さな修正で別のpageを壊しにくくなります。設定を一か所へ寄せることと、処理を一fileへ詰め込むことを混同しません。

最初の一手は、対象pageで読み込まれる外部scriptを一つ選び、必要な設定値、dependency、実行順を三行で書くことです。それが決まってからwp_add_inline_script()を使います。