WordPressのjQuery更新では警告を消す前にthemeとpluginの呼出元を確認する

WordPressを更新したあとにjQuery Migrateの警告が出たら、警告表示だけを消してはいけません。まず、どのthemeまたはpluginのscriptが古い呼出しを使っているかを確認します。警告は、今すぐpageが壊れていない場合でも、次の更新で問題になる箇所を知らせる手掛かりです。

WordPressの公式開発者向け案内は、WordPress 4.5でjQueryを1.11.3から1.12.2へ、jQuery Migrateを1.2.1から1.4.0へ更新したと説明しています。非圧縮版のjQuery Migrateでは、以前より多くのwarningが出るため、themeとpluginを試すよう案内しています。

warningを見つけたときに必要なのは、古いcodeを見つけたという事実と、siteのどの仕事に影響するかを結び付けることです。トップpageで出るwarningと、管理画面で投稿を保存したときに出るwarningでは、先に確かめる操作が違います。consoleの一行だけを見て修正すると、表示が戻っても問い合わせや画像uploadのような実務の操作が止まることがあります。

WordPress本体の更新後に警告が現れた場合でも、原因がWordPress本体にあるとは限りません。以前からtheme、plugin、外部serviceが使っていた呼出しが、新しいjQuery Migrateで見えるようになった可能性があります。更新を戻すか、scriptを直すか、pluginを更新するかは、呼出元が分かってから決めます。警告の数だけを減らすことを目的にしません。

warningの表示と壊れている場所は同じではない

jQuery Migrateは、古くなったAPIを使うscriptを見つけ、互換性を補う役割を持ちます。warningが出ても、その場で動作が止まるとは限りません。ただし、warningが出たscriptを放置すると、jQuery Migrateが補わなくなったときに、buttonやformの動作が止まるおそれがあります。

確認する順番は、画面の目立ち方ではなく、呼出元で分けます。

警告の文面だけを検索して、最初に見つかったcodeを貼り替える方法は採りません。同じ呼出しでも、theme、plugin、外部serviceでは直す人と更新方法が違うためです。

自作themeにあるscriptなら、source file、読み込まれるpage、変更した人を確認します。pluginに含まれるscriptなら、plugin fileを直接書き換える前に、対応する更新があるか、開発元へ伝える情報は何かを見ます。直接直せば一時的にwarningが消えても、次のplugin更新で変更が消えることがあります。外部serviceのscriptなら、契約中のserviceを止められるか、更新を待つか、読み込みを外すかという判断が必要になります。

同じfile名でも、どこから読み込まれたかを確認します。themeのheaderに直接書いたscript、pluginがenqueueしたscript、tag managerのような外部管理のscriptでは、編集する場所が違います。WordPressの管理画面に出るwarningを、公開pageのtheme fileだけ探しても見つからないことがあります。warningが出たscreen、URL、ログイン状態、操作直前に押したbuttonを記録して、読み込みの条件を絞ります。

本番で直す前に表示と操作を試す

原因が分かったら、test siteで修正後のscriptを試します。確認するのはwarningが消えたかだけではありません。scriptが担当している操作まで試します。

1. warningが出たpageと操作を記録する。
2. browserのconsoleで、file名と行番号を確認する。
3. theme、plugin、外部serviceのどれが読込元か分ける。
4. test siteで更新または修正を行う。
5. button、form、menu、画像uploadなど、関係する操作を試す。
6. warningと操作結果を記録してから本番へ反映する。

たとえば、問い合わせformを開いたときにwarningが出るなら、formを表示するだけでなく、入力、確認、送信の順で試します。送信先へ届くかまで確認できなければ、画面だけ見ても仕事が進むかは判断できません。

test siteでは、本番と同じtheme、plugin、主要な設定を置きます。ただし、本番の問い合わせ先、広告の計測、利用者のdataへ影響しないように、外部送信は分けます。testでwarningを消せたとしても、本番だけにあるcacheや外部scriptで同じ結果になるとは限りません。本番へ反映する前に、testした範囲と本番にだけある違いを一覧にします。

修正の前後で比べるのは、consoleの警告だけではありません。warningが出たpageを開く、menuを開閉する、画像を選ぶ、formを送る、管理画面で保存するなど、scriptが関わる操作を通します。更新前に動いていた操作を一つずつ選び、修正後にも同じ結果になるかを見ます。警告が減った代わりにbuttonが押せなくなれば、修正は完了していません。

問題を再現できない場合は、無理にcodeを替えません。どのbrowser、どの画面幅、どの利用者権限、どのpageで出たかを集め、次に出たときに比較できるようにします。毎回出るwarningと、特定の操作でだけ出るwarningを混ぜると、原因の範囲が広がります。確認できた事実と、まだ分からないことを分けて開発者へ渡します。

外部の制作者へ依頼する場合は、warningの画面shotだけを送らず、file名、行番号、URL、操作順、WordPressとpluginのversion、期待する動作を添えます。制作側が修正した後は、何を変更したか、更新で上書きされるfileか、確認した操作は何かを受け取ります。依頼を出したことと、siteの重要な操作を確認したことは別です。

互換用scriptを恒久的な修正にしない

jQuery Migrateは、古いcodeを使うsiteが急に止まらないようにするための助けになります。しかし、互換用scriptがあるからといって、古い呼出しを直さずに残す理由にはなりません。更新予定のないpluginや、担当者が分からないcustom scriptは、依存関係と費用を確認して、置換または削除を判断します。

互換用scriptを外してwarningを見えなくする方法も、原因を解決したことにはなりません。必要な互換性まで外せば、今まで動いていた機能がその場で止まる可能性があります。先に呼出元と使っている操作を確認し、修正したcodeをtest siteで試してから、互換性に頼る範囲を減らします。短期の対処と恒久的な修正を同じ変更として記録しません。

費用や時間の判断も、warningの件数だけではできません。問い合わせform、購入、予約、管理画面の投稿のように業務へ直接関わるものから優先します。使っていないsliderや古いwidgetのwarningなら、修正より削除が適切な場合もあります。siteの目的に必要なscriptなのか、過去の制作で残っただけなのかを調べます。

最初に残す記録は、warningが出た画面、file名、操作、読込元、影響する業務です。これを一件ずつそろえると、単に警告を消す作業から、themeやpluginを引き継げる状態へ直す作業に変わります。

最初の一手は、warningが出るscreenを一つ選び、consoleに出るfile名を控えることです。file名が分かれば、どこへ問い合わせ、どこでtestすべきかを決められます。