WordPress 4.6のCustomizer media controlは独自CSSを替える前に表示対象を分けて確認する

WordPress 4.6では、Customizerのmedia controlに使われるmarkupとCSSが整理されます。独自のWP_Customize_Media_Controlを使うthemeは、管理画面の見た目が少し違うだけだと考えず、画像の選択、差し替え、削除、previewまでを分けて確認します。共通controlのCSSを上書きしている場合は、以前のselectorだけに依存したまま更新しません。

4.6のCustomizer APIでは、media controlのmarkupが単純化され、CSSも共通selectorを使う形へ見直されます。独自controlがCoreの古いmarkupやCSSを前提にしていれば、画像を選べても、削除buttonや説明、previewの配置が崩れることがあります。themeの表側が正常でも、管理画面の登録作業が止まれば運用は続きません。

とくに注意するのは、公開siteの画像が一度表示できたことだけを確認して、管理画面の問題を見落とすことです。初回の選択はできても、二枚目へ替えたときにpreviewが更新されない、削除しても古い画像が残る、保存後にもう一度開くと説明が読めない、といった問題は別に起こります。画像を扱うcontrolは、登録する人が繰り返し使えることまで含めて確認します。

画像を選ぶ画面と公開画面を別に確認する

Customizerの変更では、公開siteだけを見て終わりにしません。管理画面で画像を扱う操作と、保存した値がthemeへ反映される経路を分けます。

説明用の仮例として、トップ画像用に独自media controlを置いたthemeを考えます。画像の選択だけ通っても、削除したあとに以前のURLが残れば、事業者は画像を外したつもりで古い画像を公開し続けます。選択、保存、再読込、差し替え、削除の順で確認します。

この順番では、毎回同じ画像を使いません。最初に画像Aを選び、保存後に画像Bへ差し替えます。次に画像Bを削除し、公開siteとCustomizer previewの両方で画像が消えたことを確認します。画像AからBへ変わったことが分かるよう、内容の異なるtest用画像を使います。似た画像だけで試すと、古い値が残っていても気付きにくくなります。

header、logo、背景画像、section内の画像など、controlの用途も分けて試します。同じmedia controlを継承していても、theme側が画像URLだけを使うのか、attachmentの情報も使うのかで、壊れ方が違います。headerだけ確認してほかのcontrolを省くのではなく、theme独自の表示処理がある場所を一覧にします。管理画面のcontrol名と公開siteの表示場所を対応させると、確認漏れを防げます。

previewで正しく見えても、保存後の公開siteで同じ表示になるとは限りません。previewはCustomizerが読み込んだ一時的な値を使い、公開siteは保存済みの値を読みます。選択直後の画面、保存後にpreviewを開き直した画面、公開URLを開いた画面を分けて見る理由はここにあります。どの段階でずれたかが分かれば、CSSの問題か、保存する値の問題かを切り分けられます。

CSSを直す前に依存している部分を探す

4.6へ合わせてCSSを直すときは、見た目の微調整から始めません。まず、独自CSSが何を支えるためにあるかを調べます。余白を整えるruleと、hiddenになったbuttonを見せるruleは同じように見えても、削除したときの影響が違います。selectorの名前が変わったからといって、theme側のCSSをまとめて置き換えないことが必要です。

1. theme内でWP_Customize_Media_Controlを使うclassを探す。
2. Customizer用CSSでmedia controlのclassやidを指定している箇所を探す。
3. 画像、video、audioなど、同じcontrolを継承する設定を分ける。
4. 4.6の開発版またはtest siteで選択、保存、削除、previewを確認する。
5. 本番themeへ入れる変更と、確認結果を記録する。

説明用の仮例として、themeがbuttonの幅や画像previewの高さを独自CSSで指定している場合を考えます。Coreのmarkupが変わると、そのruleが別のbuttonへ効いたり、目的のpreviewへ効かなくなったりします。selectorを一つ直したあとで選択、保存、削除を試し、問題があれば次のruleを確認します。複数の変更を一度に入れると、どの変更で表示が戻ったか分からなくなります。

独自controlのためにCoreのCSSを複製している場合も、何を補うために書いたruleなのかを確認します。余白を整えるruleと、buttonを表示させるためのruleは影響が違います。古いselectorをまとめて消すと、問題の場所を追えなくなります。使われていないruleを片付ける作業と、4.6へ対応する作業は、同じ変更へ混ぜずに記録します。

画像、video、audioのように同じ基底controlを使う設定は、表示だけでなく選択できるfileの種類も確認します。トップ画像用のcontrolだけを直して、別の設定画面のaudio選択が崩れていれば、管理画面全体の運用は止まります。対象となるcontrolを列挙し、操作結果と表示結果を表に残すと、公開前に確認した範囲が分かります。

4.6は正式版前の段階なので、開発版またはtest siteで確認した内容を本番themeへ直接入れません。test siteで変更したfile、試したcontrol、画面上の結果を残し、正式版を入れる前後で同じ操作をもう一度行います。更新後に管理画面で画像を差し替える担当者が、自分で試せる状態を作ってから本番へ進めます。

theme改修と画像の運用責任を混同しない

themeの修正を制作側へ頼めます。しかし、どの画像を事業者が差し替えられるようにするか、削除した画像がsiteから消えることを誰が確認するか、管理画面を誰に渡すかは、siteの運用設計です。CSSを直すことと、運用できる状態にすることは別です。制作側が修正を終えても、画像の担当者がどのcontrolを使うのか分からなければ、古い画像を残す事故は防げません。

頼むときは、対象のcontrol名、表示場所、画像を替える担当者、削除時に確認するURL、test siteで試す操作を渡します。制作側はmarkupとCSS、保存と表示を確認します。事業側は、公開してよい画像か、削除してよい画像か、確認を誰が終えるかを決めます。画像の内容を決める責任と、themeを修正する責任を分けておくと、更新後の確認も短くなります。

最初の一手は、独自media controlを一つ選び、画像Aの選択、保存、画像Bへの差し替え、削除、公開画面の五つを画面ごとに記録することです。controlの表示、preview、保存後、公開siteを別の欄にします。どこで崩れたかを分けてからCSSを直します。WordPress 4.6への対応は、selectorを新しくすることではなく、画像を替える人が管理画面と公開siteで同じ結果を確認できるようにする作業です。