WordPress 4.7のCustomizerはpreviewで試す作業と公開する作業を分ける

WordPress 4.7のCustomizerでは、設定を変えた直後の画面をpreviewで確認できます。previewに出た内容は、Save & Publishを押すまで訪問者の画面へ公開されません。見た目を試す作業と、公開する内容を決める作業を分けてください。途中で閉じても設定が残るようになりましたが、残った設定をそのまま公開してよいとは限りません。

Customizerで扱う設定には、site title、header image、background image、menu、widgetなどがあります。一つの設定だけを変えたつもりでも、small screenでmenuが重なる、画像に必要な説明がない、link先が古いといった問題は、previewの一場面だけでは分かりません。設定を保存する前に見る範囲と、公開する前に決める内容を別にします。

previewは公開画面の代わりではない

Customizerの目的は、設定を変えた結果を公開前に見ることです。たとえば会社名を短くし、header imageを替え、menuの順序を入れ替えたとします。previewで一つのpageが整って見えても、全てのpageで同じように読めるとは限りません。headerが長いpage titleへ重なることも、menuから進んだpageで古い案内が残ることもあります。

previewで確認するものと、公開画面で確認するものは役割が違います。

説明用の仮例として、店舗のsiteでtop pageのheader imageとmenuを変更する場合を考えます。previewで画像の位置を決めたあと、保存前に問い合わせpage、営業時間のpage、menuから開く主要なpageを順に見ます。営業時間のlinkが旧pageを向いていれば、header imageが正しく表示されても公開の準備は終わりません。画像の調整と、利用者が必要な情報へ進めることは別の確認です。

また、Customizerの画面を見ている人と、公開の判断をする人が違う場合もあります。作業する人は、何を変更したかを設定名だけで伝えず、公開画面でどこが変わるかを伝えます。判断する人は、設定値の細部ではなく、会社名、電話番号、営業時間、案内文、link先が事業の実情と合っているかを確認します。themeを操作する権限と、掲載内容を承認する責任を同じにしません。

changesetに残る設定は作業途中の記録である

WordPress 4.7では、Customizerで変更した設定がchangesetとして保存されます。WordPressの公式開発資料では、変更内容はcustomize_changesetという投稿typeへ記録され、Customizerを閉じて再び開いたときにも変更を扱える仕組みが説明されています。前の版では、保存しないまま画面を離れると変更を失いやすかったため、試しながら確認する作業が続けにくい面がありました。

変更が残ることは、作業を戻せる可能性を作ります。しかし、残っている設定を正式な下書きや承認済みの変更と取り違えないでください。4.7の標準画面には、changesetを一覧で見て、下書きとして選び、担当者へ承認を依頼するための新しい画面はありません。画面を閉じたあとに設定が残っていても、それは公開する内容を誰かが確認したことを意味しません。

たとえば、header imageを試し、site titleも仮の表記へ替えた状態で作業を中断したとします。次にCustomizerを開いたとき、変更が残っていれば続きから確かめられます。このときに先にするのは、Save & Publishを押すことではありません。仮の表記が残っていないか、画像の利用許可と掲載範囲が確認できるか、menuやlinkの確認が済んでいるかを見ます。試すために残った設定と、公開する設定を一度分け直します。

changesetは、設定変更をまとめて扱える仕組みでもあります。site titleだけを先に公開し、menuとwidgetを後で確認するより、利用者に見せる一組の変更として確認した方が、画面と案内の食い違いを見つけやすくなります。ただし、変更を一組にまとめるからといって、一度に多くの設定を足す必要はありません。原因を追える範囲へ分け、公開前に全体を確認できる量に留めます。

設定を試す前に公開の単位を決める

Customizerを開く前に、今回公開する単位を一行で書きます。「top pageのheader imageを夏の案内へ替え、営業時間pageへのmenuを確認する」のように、設定と読者に見える案内をつなげます。「見た目を少し直す」では、どこまで確認すれば終わるか決まりません。

次に、変更する設定を絞ります。画像だけを替えるなら、site title、色、widgetまで同時に触れません。複数の変更を同時にすると、保存後に表示が崩れたとき、どの設定やthemeの処理が原因かを分けにくくなります。設定を一つずつ変えることが目的ではありません。戻す必要が出たときに、何を戻せばよいか分かる状態を残すためです。

変更したら、次の順で確認します。

1. Customizerのpreviewで、変更する場所と周囲の文字や画像が重ならないかを見る。
2. menuから開く主要なpageで、案内文とlink先が今回の内容に合うかを見る。
3. 小さな画面幅で、menu、button、画像、問い合わせ先が読めるかを見る。
4. 設定を公開する人が、変更内容と確認結果を見て判断する。
5. Save & Publishのあと、ログアウトした画面または別のbrowserで公開URLを開く。

この順序であれば、Customizerのpreviewを便利な試行場所として使いながら、管理画面の見え方だけで公開を決めずに済みます。外部へ修正を頼むときも、作業依頼には設定名だけでなく、変更するURL、公開する理由、確認する画面、公開の承認者を含めます。誰かがthemeを触れることと、誰かが公開内容の責任を持つことは別です。

保存後に見るのは設定値ではなく利用者の画面である

Save & Publishを押したあとは、管理画面へ戻って終わりにしません。公開側のURLを開き、top pageからmenuをたどり、変更した案内へ進みます。linkが期待したpageへ進むか、画像の下に読めない文字がないか、問い合わせ先が見つかるかを確認します。Cookieやlogin状態によって管理者だけに見える内容があれば、別のbrowserでも見ます。

仮例の店舗siteなら、営業時間pageへ進み、休業日や電話番号がheaderの案内と矛盾しないかを見ます。問い合わせbuttonを置いたなら、buttonを押した先で何を入力し、送信後に誰が受けるのかまで確認します。Customizerの変更は見た目から始まりますが、公開後のsiteは利用者の行動で評価されます。

最初の一手は、次にCustomizerで変更する内容を一行で書き、変更するURLと公開後に確認するURLを二つずつ決めることです。これだけで、試すための設定と公開する案内を混ぜにくくなります。