WordPress 4.6のCustomizer validationはsanitizeと入力エラーを分けて扱う
公開日： 執筆：佐藤
Customizerの設定で、入力を整えて保存できるものと、保存してはいけないものは別です。WordPress 4.6では、setting valueのvalidationとerror notificationが加わります。sanitize_callbackだけで無理に値を直すのでなく、直せない入力は理由を示して保存を止めます。
4.6のvalidationでは、変更したsettingを保存する前にまとめて確認します。一つでも無効なsettingがあれば保存は受け付けられず、errorはcontrolへ表示されます。以前のように一部のsettingだけが保存され、残りが反映されない状態を避けるためです。設定画面に入力欄を増やすほど、何を保存できる値とするかを先に決める必要があります。
入力欄を作ると、値があるかどうかだけを確認しがちです。しかし、空欄が許される設定もあれば、空欄では公開pageの案内が成立しない設定もあります。数字であることだけで足りる欄もあれば、開始年と終了年のように複数の値の関係を確認する欄もあります。validationは、入力を面倒にするためではなく、公開できない組み合わせを保存しないために使います。
sanitizeとvalidationの役割を混同しない
sanitizeは、databaseへ保存できる形へ値を整える処理です。validationは、その値を受け付けてよいかを判断する処理です。
| 処理 | 役割 | 例 |
|---|---|---|
| sanitize | 空白を除く、整数へ変換する、tagを外す | 数字の文字列を整数として保存する |
| validation | 値が条件に合うかを判断する | 年が空でないか、範囲内かを確かめる |
| notification | 保存できない理由を利用者へ示す | 「年を入力してください」と表示する |
| 公開画面のescape | 出力時の安全な表示を行う | 保存済みの文字をHTMLへ出す前に処理する |
説明用の仮例として、Customizerに開業年を入れるsettingを置く場合を考えます。数字へ変換することはsanitizeです。しかし、空欄、未来の年、説明文まで含んだ値を受け付けるかはvalidationで決めます。入力が無効なら、古い値だけがpreviewに残る理由をnotificationで示します。
たとえば、入力値が「2008年」なら、数字だけを保存するのか、「年」を含めて保存するのかを先に決めます。表示側で「年」を付けるなら、保存する値は整数にそろえた方が比較しやすくなります。「2008年ごろ」のような表記を許すなら、数字だけを期待するvalidationにはできません。入力欄のlabelと公開pageの表記だけを見て決めず、保存する値の形式を一つにします。
未来の年を入れたときは、単に古い値へ戻すのでなく、なぜ受け付けないかを知らせます。利用者が入力を直せなければ、保存buttonを押しても何が起きたか分かりません。notificationは開発者向けのerror logではなく、設定を変更する人が次に何を直すかを示すためのものです。「入力が正しくありません」とだけ出すより、対象の欄と条件が分かる文にします。
sanitizeとvalidationの順序も混同しません。前後の空白を取り除き、数字の文字列を扱える形にすることはsanitizeでできます。一方、変換後の値が事業上あり得る年か、空欄を許すか、別のsettingと矛盾しないかはvalidationで判断します。無理に値を丸めたり、無効な値を別の値へ置き換えたりすると、入力者は何が保存されたか分からなくなります。
一部だけ保存される状態を作らない
4.6のvalidationを使うときは、複数のsettingを一組として考えます。営業時間の開始時刻と終了時刻、電話番号と受付案内、背景画像と代替文のように、並んだ値で意味が決まる設定があります。一方だけ新しく保存され、もう一方が古いままなら、公開pageで矛盾した案内が出ます。どのsettingを同時に確認するかを決めます。
- どのsettingが同時に意味を持つかを決める。
- 各settingで整えられる値と、受け付けない値を分ける。
validate_callbackまたはWP_Customize_Setting::validate()で条件を実装する。- 無効な値を入れ、保存が止まりerrorが表示されるか確認する。
- 値を直したあと、すべてのsettingが同じ保存で反映されるか確認する。
説明用の仮例として、営業開始時刻と終了時刻をCustomizerで入力する場合を考えます。開始が10時で終了が18時なら、二つをまとめて保存します。終了時刻だけを9時へ変えると、数値としては入力できますが、営業時間の案内としては成り立ちません。どちらか一方の欄だけで確認するのでなく、二つの値の関係をvalidationで確かめます。
一部だけ保存される問題は、設定を分けてpreviewできる場合ほど見落としやすくなります。画像は新しく見えるのに、同時に直したlink先URLは古いまま、という状態では、公開前の画面だけ見ても気付きません。testでは、複数のsettingへ正しい値を入れた場合、片方だけ無効な値を入れた場合、直してもう一度保存した場合を分けて試します。保存後にCustomizerを開き直し、公開URLも別に開きます。
previewをJavaScriptのpostMessageだけで更新するsettingは、画面側でもvalidationを行います。ただし、JavaScriptだけで確認を終えません。browserからの操作を通らずに送られた値でも保存できないよう、server側のvalidationを残します。画面でerrorが出ないことと、serverが無効な値を受け付けないことは別の確認です。
error notificationの文言もtestします。複数のsettingにerrorがあるとき、どのcontrolで何を直すのか分かるかを見ます。入力欄から離れた位置にだけerrorが出れば、設定を変更する人は見落とすかもしれません。長い技術用語を出す必要はありませんが、条件を短く示し、値を直せば保存できることが分かるようにします。
入力欄の実装と公開内容の承認を分ける
Customizerのvalidationを制作側へ実装してもらえます。しかし、料金、営業時間、電話番号、公開する画像の条件を誰が決めるかは事業側の判断です。errorを表示することと、正しい事業情報が入力されたことを承認することは別です。validationは入力形式を確かめられても、営業時間を変更してよいかまでは判断しません。
制作側へ頼むときは、settingの用途、保存する形式、空欄を許すか、無効とする条件、表示するerror、関連するsetting、公開pageの表示場所を渡します。制作側はcallbackと保存、notification、previewを確認します。事業側は、入力する値と公開する条件を承認します。入力がtechnicalに正しくても、古い電話番号や誤った料金を公開してよいわけではありません。
最初の一手は、Customizerのsettingを一つ選び、「整えられる値」「保存しない値」「表示するerror」「関連するsetting」「公開画面への出力」を五行に分けることです。次に、正しい値、空欄、形式が違う値、関連する欄と矛盾する値を入れ、保存とnotificationを確認します。五つを決められてからcallbackを追加します。WordPress 4.6のvalidationは、入力欄を増やすための仕組みではなく、保存した設定と公開画面の案内を食い違わせないための仕組みです。
関連記事
