エンジニアブログ

エンジニアブログ
MT技術情報

プラグイン周りについて ~ プラグインセット

ぴろり上西 2011年05月25日

 Movable Type 5 ユーザーコミュニティ:MTQ で次のような質問がありました。

プラグインのセットを作りたいのですが
プラグインの名前でyamlを作成してみたりしたのですが、セットとして認識されませんでした。やはり、下記のように .pl で書き直さないとだめでしょうか?

 この質問についての答えは Yes です。/plugins の下の一つのサブディレクトリ内に複数のプラグインを配置するには YAML ではなく Perl スクリプトで書かれたプラグインを置かねばなりません。これに関係して、少し調べた部分をまとめておきます。
 プラグインを読み込んでいるところのソースコード(/lib/MT.pm, _init_plugins_core 関数、MT5.1 まで変更されていないみたい)を見ると、おおむね以下のような手続きになっていることがわかります。

  1. /plugins ディレクトリの中を調べる (opendir~readdir~closedir)
    1. 拡張子が .pl のファイルであれば、Perl で書かれたプラグインとして読み込む
    2. 拡張子が .pl 以外のファイルは無視される
    3. サブディレクトリの中に config.yaml があれば、YAML で書かれたプラグインとして読み込む
    4. サブディレクトリの中を調べる (opendir~readdir~closedir)
      1. 拡張子が .pl のファイルであれば、Perl 通常ので書かれたプラグインとして読み込む
      2. 拡張子が .pl 以外のファイルは無視される

 という感じです。YAML によるプラグイン定義は config.yaml というファイル名で固定されており、サブディレクトリ内に config.yaml が存在した時点でそれが読み込まれ、次のサブディレクトリに処理が移ります。ですので MTQ での質問のように、一つのディレクトリに複数のプラグインを配置したい場合には、拡張子が .pl の Perl スクリプトとして配置するしかありません。

 ところで、話しは逸れますが、MT4 以降、プラグインは従来の Perl スクリプト形式に加えて YAML 形式が採用されました。シックスアパートでは YAML によるプラグイン作成を推奨しているようですが、個人的には従来の Perl スクリプトによる作成方法が好ましいように感じています。理由は以下の通りです。

 1. Perl スクリプトで書かれたプラグインは、一つのサブディレクトリ内に一つ以上配置できますが、config.yaml による記述では、一つのサブディレクトリにつき一つのプラグインしか配置できません。そのため、それぞれ関連する機能を提供しあう複数のプラグインの集合という管理ができません。
 プラグインによって提供されたある一連の機能について、それらをまとめて削除したい場合、Perl スクリプトで提供されるプラグインは、そのサブディレクトリ一つを削除すれば問題ありませんが、YAML によって提供されたプラグインは、どれらのサブディレクトリを削除すればよいのか人間が知っている必要があります。
 MTCMS に搭載されているサイトマップダッシュボード機能はプラグインとして提供されている機能の一つで、ダッシュボード上に某 Windows 風なサイトマップを表示することができます。このダッシュボード上から、ダイアログウィンドゥを開いて、いきなりサブカテゴリやサブフォルダを作成したり、フォルダごとにアセットをフィルタリングするなどの機能が提供されていますが、これらの機能はこのダッシュボードの拡張として存在しています。故に、これらの機能はそれぞれが .pl ファイルとして一つのディレクトリに配置されています。もしサイトマップダッシュボードのプラグイン自体が不要になれば、そのディレクトリ一つを削除すればよいのです。

 2. プラグインの下位互換性を考えた場合、例えば、簡単なテンプレートタグを拡張する程度のプラグインであれば、config.yaml を使わずに、更に registry さえも使わずに、MT::Template::Context->add_tag と MT3 時代の方法を使い続けることで、MT3 ユーザさえもその恩恵に預けることができます。
 また、registry を利用する場合であっても、例えば、メニュー項目を追加するプラグインでは MT4 と MT5 で registry のキー名が異なる場合、プログラム的に MT のバージョンを判別して処理を分岐する必要があります。

 3. config.yaml による記述では、stuff な(単純なくだらない)プラグイン一つのために複数のファイルが必要になります。つまり、プラグインの定義が書かれた config.yaml ファイルと、処理の実体が書かれた Perl のモジュールファイル(*.pm)です。Perl スクリプトによる形式であれば、一つのファイル内にプラグインの登録処理(MT->add_plugin)と処理の実体(sub hogehoge {...})を合わせて書くことができます。
 config.yaml 内でもブロックスタイルを用いて処理の実体(Perl スクリプト)を書くことができますが、1) Perl による Syntax Check を行えない、2) エディタの Syntax Hilight 機能に預かれない、3) 一つのファイル中に YAML、Perl という言語仕様が混在することのメンテナンス性の低下、などの問題があります。

 4. config.yaml によるプラグイン定義において、その YAML 内に Syntax Error があった場合、そのエラーが判りづらいというのがあります。インデントするつもりで Tab を打ったらホワイトスペース 4 つじゃなくて \t が入っていて構文エラーですとか、ホワイトスペースが一つ足りずに構文エラーですとか → 参考:MT plugin の config.yaml には注意

 ...という理由です。YAML はスタートダッシュが秀逸で、サクサクッとプラグインを作るのには適していると思います。ただ、長期に渡って複数の開発者で改善改修を行い続ける必要があったり、プラグインがどんどん肥大化、高機能化していくケースを考えると、最初が多少面倒な Perl スクリプトであっても、結果的には保守性や可読性を維持できる方がメリットがあると感じています。

 次回は、複数のプラグインがどのような順番でシステムに読み込まれるのかを解説したいと思います(続くのかよ)