MT4.xプラグイン作成/管理画面のメニューに独自項目を追加する http://www.ark-web.jp/sandbox/wiki/300.html
MT4.xプラグイン作成/管理画面のメニューに独自項目を追加する
やりたいこと †
MTの管理画面には「システムメニュー」、「新規作成」、「一覧」、「設定」、「ツール」といった、マウスをフォーカスすると下層のメニューが表示される仕組みがあります。これらのメニューに任意の項目を追加することを行います。
方法 †
Pluginファイルのinit_registry()メソッドで設定することができます。
Pluginの作成に関してはMT4.0プラグイン作成?の他のコンテンツを参照してください。
メニューを追加するには、以下のようにします。
sub init_registry { my $plugin = shift; $plugin->registry({ : 'applications' => { 'cms' => { 'menus' => { 'manage:hoge' => { label => 'Hoge', order => 10000, mode => 'list_hoge', view => "system", }, }, : }, }, : });
これで、Hogeというメニューがシステム管理画面の[一覧]の中に並びます。また、Hogeには__mode=list_hogeへのリンクが張られます。
manage:[当該メニューのkey] => { label => [メニュー表示ラベル], order => [表示順], mode => [リンク先__mode], view => [表示先。systemならシステム管理画面、blogならブログ管理画面], },
といった形です。他にも system_permissionで管理者だけにアクセスを許すといった設定が可能です。
メニューIDのルール †
[登録先メニューkey]:[当該メニューのkey]で指定します。
登録先メニューのkeyは以下のように定義されています。
key | メニュー(日本語表記) |
create | 新規作成 |
manage | 一覧 |
design | デザイン |
prefs | 設定 |
tools | ツール |
system | システムメニュー |
従って、新しくkey=hogeのメニューを新規作成配下に追加する場合は
create:hoge
というIDを指定することになります。
メニューIDは全メニューを通してユニークである必要があります。
(メニューIDと呼称していますが、正しくはなんと呼べばいいのかわかりません^^;)
また、独自のkeyを追加することもできます。
# Hogeというkeyを作り、その配下にlistを追加する。 'hoge' => { label => 'Hoge', order => 10000, }, 'hoge:list' => { label => 'List of Hoge', order => 100, mode => 'list_hoge', },
orderの指定 †
orderは数値が大きいほど下(または右)に表示されます。
viewの指定 †
viewに指定できる値と挙動は次の通りです。
viewの値 | 挙動 |
system | システム管理画面のメニューに表示される |
blog | ブログ管理画面のメニューに表示される |
また、viewを指定しない場合、システム管理画面、ブログ管理画面の双方のメニューに表示されます
permissionの指定 †
ユーザのロールに応じたアクセス権を設定できます。
アクセス権限を持たないユーザに対してはメニューのリンクがデッドリンクになります。
これによって、例えば「テンプレートの管理」の権限を持つロールのユーザしかアクセスできないメニューなどを定義できます。
ロールの各権限とその権限を持つユーザにアクセスを許可するためにpermissionに指定する値の関係は以下の通りです。
権限 | permissionに指定する値 |
administer_blog | ブログ管理者 |
edit_config | ブログの設定 |
set_publish_paths | 公開パスの設定 |
edit_categories | カテゴリの管理 |
edit_tags | タグの管理 |
edit_notifications | アドレス帳の管理 |
view_blog_log | ログの閲覧 |
create_post | ブログ記事の作成 |
publish_post | ブログ記事の公開 |
send_notifications | 通知の送信 |
edit_all_posts | すべてのブログ記事の編集 |
manage_pages | ウェブページの管理 |
rebuild | ブログの再構築 |
edit_templates | テンプレートの管理 |
edit_assets | アイテムの管理 |
upload | ファイルアップロード |
save_image_defaults | 画像に関する既定値の設定 |
comment | コメントの送信 |
manage_feedback | コメント/トラックバックの管理 |
複数の権限に対して許可を与えたい場合は「,」で区切って以下のように設定します。
# ブログ記事の作成とコメントの送信の権限を持つロールにアクセスを許可 permission => 'create_post,comment'
system_permissionの指定 †
ユーザのシステム権限に応じたアクセス権を設定できます。
アクセス権限を持たないユーザに対してはメニューのリンクがデッドリンクになります。
これによって、例えば「ブログの作成」のシステム権限を持つユーザしかアクセスできないメニューなどを定義できます。
各システム権限とその権限を持つユーザにアクセスを許可するためにsystem_permissionに指定する値の関係は以下の通りです。
システム権限 | system_permissionに指定する値 |
administer | システム管理者 |
create_blog | ブログの作成 |
view_log | ログの閲覧 |
edit_templates | テンプレートの管理 |
manage_plugins | プラグインの管理 |
複数の権限に対して許可を与えたい場合はpermissionと同様に「,」で区切って設定します。
その他のプロパティ †
メニューIDに指定できるその他のプロパティには調べた範囲では以下があります*1
- args
- condition
- dialog
args †
メニューのリンクに引き渡すQueryStringのパラメータを指定します。例えば、
mode => 'hoge', args => { _type => "blog" },
と指定した場合、メニューに指定されるリンクは
__mode=hoge&_type=blog
となります。
condition †
permission(およびsystem_permission)の判断をTrue(1) or False(0)を返すメソッドによって指定することができます。より複雑な権限設定を行いたい場合に便利です。
例えば、以下のようにします。
condition => sub { &permission_routine() }, sub permission_routine { my $app = MT->app; # スーパーユーザなら無条件でアクセス可(True) return 1 if $app->user->is_superuser; # パラメータでブログIDが指定されていて if ( $app->param('blog_id') ) { # 当該ユーザがブログ記事の作成、またはウェブページの管理権限を持っている場合もアクセス可(True) my $perms = $app->user->permissions($app->param('blog_id')); return 1 if $perms->can_create_post || $perms->can_manage_pages; } # それ以外はアクセス不可(False) return 0; }
権限判定のメソッドはMT::PermissionオブジェクトのAPIを利用できます。基本的にはpermissionプロパティに指定する値にcan_をつけたメソッド名になっています。例えば、ブログ記事の作成権限を示すcreate_postをそのユーザが持つかどうかは、当該ユーザのMT::Permissionオブジェクトを取得した後、そのMT::Permissionオブジェクトのcan_create_postメソッドをコールします*2。
dialog †
リンク先をモーダルダイアログで表示したい場合にmodeの代わりに指定します。指定する値はmodeプロパティに指定する値と同様、表示したい画面をあらわす__mode値です。
# __mode=hogeの画面をモーダルダイアログで表示する #mode => 'hoge', dialog => 'hoge',
*1 Creating Menu ItemsやMovable Type Registry Referenceには全てのプロパティが網羅されていないようです(2008/06/12現在)そのため、ソースコードを直接確認して洗い出したプロパティが含まれます。system_permissionは既にその一例になっています
*2 $app->userからコールしているis_superuserやpermissionsメソッドは2008/06/13現在、APIドキュメントには記載されていないので、使わない方がよいのかも^^;