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

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

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公式のコードリファレンスに載っている wpdb のソースコードは、サイトごとのテーブルを posts・comments・links・options・postmeta・terms・term_taxonomy・term_relationships・termmeta・commentmeta の10個、インストール全体のテーブルを users・usermeta の2個として持っています。この12個に、操作の記録を残すためと名前から分かるものはありません。ページは usermeta を利用者の追加情報の置き場所として説明していますが、会員機能が足した情報がどこに入るかは書いていません。置き場所の候補としては、標準のテーブルの中、プラグインが足したテーブル、別のデータベース、外部のサービスなどが考えられます。候補の並びは当方の見立てで、資料が挙げたものではありません。マルチサイト（1つのWordPressで複数のサイトを動かす構成）用のテーブルは別の一覧にあり、その中には registration_log という名前のものがありますが、マルチサイトの構成で使うもので、権限の変更や退会を記録するとは書かれていません。非推奨のテーブルも別の一覧にあります。

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

標準の置き場所で足りないとき、プラグインや実装で独自のテーブルを足す選択肢があります。ハンドブックは、その前に検討することを求めています。「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.」

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

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

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

WordPressの設定ファイル（wp-config.php）には、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」と説明しています。

つまり、利用者の情報を標準以外の場所に置く構成を、提供元自身が想定しています。ただし、条件も同じ資料の注意書きに書かれています。注意書きによれば、CUSTOM_USER_META_TABLE を設定しても、usermeta テーブルはデータベースごとに作られ、インストールごとの権限はそこに入ります。インストーラーは標準で最初の利用者（ID 1）に権限を付けます。また「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」とあります。注意書きは「each instance」「each of the site」と、インストールが複数ある場合の書き方をしており、1つのサイトだけで差し替える場合にどこまで同じ条件が当てはまるかは書かれていません。

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

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

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

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

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

どの行も、答えが出てくるまで判定できません。自分で分からなければ「相談相手に確認すること」の項目を聞いてください。答えが出てこないこと自体は、設定の範囲で片づかないという意味にはなりません。分かってから決めます。設定の範囲で片づかないと分かったときの選び方には、いまのまま運用でしのぐ、WordPressの上で足りない部分を補う（既存のプラグインへの交換や外部サービスとの連携を含みます）、別の構成へ移す、機能そのものをやめて要件を小さくする、といったものがあり、費用、時期、扱う情報の性質で選びます。別の構成へ移す場合の範囲と工程は、会員機能の作り替えにまとめています。

相談相手に確認すること

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

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