WordPress 4.7のterm capabilityは分類を編集する人とtermを分けて確認する

WordPress 4.7では、特定のcategory、tag、custom taxonomyのtermを編集、削除、投稿へ付与できるかを、termごとに確認するcapabilityが加わりました。使うときは、まず誰が分類全体を管理するかを役割で決めます。そのうえで、特定のtermだけを保護したい理由がある場合に、edit_term、delete_term、assign_termを使います。新しいcapabilityを使うだけで、既存の利用者の権限が細かく分かれるわけではありません。

termは、categoryやtagなどの分類項目です。「お知らせ」というcategory、「採用」というtag、商品種別や地域を表すcustom taxonomyの個々の項目がtermです。投稿を編集できる人と、分類を追加したり変更したりできる人は同じとは限りません。投稿担当者には記事を書ける権限を渡し、分類名やURLに関わる変更は別の担当者に残す、といった分け方が必要になることがあります。

新しいterm capabilityは既存の権限を急に変えない

WordPress 4.7で加わったedit_term、delete_term、assign_termは、特定のtermを対象にしたmeta capabilityです。標準の動作では、既存の分類用capabilityへ対応付けられます。categoryならmanage_categoriesなど、taxonomyを登録するときに指定したcapabilityが判断の土台になります。そのため、WordPress 4.7へ更新した直後に、利用者が急に特定のcategoryを編集できなくなったり、逆に権限が広がったりする変更ではありません。

ここを誤解すると、「個別termを守れるようになったから、権限の設計は終わった」と考えがちです。しかし、個別の判断を加えない限り、元のroleとtaxonomyのcapabilityが決める範囲は残ります。新しいcapabilityは、特定termについて追加の判断を入れる入口です。siteの運用で必要なのは、どの分類を誰が作り、誰が投稿へ付け、誰が削除できるかを先に決めることです。

説明用の仮例として、商品siteに「販売中」「販売終了」「準備中」というtermがある場合を考えます。記事を書く担当者が商品へ「販売中」を付けられるとしても、誤って「販売終了」を削除してよいとは限りません。販売終了のarchiveには古い商品へのlinkが残るかもしれません。投稿へtermを付ける仕事と、termそのものを消す仕事は、画面では近く見えても、公開URLと過去記事へ与える影響が違います。

編集、削除、付与を同じ作業として扱わない

edit_termはtermの名前、slug、説明などを変更する判断に使えます。delete_termはtermを削除する判断に使えます。assign_termは、投稿などのobjectへtermを付ける判断に使えます。この三つは似ていますが、失敗したときの影響が違います。

たとえば地域分類の「東京」というtermを「東京都」へ変えると、分類archiveのURLや、そのURLへ向けたlinkを確認する必要があります。termを削除すれば、そのtermが付いた投稿を読者がどこから探すかも変わります。一方で、新しい施工例へ既存の地域termを付けるだけなら、分類の構造は変えません。投稿担当者が選ぶ範囲を広くし、分類構造を変える範囲を狭くする方が、日々の更新を止めずに済みます。

分類を個別に保護したい場合、map_meta_cap filterで、対象termに応じた追加の判断を入れられます。WordPressの例では、保護したtermを削除しようとする場合に、必要なcapabilityへdo_not_allowを加えています。これは、特定termを消せなくする方法の例です。全ての分類を個別に制限すべき、という意味ではありません。

個別制限を作る前に、なぜそのtermだけ保護するのかを説明できるようにします。法令に関わる分類、URLを長く運用している分類、複数部門が使う共通分類なら、保護する理由があります。単に名称が気に入らない、作成者が違うという理由だけで細かい制限を足すと、更新のたびに誰へ頼むかが分からなくなります。制限は、作業を止めるためではなく、間違えた変更が公開へ及ぶ範囲を小さくするために使います。

categoryとtagは同じ権限のままと決めつけない

WordPress 4.7では、post tag taxonomyがcategoryとは別のcapabilityを標準で使うようになりました。既存の動作は変わらないと説明されていますが、tagとcategoryを別に扱うcodeを作れるようになります。これを、tagを自由に増やしてよいという意味にしません。categoryとtagは、site内で果たす役割が違うため、運用上の決め方も分けます。

categoryを記事の大きな主題に使い、tagを専門語や横断する条件に使うsiteなら、categoryを増やす判断は慎重になります。categoryを増やすと、menu、archive、内部linkの設計へ影響します。tagは細かく付けられても、同義語を増やせば一覧が分散します。WordPressのcapabilityを分けられることと、分類の基準を分けずに運用してよいことは別です。

説明用の仮例として、編集担当者が毎日の記事へtagを付け、サイト管理者がcategoryを決める場合を考えます。この役割分担では、編集担当者が既存tagを付けられる範囲と、新しいtagを作れる範囲を別にします。管理者はcategoryを増やす前に、archiveを作るか、何本の記事を置くか、menuから案内するかを確認します。画面上の権限設定は、この分類方針を実行するためのものです。

権限を変える前に四つの画面を確認する

term capabilityやmap_meta_capを使うcodeを加えたら、管理者だけで確認して終えません。権限が違う代表利用者で、termを作る、編集する、投稿へ付ける、削除する画面を確認します。許可する操作だけが動き、禁止する操作が適切に止まるかを見ます。

確認する利用者は、少なくとも分類を管理する人、記事を更新する人、閲覧だけする人に分けます。実際の利用者accountを使えない場合は、test用accountでroleを再現します。管理者accountで一度動いたことは、ほかのroleで同じように動く証明になりません。

1. 分類を管理するroleで、対象termを編集、削除、投稿へ付与できるかを確認する。
2. 投稿を更新するroleで、許可したtermを付けられ、禁止した操作へ進めないかを確認する。
3. 閲覧用roleで、管理画面の操作linkや不要な情報が出ないかを確認する。
4. 公開pageと分類archiveを開き、term名、URL、投稿一覧が意図どおりかを確認する。

公開siteで権限を替えると、担当者が日々の更新をできなくなる場合があります。staging環境でroleとtermの組合せを試し、変更したcode、対象taxonomy、対象term、確認したaccountを残します。外部の制作会社へ依頼するなら、誰が何をできるようにするかだけでなく、できなくする操作、例外にするterm、公開pageで確認するURLも渡します。

最初の一手は、現在のtaxonomyごとに、作成、編集、削除、付与を誰が行うかを書き出すことです。その表で保護が必要なtermだけを選びます。WordPress 4.7のterm capabilityは、その判断をcodeへ反映するために使います。