WordPress 4.7のCustomizerは独自panelを使うthemeで見た目より先に動作を確認する

WordPress 4.7では、Customizerのpanelとsectionの画面構造が変わる予定です。画面が開き、設定項目が見えていても、更新前と同じように動くとは限りません。独自のpanelやsectionを追加しているthemeでは、開く、戻る、設定を変える、保存する、もう一度開くところまで確認します。

今回の変更は、設定項目の見出しと内容が、画面のHTMLでは別の位置へ置かれることにあります。以前は大きな入れ子の中にあったものが分かれ、見出しと内容の関係はaria-ownsで示されます。見た目を変えるだけのCSSでは影響が出ない場合もあります。しかし、親子の入れ子を前提にJavaScriptで開閉している場合や、containerから特定の要素を探している場合は、画面が見えていても操作だけが壊れることがあります。

画面の設定と画面を動かす処理を分けて調べる

Customizerへ色、ロゴ、文章などの設定を追加しているだけなら、まず標準の操作で確認します。独自のpanel、section、control、開閉処理、画面用CSSがあるなら、設定値と画面の動きを別に調べます。設定値が保存できても、開閉処理まで正しいとはいえません。

WordPress 4.7では、Containerに内容を取り出すgetContent()が加わり、headContainerとcontentContainerも使えるようになります。独自のsectionやpanelで、内容を入れ子のままにしている理由がある場合や、独自の展開処理を持つ場合は、この変更を確認します。既存のcontainerが直ちに使えなくなるという話ではありません。互換性を保つため、見出し側と内容側を含む集合として扱われます。だからこそ、古い構造を前提に一つの要素だけを期待している処理を探す必要があります。

sourceを探すときは、containerという語だけで終わりにしません。panelやsectionを開く処理、戻るbuttonへeventを付ける処理、表示中の項目へclassを付ける処理も確認します。独自のCSSが親要素から子要素を選ぶ書き方をしていれば、見出しと内容が別の位置になったときに効かなくなる場合があります。JavaScriptとCSSを別々に直す前に、どの操作を支えているかを記録します。

見た目だけでは分からない失敗を先に試す

説明用の仮例として、theme独自の「トップページ設定」panelを考えます。この中に、画像を選ぶsectionと、表示する文章を入力するsectionがあるとします。更新後に最初の画面だけを見れば、二つのsectionが並んでいるので問題がないように見えます。

しかし、画像を選んだあとに文章のsectionを開き、前の階層へ戻って再び画像を開くと、独自のJavaScriptが古い親要素を探して止まることがあります。previewへ画像が出ても、保存後にもう一度Customizerを開いたときに選択状態が戻ることもあります。操作の途中で起きる不具合は、最初の表示だけでは見つかりません。

確認する値は、実際に公開画面へ影響するものを一つ選びます。色のように影響が小さい値だけではなく、画像、メニュー、文章のように、保存とpreviewの両方を通る設定を選ぶと、確認の意味がはっきりします。設定を変えたときだけでなく、変更を取り消したときも試します。

画像を選ぶcontrolなら、画像Aを選び、保存し、画像Bへ替え、削除し、同じpanelを開き直すところまで試します。文章のsettingなら、短い文、長い文、空欄を入れ、previewと公開画面で表示を比べます。選択直後にpreviewが変わることと、保存後に同じ状態へ戻れることは別です。test用の値を使い、公開中の案内を確認のために不用意に変えません。

戻る操作も一度だけで終わらせません。panelを開き、sectionを開き、controlを操作し、前の階層へ戻り、別のsectionを開きます。独自JavaScriptの問題は、最初の表示ではなく、二度目の開閉や別のsectionへ移ったときに出ることがあります。画面が応答しなくなった場合は、保存処理、開閉処理、CSSのどこまで動いたかを分けて残します。

更新前に残す確認記録

1. themeとpluginの中から、独自のpanel、section、control、Customizer用JavaScript、CSSを洗い出す。
2. 代表する設定を一つ選び、更新前の画面で開く、変更する、previewを確認する、保存する、再表示する、戻るを記録する。
3. 更新後に同じ順序をたどり、表示、開閉、保存、previewのどこが違うかを分ける。
4. 差が出た場合は、設定値の保存、JavaScript、CSSのどれが原因かを一つずつ確認する。
5. 公開画面に影響する設定なら、管理画面だけで終わらせず、保存後の公開画面も確認する。

WordPress本体を更新することと、独自themeが同じように動くことは別です。更新を外部へ任せる場合も、独自に加えたCustomizer機能の場所、変更できる担当者、確認する画面はsite側で把握しておきます。修正が必要になったとき、どの設定が使えなくなったのかを示せなければ、原因を探す時間が延びます。

test siteがある場合は、そこで4.7の変更とthemeを組み合わせます。本番siteのCustomizerで試す場合は、test用の設定を一つに絞り、元の値と戻す手順を先に確認します。設定を変える人と公開画面を確認する人が違うなら、何を変え、どのURLを開くかを共有します。管理画面で保存できたという報告だけで、公開確認を終えません。

修正を依頼するときは、画面名、操作順、期待する結果、実際に起きた結果、使用したbrowserを渡します。「Customizerが壊れた」とだけ伝えるより、画像sectionを開いた後に戻るbuttonが動かない、保存後にpreviewが戻る、のように操作と結果を分けた方が直す場所を絞れます。制作側が修正した後も、同じ順序で再確認します。

最初の一手は、独自Customizerを使う画面を一つ選び、操作の順序と結果を更新前に残すことです。その記録があれば、画面の見た目ではなく、どの動作が変わったかを基準に修正できます。