会員管理の困りごとが、設定の範囲で片づくか

権限の定義と、利用者ごとの情報は別の場所にある

WordPressの公式プラグインハンドブックは、ロール（役割。編集者・購読者などのまとまり）とその権限について「WordPress stores the Roles and their Capabilities in the options table under the user_roles key.」と説明しています。options テーブルはサイト全体の設定を入れる場所で、user_roles はその中の1つのキーです。役割の定義そのものは、利用者ごとの行ではなく、設定を入れるテーブルの1つのキーにまとまっています。

この定義が1か所にまとまっていること自体は設計であって、不具合ではありません。ハンドブックが述べているのは、役割の定義の置き場所と、権限を判定する関数があることまでです。利用者への割り当てについては、後で引くコードリファレンスが usermeta を「additional user information, such as nicknames, descriptions and permissions」の置き場所として説明しています。標準の構成なら手がかりはあります。分からないのは、プラグインが足した条件がどこにあるかのほうです。以下では、調べる対象を役割の定義と、利用者ごとの割り当てと、プラグインが足した条件の3つに分けます。当方の整理で、出典が定めたものではありません。

利用者に紐づく情報は、件数が決まっていない

利用者ごとの追加情報は、役割の定義とは別の場所に入ります。ハンドブックは、usermeta テーブル（利用者1人ごとの追加情報を入れる場所）について「the usermeta table was introduced, which can store any arbitrary amount of data about a user.」と説明し、利用者のテーブルとの関係を「Both tables are tied together using one-to-many relationship based on the ID in the users table.」としています。

つまり、利用者1人に、件数を固定しない形で複数件が紐づきます。usermeta を使う実装なら、会員種別や属性を足していけます。ただし、会員種別が usermeta に入っているとは限りません。役割として持たせることも、独自のテーブルに入れることもできます。どの利用者にどんな項目が何件入っているかは、置き場所の仕組みからは決まりません。数えるには、実際に入っている中身を見ることになります。

資料が書いていないこと

会員機能を調べるときによく問題になる次の2点について、提供元の文書は書いていません。

1つは、テーブル間に外部キーなどの制約があるかどうかです。前の節で引いた資料は、利用者と追加情報の結びつきを説明していますが、データベース（記事や利用者の情報を保存する仕組み）の側で、紐づきが崩れないよう強制しているかどうかには触れていません。利用者を消したときに紐づく情報がどうなるかは、この資料からは決まりません。

もう1つは、権限の変更、退会、購入といった履歴が残るかどうかです。ハンドブックが説明しているのは保存場所であって、変更の記録ではありません。履歴が要るなら、いま残っているかを自分で確かめる必要があります。求められる場面は、会員情報の扱いを問われたときに来ます。誰がいつ何を変えたかを後から示せるかどうかは、扱っている情報の性質で重みが変わります。

確かめられなかったことを、ここでは「無い」と書いていません。無いことを示すには別の資料が要ります。

範囲を限れば言えることもあります。WordPress公式のコードリファレンスは、サイトごとのテーブルを posts・comments・links・options・postmeta・terms・term_taxonomy・term_relationships・termmeta・commentmeta の10個、インストール全体のテーブルを users・usermeta の2個として列挙しています。この12個に、操作の記録を残すためと名前から分かるものはありません。ページは usermeta を利用者の追加情報、options を設定の置き場所として説明していますが、会員機能が足した情報がどこに入るかは書いていません。会員機能が足した情報がどこにあるかは、この一覧だけでは決まりません。標準のテーブルの中、プラグインが足したテーブル、別のデータベース、外部のサービスなどが考えられます。候補の並びは当方の見立てで、資料が挙げたものではありません。マルチサイト用と非推奨のものは別の一覧にあります。

独自のテーブルを足す前に、提供元が検討を求めていること

標準の置き場所で足りないとき、プラグインや実装で独自のテーブルを足す選択肢があります。ハンドブックは、その前に検討することを求めています。「Before jumping in with a whole new table, however, consider if storing your plugin's data in WordPress' Post Meta (a.k.a. Custom Fields) would work. Post Meta is the preferred method; use it when possible/practical.」

原文が挙げているのは投稿に紐づくメタデータで、会員情報そのものの話ではありません。同じ文書は独自テーブルの作り方も説明しており、独自テーブルそのものを避けるべきものとはしていません。求められているのは、足す前に既存の置き場所で足りるかを検討することです。

検討の中身は、何を自前で持ち、何をWordPressに任せるかの線引きです。独自テーブルに置いた情報が、管理画面や他のプラグインからどう扱えるかは、作りによって変わります。足す前に、実装する相手と確かめることになります。

利用者テーブルを差し替える経路も用意されている

WordPressの設定ファイルには CUSTOM_USER_TABLE と CUSTOM_USER_META_TABLE があります。公式文書は「CUSTOM_USER_TABLE and CUSTOM_USER_META_TABLE are used to designate that the user and usermeta tables normally utilized by WordPress are not used」と説明しています。

つまり、利用者の情報を標準以外の場所に置く構成を、提供元自身が想定しています。ただし、条件も同じ資料に書かれています。複数のWordPressで利用者テーブルを共有する手順の説明として、「You also need to manage permissions to each of the site via a plugin or custom function」とされ、設定しなければ「you will experience permission errors and log-in issues」とあります。複数で共有するなら、権限の管理は別に用意することになります。1つのサイトだけで差し替える場合について同じ条件が要るとは書かれていません。

採用する時期についても、「CUSTOM_USER_TABLE is easiest to adopt during initial Setup your first instance of WordPress」と書かれています。すでに動いている会員サイトで採れるかどうかは、資料からは決まりません。

資料が述べているのは、設定が存在することと、使うときに要る条件までです。差し替えれば会員管理の課題が解決するとも、移行に何が要るとも書かれていません。標準の構成に収まらないことが、そのままWordPressをやめる理由になるわけではありませんが、差し替えが軽い手段だという意味にもなりません。

いまの困りごとが、設定の範囲で片づくか

ここまでの資料が示すのは、情報がどこに置かれるかと、独自テーブルを足す前に検討することまでです。どうするかは資料からは決まりません。以下は当方の判断基準です。出典が定めたものではないので、自社の事情に合わないと思ったら合わせて構いません。

困りごとが違えば、分かれ目も違います。次の表で、自社に当てはまる行を見てください。複数当てはまるなら、行ごとに判定します。「設定の範囲で片づく」には、設定の画面を見れば答えが出る場合と、設定を変えれば直る場合の両方が入ります。どちらも、実装に手を入れずに済むという意味です。

3行目については、これから記録を残せるかどうかは別の問いです。過ぎた分に答えられないことと、今後に備えられることは分けて考えてください。

設定の変更では片づかないと分かったとき、選ぶ先は大きく3つに分かれます。いまのまま運用でしのぐか、WordPressの上に足りない仕組みを作るか、別の構成へ移すかです。既存のプラグインへの交換や外部サービスとの連携は2つめに含めています。機能そのものをやめて要件を小さくする選択も残ります。どれを選ぶかは費用、時期、扱う情報の性質で変わるため、ここまでの材料では決まりません。決まるのは、設定の変更では片づかないので別の手を考える段階に来た、ということです。

どの行も、答えが出てくるまで判定できません。 自分で分からなければ「相談相手に確認すること」の項目を聞いてください。答えが出てこないこと自体は、設定で片づかないという意味にはなりません。分かってから決めます。別の構成へ移す場合の範囲と工程は、会員機能の作り替えにまとめています。

相談相手に確認すること

制作会社や開発の担当者へ聞くときは、次を聞いてください。前の節の表を判定できる形にしてあります。

• 管理画面から見えない会員情報と、表示条件との関係：会員情報のうち、管理画面から見えないものがあるか。あるなら何を持っているか。その情報が、誰に何を見せるかの判定に使われているか。使われているなら、設定の画面から確かめる手立てがあるか。
• 出し分けの条件を、突き合わせられるかどうか：会員限定の公開範囲を決めている条件が、どのプラグインのどの設定にあるか。役割の定義と、利用者への割り当てと、プラグインが足した条件の3つを、設定の画面だけで突き合わせられるか。突き合わせられないなら何が妨げているか。共通の定義を作って各画面から参照する形へ、設定の範囲で変えられるか。
• 履歴の有無と、取り出せるかどうか：権限の変更、退会、購入の記録が、必要な期間の分だけ残っているか。残っているならどこにあり、設定の画面から取り出せるか。残っていないなら、いま入っているプラグインの設定を変えて、今後の分を残せるか。
• 利用者を消したときの動き：退会の処理で、紐づく情報がどうなるか。実際に試して確かめられるか。