WordPress 4.6のregister_meta()はmeta keyを決める前に用途と権限を分ける

投稿へ独自の情報を保存するとき、meta keyの名前だけを決めて書き込み始めると、後から何の値か分からなくなります。WordPress 4.6のregister_meta()は、meta keyにsanitize callbackやauthorization callbackを結び付けられます。値を保存する仕組みと、誰が何のために変更できるかを一緒に決めます。

4.6ではregister_meta()の形が整理され、既存の三引数による登録も動き続けます。meta keyは、他のthemeやpluginと重ならないようにprefixを付けます。$wp_meta_keysを直接書き換えるのではなく、登録済みのkeyを確認する関数を使います。既に保存されている値があるからといって、新しいkeyの意味や編集権限が決まるわけではありません。

metaは便利な空き箱ではありません。本文に書くべき説明、categoryで分けるべき分類、site全体で使う設定、投稿ごとに持たせる補助情報を、同じ場所へ入れると運用が崩れます。値を表示する画面が増えるほど、誰が更新し、古くなったときに誰が直すかも必要になります。keyを一つ追加する前に、その情報が本当に投稿ごとに必要かを決めます。

保存する値と、表示する文章を分ける

metaは管理画面で使う補助情報として便利ですが、本文、見出し、料金、公開条件まで無秩序に入れる場所ではありません。

説明用の仮例として、記事に「確認日」を保存するとします。satolab_reviewed_onのように用途が読めるprefix付きのkeyを決め、日付だけを受け付ける処理と、編集者が変更できる条件を分けます。料金や注記の文章まで一つのmetaへ詰め込むと、誰がどこで承認した内容かを追えません。

確認日へ「2016年8月7日」と記録するなら、値の形式を日付だけに決めます。「確認済み。担当者へ連絡」といった補足まで同じ値へ入れると、日付として並べ替える処理も、確認日だけを表示する処理も扱いにくくなります。補足が必要なら、別のkeyにするか、投稿の編集履歴に残すかを考えます。一つの値に複数の意味を持たせないことが、後の修正を小さくします。

公開pageへ表示する値と、編集者だけが使う値も分けます。たとえば、記事の確認日を公開するかどうかは、記事の信用をどう伝えるかの判断です。内部の確認担当者名や作業メモまで公開する必要はありません。表示しない値でも、管理画面から変更できるなら、誰に権限を与えるかを決めます。保存できることと、見せてよいことを同じ条件にしません。

sanitize callbackは、入力された値を受け取る前に形式を整える役目です。表示するときのescapeとは目的が違います。日付だけを保存したい欄でHTMLを許すか、整数だけを使う順序欄で文字列を受けるかは、保存する前に決めます。入力欄で制限していても、保存処理で形式を確認しなければ、別の経路から想定外の値が入ることがあります。

authorization callbackは、誰が値を変えられるかを判断するためのものです。投稿を読める人が編集できるとは限りません。たとえば、著者が本文を直せても、公開順や内部確認の値は編集者だけが変えるようにしたい場合があります。valueの形式を整える処理と、変更を許す処理を同じcallbackへ混ぜると、後から権限の理由を見直しにくくなります。

keyを登録する前に既存dataを確認する

新しいmeta keyを作るときは、次の順で確認します。既存dataを調べずに似たkeyを増やすと、同じ情報が二つの場所へ残ります。どちらを優先するかが決まらないまま表示処理を作ると、投稿によって古い値と新しい値が混ざります。入力欄を追加する前に、今あるtheme、plugin、投稿で使われているkeyを探します。

1. 保存したい情報が本文、taxonomy、設定、metaのどれに属するかを決める。
2. 既に同じ用途のkeyがtheme、plugin、既存投稿にないか確認する。
3. keyにprefixを付け、値の形式を一つにする。
4. sanitize callbackとauthorization callbackを、それぞれの目的で決める。
5. test投稿で保存、編集、表示、権限のない利用者による変更を確認する。

説明用の仮例として、以前のthemeがreviewed_dateというkeyを使い、新しいpluginがreview_dateを使おうとしている場合を考えます。見た目は近くても、保存している値の形式や表示場所が違うかもしれません。既存keyの値を確認せず、新しいkeyを追加すると、投稿ごとにどちらを見ればよいかが分からなくなります。引き継ぐ値があるなら、移す方法と確認する投稿を決めます。使わない値なら、残す理由と参照している場所を確認してから扱います。

keyにはprefixを付け、誰のための値かを名前から追えるようにします。ただし、prefixを付けるだけで他のthemeやpluginとの関係がなくなるわけではありません。似た用途の登録済みkeyがあるか、同じpost typeで使うか、入力欄がすでにあるかを確認します。get_registered_metadata()、get_registered_meta_keys()、registered_meta_key_exists()は、登録したkeyを確認するために使えます。管理画面の入力欄があることだけを根拠に、keyが正しく登録されているとは判断しません。

test投稿では、保存だけを試して終わりにしません。編集者が値を入力して保存し、再び編集画面を開いて同じ値が読めるかを確認します。次に、権限のない利用者で編集画面を開いた場合に、その値を変えられないかを確認します。公開pageで使うなら、空の値、正しい値、想定外の値を入れた場合に表示が崩れないかを見ます。実際の投稿へ入れる前に、値の流れを一件でたどります。

4.6は正式版前なので、開発版またはtest siteで登録処理を試します。既存の三引数形式を使っているthemeやpluginがあるなら、変更した場所と確認した組み合わせを残します。新しい形へ書き替えることと、既存の値を安全に扱えることは別です。更新対象のfile、key、test投稿、確認結果を記録しておくと、正式版へ進むときに同じ確認を繰り返せます。

開発作業と情報を決める責任を分ける

制作側はmeta keyとcallbackを実装できます。しかし、何を内部情報として保存するか、誰が変更できるか、公開pageへ出すか、古い値をいつ見直すかはsiteの運用判断です。登録処理を追加することと、情報管理の責任を果たすことは別です。制作側へ「metaを追加してほしい」と頼むだけでは、どの情報を守るかは決まりません。

頼むときは、keyの用途、使うpost type、値の形式、入力する人、変更できる人、公開pageへ出すか、既存の値があるかを渡します。制作側はkeyの登録、sanitize callback、authorization callback、表示処理を確認します。事業側は、値の内容と更新の責任を確認します。metaを追加したあとに担当が変わっても、名前と用途から判断できる状態を残します。

最初の一手は、追加したいmetaを一件選び、用途、値の形式、編集者、公開pageへの表示有無、既存keyの有無を五行に分けて書くことです。次にtest投稿で、保存、再編集、権限のない利用者、公開表示を順に確認します。五つが決まらないなら、keyを増やす前に情報の置き場所を見直します。register_meta()は値を保存するための関数ですが、何を保存し、誰が扱うかまで曖昧にしたままでは役に立ちません。