カスタム投稿タイプに独自の編集権限を与えていた時、カスタムタクソノミーを設定する権限も厳格化したっぽい

お客さんから、連絡が来て気づいた問題。

うまくまとまらんけどとりあえずメモ書き程度に書く。
似たような状況に陥った人に見つけてもらえれば良いけどｗ

先に結論

カスタムタクソノミーのcapabilitiesも正確に設定しよう。

状況

状況としてはこんな感じ

• カスタム投稿タイプ（仮にnewsとする）が設定されている。
  • capability_typeとしてnewsが設定されている。
• カスタム投稿タイプにはカスタムタクソノミー（仮にnews-categoryとする）が設定されている。
  • capabilitiesは初期設定のママ
• newsのみを投稿・修正することができる権限（仮に「ニュース投稿者」とする）が設定されている。
• ニュース投稿者にはカスタム権限として、newsに関する全ての権限が与えられている（edit_newssとか）
• エディタはブロックエディタ。

何が起きたか

この状態で、WordPress 5.4までは問題なくnews-categoryはnewsに対して設定ができていたのだけど、どうやら5.4.1のアップデート（またはそれに準ずるセキュリティーリリース(ex. 5.3.3)）のタイミングで設定ができなくなったらしい。

クラシックエディタを入れてチェックしていないので正確なところまではわからないけど、投稿画面のJSのコンソールでREST APIがタクソノミー関連のアクセスに対して403エラーを返していたので、クラシックエディタを使用していたら問題は発生してなかったかも。

解決策

状況の2つ目の補足「capabilitiesは初期設定のママ」というのがネックになっています。

カスタムタクソノミーのcapabilitiesは初期設定では以下の状態です

[
  'manage_terms' => 'manage_categories',
  'edit_terms'   => 'manage_categories',
  'delete_terms' => 'manage_categories',
  'assign_terms' => 'edit_posts',
]

（参考 : Function Reference/register taxonomy / 日本語）

この中の’assign_terms’が投稿に対してタクソノミーを紐付ける権限で、初期設定は’edit_posts’。つまり、通常の投稿(post)を投稿することが出来る権限。

これの権限チェックがどうやら厳格化されたようなので、ここの権限を以下のように変更します。

'assign_terms' => 'edit_newss',

（newssに違和感があるのはWordPressの仕様なので無視。）

つまり、ちゃんと正しい権限を与えてあげてねということ。

ニュース投稿者は’edit_newss’という権限しか持っておらず、’edit_posts’という権限は与えられていないのでむしろ今までの権限設定が甘すぎたわけです。
今回の修正はそのあたりの権限設定も厳格化されたという流れ。

それ以外にも今回のセキュリティーリリースでは色々な問題が修正され、それに伴い一部の環境ではページが閲覧できなくなるなどの問題が発生していますが、この件についてもその一部かなと思われます。

もし、似たような状態が発生した場合はこちらを参考に設定を見直してみてください。