WordPressの権限設定において、標準のロールだけではしっくりこないの場合にカスタマイズする方法メモです。
ロールとケイパビリティ
まず押さえておきたい基本として、WordPressの権限は、「ロール(role)」と「ケイパビリティ(capability)」という2つの単位で管理されていること。
- ケイパビリティ（Capability）
「記事を投稿できる」「プラグインを有効化できる」のような、個別の操作権限のこと - ロール（Role）
ケイパビリティをひとまとめにした権限グループのこと。ユーザーにはロールを割り当てることで、そこに含まれるケイパビリティがまとめて付与される
1人ずつケイパビリティを設定するのは現実的ではないので、あらかじめ用途別にまとめられたロールをユーザーに割り当てる、という仕組みになっています。
権限カスタマイズの基本コード
【権限グループ（ロール）の名称・操作範囲】
| 名称（日本語） | 名称（英語・設定用） | 操作範囲（権限） |
|---|---|---|
| 管理者 | administrator | 全ての機能操作が可能 |
| 編集者 | editor | 全投稿記事の編集・削除・公開が可能 |
| 投稿者 | author | そのユーザーが作成した記事のみ編集・削除・公開が可能 |
| 寄稿者 | contributor | 記事の作成・編集が可能で、公開することはできない |
| 購読者 | subscriber | 記事の閲覧のみ可能 |
この表では上から順にできること少なくなっていき、管理画面の表示メニューも変わります。
【権限や権限グループの追加・削除】
| add_cap() | 既存のロールにケイパビリティを追加 |
| remove_cap() | 既存のロールからケイパビリティを削除 |
| add_role() | 新しいロールを追加 |
| remove_role() | ロールそのものを削除 |
いずれもfunctions.phpに直接書いてもよいですが、ロールの追加・削除は毎回のページ表示で実行する必要がない処理なので、プラグインの有効化時やテーマの切り替え時に1度だけ実行するようにしておくと無駄がありません。
【権限の一例】
| 記事を見る | read |
| 記事を書く・編集する | edit_posts |
| 記事を公開する | publish_posts |
| プラグインのインストール | install_plugin |
| カテゴリーを編集 | manage_categories |
| ユーザー作成 | create_users |
| コメント管理 | moderate_comments |
上記で紹介したもの以外にもさまざまな権限が設定できます。設定できる権限一覧は以下のページを参照ください。
既存の権限グループに権限（ケイパビリティ）を追加
元々存在する権限グループにある権限を追加する際に add_cap() を使用します。
例えば寄稿者(通常は画像をアップロードできない)にメディアファイルのアップロードも許可したい場合、次のように記述します。
function komari_allow_contributor_upload() {
$role = get_role( 'contributor' );
if ( $role ) {
$role->add_cap( 'upload_files' );
}
}
add_action( 'init', 'komari_allow_contributor_upload' );get_role('権限グループ') で変更したい権限グループを指定、取得した権限グループに add_cap('権限名') で権限を追加し、アクションフックを利用して登録します。
新しく権限グループを追加
新しく権限グループを追加したい場合は以下のようなコードを記述します。
function komari_add_content_editor_role() {
add_role(
'content_editor',
'コンテンツ編集者',
array(
'read' => true,
'edit_posts' => true,
'edit_others_posts' => true,
'publish_posts' => true,
'upload_files' => true,
'delete_posts' => false,
)
);
}
add_action( 'init', 'komari_add_content_editor_role' );
add_role('権限グループ名', '表示名', ケイパビリティ（配列）);
既存ロールのケイパビリティ一覧をコピーしてきて、必要な行だけ書き換えるとやりやすいです。
他の権限グループの権限を利用するのではなく、一から権限を設定する場合は、機能名を配列で指定します。'機能名' => true, でその権限が追加されます。
function add_user_role() {
$new_cap = [
'edit_posts' => true,
'read' => true,
'delete_posts' => true,
];
add_role('my_user_role', '新しい権限グループ', $new_cap);
}
add_action('admin_init', 'add_user_role');【参照】add_role() – Function | Developer.WordPress.org
登録できれば、ユーザーページの権限グループのリストに表示されます。
権限グループからケイパビリティを外す・ロールごと削除する
既存ロールから特定のケイパビリティだけ外したいときはremove_cap()を使います。
$role = get_role( 'editor' );
$role->remove_cap( 'delete_posts' );remove_role() でロールごと削除できます。
function remove_user_role() {
remove_role('subscriber');
}
add_action('admin_init', 'remove_user_role');なお、remove_role()はあくまでロールの定義を削除するだけで、そのロールを割り当てられていたユーザーは自動的に別のロールへ移動しません。削除する前に、該当ユーザーのロールを付け替えておく必要があります。
実務で使えるスタマイズ事例
実際のWordPress運営では、標準の「管理者・編集者・投稿者」だけでは不十分なケースが多々あります。いくつかカスタマイズ例をご紹介します。
他人の投稿を削除させたくないコンテンツ編集者
編集者ロールは、投稿・固定ページの編集・公開に加えて、他のユーザーの投稿を削除する権限や、HTMLタグを制限なく入力できる権限も持っています。複数人に編集者相当の権限を渡したいけれど、この2点までは渡したくない、というケースで、以下のカスタマイズがおすすめです。
function komari_add_content_editor_role() {
$editor = get_role( 'editor' );
if ( ! $editor ) {
return;
}
add_role( 'content_editor', 'コンテンツ編集者', $editor->capabilities );
$content_editor = get_role( 'content_editor' );
$content_editor->remove_cap( 'delete_posts' );
$content_editor->remove_cap( 'delete_others_posts' );
$content_editor->remove_cap( 'delete_published_posts' );
$content_editor->remove_cap( 'unfiltered_html' );
}
add_action( 'init', 'komari_add_content_editor_role' );
get_role('editor')->capabilities で編集者ロールのケイパビリティ一覧をそのまま取得し、add_role() の第3引数に渡すことで、編集者と同じ権限を持つ別ロールとしてコピーできます。
そこから削除系の権限と unfiltered_html だけを外せば、「投稿の編集・公開はできるが、削除やスクリプトの直接入力はできない」ロールになります。
外部ライター向け「寄稿者＋画像アップロード」
外部ライターにいきなり公開権限まで渡すのは避けたい場合、下書きの作成までしかできない寄稿者ロールが適切でしょう。
ただし寄稿者ロールは標準では画像などのメディアをアップロードできないため、執筆に必要な画像だけは自分でアップロードできるように upload_files を追加しておきます。
function komari_add_writer_role() {
$contributor = get_role( 'contributor' );
if ( ! $contributor ) {
return;
}
add_role( 'external_writer', '外部ライター', $contributor->capabilities );
$writer = get_role( 'external_writer' );
$writer->add_cap( 'upload_files' );
}
add_action( 'init', 'komari_add_writer_role' );
プラグインの更新作業だけを任せたい運用担当者ロール
サイト運営を手伝ってもらっている担当者に、プラグインの更新作業だけ任せたいといったケース。
activate_pluginsとupdate_pluginsだけを持たせています。
function komari_add_plugin_updater_role() {
add_role(
'plugin_updater',
'プラグイン更新担当',
array(
'read' => true,
'activate_plugins' => true,
'update_plugins' => true,
)
);
}
add_action( 'init', 'komari_add_plugin_updater_role' );
これでテーマ編集やユーザー管理には触れさせずに、プラグインの更新作業だけを任せられます。
会員制サイトやECサイトでの専用権限
会員制サイトやECサイトなどは、より一層セキュリティと運営効率の両立を考えて、サイトの性質に応じて適切に権限を調整する必要があります。
購読者ロールをベースに、会員ランクごとに閲覧できるコンテンツを制御したり、EC機能側のケイパビリティ(注文の閲覧など)を追加したりと、サイトの性質に合わせた専用ロールを作るケースも多いです。購読者ロールをベースに、独自のケイパビリティを1つ追加して、コンテンツの表示を出し分けるという方法もあります。
function komari_add_premium_member_role() {
add_role(
'premium_member',
'プレミアム会員',
array(
'read' => true,
'read_premium_content' => true,
)
);
}
add_action( 'init', 'komari_add_premium_member_role' );
read_premium_contentはWordPressが標準で用意しているケイパビリティではなく、このロール専用に決めた名前です。テンプレート側で次のように判定すれば、このロールを持つユーザーだけに限定コンテンツを表示できます。
if ( current_user_can( 'read_premium_content' ) ) {
// 限定コンテンツを表示する処理
}会員サイト構築系のプラグインを使っている場合は、プラグイン側が独自のロールやケイパビリティをすでに用意していることが多いので、まずはそちらを確認してから、足りない部分だけ自前でカスタマイズやり方もあります。
まとめ
標準のロールで足りない部分は、add_role()・add_cap()・remove_cap()・remove_role()の4つでだいたい対応できそうです。特にプラグインまわりの権限は、渡しすぎるとサイトの乗っ取りにつながりかねない強い権限なので、必要な操作だけに絞ったロールを新規に用意する、渡す必要がなければDISALLOW_FILE_EDITで編集機能自体を閉じる、というあたりを基準に考えるとよさそうです。
標準ロールそれぞれの範囲については以下の記事にまとめてあるので、あわせて確認しておくと判断しやすいと思います。
