小粋空間: プラグイン開発アーカイブ

Top ＞ Movable Type ＞プラグイン開発 [全て閉じる]

2012年2月 8日

Movable Typeの一覧画面にリストアクションを追加する

February 8,2012 2:55 AM
Tag：[MovableType, Plugin]
Permalink

Movable Typeのプラグイン開発ネタで、一覧画面にリストアクションを追加する方法です。バージョンは5.1以降です。

「リストアクション」とは、一覧画面内に表示されたチェックボックスをチェックして動作をさせるための機能です。

リストアクションのメニューを表示

１．プラグインのリストアクションを追加する

プラグインのリストアクションは、次のように「プラグインアクション」というoptgroup要素の中に追加したアクションが表示されます。

プラグインのリストアクション

プラグインのリストアクションを追加するには、次の内容をfoo.plなど任意のファイル名でplugins配下にアップロードします。赤色部分がリストアクション定義です。

package MT::Plugin::Foo;
 
use strict;
use base qw( MT::Plugin );
 
my $plugin  = MT::Plugin::Foo->new({
    id          => 'foo',
    name        => 'foo',
    description => 'This is foo',
    version     => '0.1',
    registry => {
        list_actions => {
            entry => {
                foo => {
                    label => 'foo',
                    mode => 'foo',
                    order => 1000
                },
            },
        },
    },
});
MT->add_plugin($plugin);

２．コア機能としてリストアクションを追加する

コア機能としてのリストアクションは次のように、既存のリストアクションと並べて表示でき、１項のリストアクションよりメニューがすっきりします。もちろんメニューからの動作はプラグインで実装可能です。

コア機能のリストアクション

コア機能としてリストアクションを追加するには、次の内容をfoo.plなど任意のファイル名でplugins配下にアップロードします。

package MT::Plugin::Foo;
 
use strict;
use base qw( MT::Plugin );
 
my $plugin  = MT::Plugin::Foo->new({
    id          => 'foo',
    name        => 'foo',
    description => 'This is foo',
    version     => '0.1',
    registry => {
        callbacks => {
            init_request => \&init_request,
        },
    },
});
MT->add_plugin($plugin);
 
sub init_request {
    my ($eh, $app) = @_;
    my $core = MT->component("core");
    $core->registry("list_actions", "entry", "foo",
        {
            label => 'foo',
            mode => 'foo',
            order => 1000,
        });
}
1;

１項との違いは、プラグインのレジストリにlist_actionsを追加するのではなく、init_request実行契機でコア機能（$core）のレジストリに追加している点です。

registry()のパラメータにサンプルのようなハッシュ形式を記載すれば、list_actions以外の内容でも追加することができます。

    $core->registry("list_actions", "entry", "foo",
        {
            label => 'foo',
            mode => 'foo',
            order => 1000,
        });

３．注意事項

プラグイン定義はYAMLでも記述することができますが、MT5.12現在では、次のようなYAMLを定義しても一覧画面にリストアクションを追加することができないようです。

id: foo
name: foo
version: 0.01
list_actions:
    entry:
        foo:
            label: 'foo'
            mode: foo
            order: 1000

Comments [0] | Trackbacks [0]

2011年1月 3日

Movable TypeのプラグインオブジェクトをPerlで作成するときのバリエーション

January 3,2011 1:55 AM
Tag：[MovableType, Perl, Plugin]
Permalink

Movable Type のPerlによるプラグインオブジェクトを作成するサンプルは次のような感じです。

その1

package MT::Plugin::MyPlugin;
use strict;
use base qw( MT::Plugin );
 
my $plugin = new MT::Plugin::MyPlugin({
    name => 'Sample Plugin: registration',
    version => 1.0,
    description => "Sample: Plugin registration",
    author_name => 'Plugin author',
    author_link => 'http://www.example.com/about/',
    doc_link => 'http://www.example.com/docs/',
});
MT->add_plugin($plugin);

で、何かの拍子にプラグインを調べたときに、プラグインオブジェクトの作成（青色部分）で色々なコードをみつけたので紹介しておきます。コピペミスあったらすいません。

その2

my $plugin = new MT::Plugin({
…中略…
});

その3

my $plugin = MT::Plugin::MyPlugin->new({
…中略…
});
MT->add_plugin( $plugin );

その4

my $plugin = __PACKAGE__->new({
…中略…
});
MT->add_plugin( $plugin );

その5

MT->add_plugin({
…中略…
});

その6

MT->add_plugin(__PACKAGE__->new({
…中略…
}));

その7

my $plugin;
{
    my $about = {
        …中略…
        },
    };
    $plugin = __PACKAGE__->new($about);
}
MT->add_plugin($plugin);

私はYAMLです（笑）。

Comments [0] | Trackbacks [0]

2010年11月 6日

Movable Typeのプラグインファイル構成について

November 6,2010 2:02 AM
Tag：[Developer, MovableType, Plugin]
Permalink

Movable Typeのプラグインファイル構成について紹介します。

MTQでプラグインファイルについて質問があり、このエントリーを書くことにしました。質問の要旨は次の通りです。

プラグインにはYAMLファイルがないものが多く、単にxxx.plのみで配布されているものもあります。またlibディレクトリ内の～.pmというファイルもあったりなかったりします。どういう時にこれらのファイルを選択または使用しているのでしょうか。

ということで、本エントリーではプラグインファイルの選択・配置について解説します。

１．YAMLファイル（config.yaml）の有無について

YAMLファイル（config.yaml）は、プラグインの定義（プラグイン名やバージョン、プラグインの初期設定など）を行うためのファイルで、Movable Type 4からYAML形式でのプラグイン定義ができるようになりました（下）。

config.yaml

id: MyPlugin
name: Sample plugin
version: 1.0
description: Sample plugin
author_name: Plugin author
author_link: http://www.example.com/about/
doc_link: http://www.example.com/MyPlugin/docs/
…後略…

Movable Type 4以前のMovable TypeプラグインはPerl言語しか許容されておらず、その際に定義するプラグインファイルがxxx.plというファイルです（下）。拡張子が.plであればファイル名は任意です。

MyPlugin.pl

package MT::Plugin::MyPlugin;
use strict;
use base qw( MT::Plugin );
 
my $plugin = new MT::Plugin::MyPlugin({
    name => 'Sample Plugin',
    version => 1.0,
    description => 'Sample plugin',
    author_name => 'Plugin author',
    author_link => 'http://www.example.com/about/',
    doc_link => 'http://www.example.com/MyPlugin/docs/',
});
MT->add_plugin($plugin);

プラグインの機能を実現する上では、PerlでもYAMLでもプラグイン定義に関する機能の違いはありませんが、上のコードから分かるようにYAMLの方がシンプルに記述できます。~~以前開催されたMTDDCの澤田さんのスライドで「YAMLは実行コードを含まないのでセキュア」というお話もありました。~~→Perlとの違いはありませんでした。参考：「Re: Movable Typeのプラグインファイル構成について」

２．YAML形式で定義されたプラグインが少ない理由など

YAML形式で定義されたプラグインが少ないとすれば、以下の理由が考えられます。あくまで推測です。

配布プラグインがMovable Type 3の時代に作られており、バージョンアップを行ってもPerl形式のプラグイン定義が継承されている。
Movable Type 3との互換性を考慮してPerl形式のプラグインを開発している。
Perl形式のプラグイン開発が定着しており、Movable Type 4以降もPerlで開発を行っている。
YAMLでのプラグイン開発に関する情報が少ない。

ちなみに私は、最近作っているプラグインについてはすべてYAMLで定義しています。以前開発したプラグインもバージョンアップの機会があればYAMLにリファクタリングしています。

最初はYAMLのお作法になじまなかったのですが、Perlよりも楽に記述でき、最近は重宝しています。

３．libディレクトリ（モジュール）の必要性について

１項で説明したプラグイン定義をPerlで実装すれば、そのファイルでPerlが扱えるので、すべてのコードをまとめて記述することもできます。ただし、1つのファイルにすべてのコードを埋め込むと、コード自体の機能が不明確になります。

config.yamlにもPerlのコードを記述することは可能ですが、いずれにしても機能分担を明確にするために、モジュールを作成した方が良いと思います。そうすることでコードの保守性が向上します。MTのコア機能でも、オブジェクトや機能別にモジュールに分割して、lib/MT配下に配置しています。

lib（library）ディレクトリ配下にモジュールを配置するのは、LinuxやPerl言語のお作法のようです。プラグインもこの形式に倣った配置が行えます。プラグイン定義ファイルにモジュール名を記述する場合も、libディレクトリを意識せずに定義できるようになっています（YAMLでの定義については後述）。

４．libディレクトリ配下の構成について

lib配下に直接モジュール（xxx.pm）を配置しても構いませんが、よくみかけるのは、次のようにプラグイン名のディレクトリを配置し、その配下にモジュールまたはディレクトリを配置する方法です。

下はMyPluginというプラグインのモジュール配置例です。

MT_DIR/
  └ plugins/
      └ MyPlugin/
          ├ config.yaml
          └ lib/
             └ MyPlugin/
                ├ Tags.pm
                └ CMS.pm

この例のように、Tags.pmやCMS.pmという、意味のある名称にしたモジュールを配置すれば機能分担が明確になり、保守性が向上します。より大規模なプラグインを開発する場合、さらにディレクトリやファイルを分割しても良いでしょう。

５．config.yamlでのモジュール定義

４項のようにモジュールを配置した場合、config.yamlでのモジュール（Tags.pm/CMS.pm）の記述は次のように行います。Tags.pmには
_hdlr_fooと_hdlr_barというメソッド、CMS.pmには_add_fieldと_set_paramというメソッドがあると仮定します。

…前略…
tags:
    block:
        MTFooLoop: $MyPlugin::MyPlugin::Tags::_hdlr_foo
    function:
        MTFooName: $MyPlugin::MyPlugin::Tags::_hdlr_bar
callbacks:
    MT::App::CMS::template_source.edit_entry: $MyPlugin::MyPlugin::CMS::_add_field
    MT::App::CMS::template_param.edit_entry: $MyPlugin::MyPlugin::CMS::_set_param

それぞれのハッシュの右辺にある「$MyPlugin::MyPlugin::Tags::_hdlr_foo」というフォーマットは、「$+プラグイン名::lib配下のプラグインディレクトリ名::モジュール名::メソッド名」になります。

この部分の定義が実際のディレクトリ・ファイル配置やモジュールの先頭に記述したパッケージ名と異なっていると正常に動作しません。大文字・小文字の違いも動作しない原因となります。

６．YAML形式での開発について

YAML形式のプラグイン定義の弱点は、エラーが発生するとPerlでの定義よりも原因が分かりにくい点ですが、５項の設定がきちんと行えていればその事象に遭遇することはないと思います。

よって、YAML形式のプラグイン定義でプラグインを開発する場合、既存の配布プラグインで自分が作りたいタイプ（拡張テンプレートタグやコールバックなど）に近いものを選び、ファイル名やパッケージ名・メソッド名だけを書き換えてファイル構成は流用する方法をお勧めします。モジュール内のPerlエラーについては、YAMLもPerlも特に違いはなく、システムログにメッセージが出力されます。

当ブログで公開している最近のプラグインは以下のリンクから利用してください。