Movable Type3.3と4.0の両方に対応したTransformerプラグインの書き方。

各所で話題の? Transformerプラグインが4.0で動作しない! 件 (あんまり話題になってないのか?) ですが, 両対応するプラグインをひとつ書いてみました。プラグインの書き方や改造のヒントになれば。

関連エントリー

• MT4.0, CMSの変化とTransformerプラグイン。
• Movable Typeのプレビュー機能を改良するStylePreviewプラグイン(改良)。
• Movable Typeのプレビュー機能を改良するStylePreviewプラグイン。

Transformerプラグイン開発関連ページ

• Six Apart - 技術情報提供ブログ: Transformerプラグインの開発
• Movable Typeで行こう！: Transformerプラグインの作り方
• [KOF2006] MTプラグインサンプル及びドキュメント公開します。(Junnama Online (Mirror))

今回改造したプラグインはエントリーの編集画面のプレビューにテンプレートタグやCSSを反映させるStylePreviewプラグイン。

プラグインのダウンロード

• StylePreview.pl.zip(4KB)

え? そもそも4.0でデフォルトでちゃんとプレビューできるって?

そうかい, そんなこと言うなら, じゃぁ、書かねぇよ!というのは冗談で。

4.0ではエントリー編集画面で「Preview」ボタンをクリックすると, 表示された画面にiframeが入っていてフレーソ内に再構築された一時ファイル(716e33a47fa625eea57c6c428664685d923cf5ca.html みたいな名前で生成される)が入るようになっています。画面を遷移するとちゃんと一時ファイルは消えますが、プレビュー画面でブラウザウィンドウを閉じると一時ファイル(つまりゴミ、というか意図しない途中段階のファイル)が残ってしまうので注意が必要です。もちろんベータバージョンなのでリリースまでに改良される可能性はあります。

このプラグインは「一時ファイルを生成せずに」CSSやテンプレートタグが適用された状態でのプレビュー画面を表示させるものです。いずれにしても4.0になったら需要は殆どないと思いますが、今回はTransformerプラグインを両バージョンに対応させる例ということで。

MT4.0でのTransformerプラグイン

やっと本題。

以前にも書きましたが、MT4.0ではTransformerプラグインのためのコールバック名称が変わっています。

AppTemplateSource => template_source (テンプレートのソースに対する処理)
AppTemplateParam => template_param (テンプレートに渡されるパラメタに対する処理)
AppTemplateOutput => template_output (テンプレートエンジンの出力結果に対する処理)

lib/MT/Compat/v3.pm に以下の記述があるように、「大切でない(コールバックのエイリアス)マッピング(何故ならv3のレガシーなコールバック達はおそらくうまく動かないだろうから」ということのようです。コメントアウトで「一応」書いてはあるので最終リリース時にどうなるかはわかりませんが。

    # Unnecessary to map since all the v3 legacy callbacks would fail
    # anyway.
    # $MT::CallbackAlias{'AppTemplateSource'}   = 'template_source';
    # $MT::CallbackAlias{'AppTemplateParam'}    = 'template_param';
    # $MT::CallbackAlias{'AppTemplateOutput'}   = 'template_output';

まずはバージョンを取得して変数に入れておきます (プラグインの先頭付近に書くと分かりやすいかと思います) 。

my $mt_version;
my $v = MT->version_id; 
#->4.0 Beta 1 
if ($v =~ /^4/) { 
	$mt_version = 40;
} elsif ($v =~ /^3¥.3/) {
	$mt_version = 33;
} else {
	$mt_version = 32;
}

TransformerプラグインはMT3.3からの機能ですから, 4系であれば「40」3.3系であれば「33」それ以外であればここでは仮に「32」とします。「32」の場合は BigPAPI が使えるので, できるだけ多くのバージョンに対応させるのであればこの3種類を分岐させて処理を書けば良いでしょう。

バージョンを取得したら, バージョン毎に MT->add_callback を分岐させます。

if ($mt_version == 40) {
	MT->add_callback('MT::App::CMS::template_output.preview_strip',9 ,$plugin, ¥&_StylePreview);
} elsif ($mt_version == 33) {
	MT->add_callback('MT::App::CMS::AppTemplateOutput.preview_entry',9 ,$plugin, ¥&_StylePreview);
	MT->add_callback('MT::App::CMS::AppTemplateSource.preview_entry',9 ,$plugin, ¥&_PreviewTmpl);
} elsif ($mt_version == 32) {
	# BigPAPI用のコールバックを書くのであればここに
}

あとはバージョン毎のテンプレートやメソッドの変更等に応じて適宜コードを分岐させます。

今回はさほど変更点は多くありませんでした。テンプレートの部分以外では一カ所のみ (4.0では $app->translate_templatized($template->output); としないとページを生成できませんでした)。

	if ($mt_version == 40) {
		$preview_tmpl = $app->translate_templatized($template->output);
	} else {
		$preview_tmpl = $template->text;
	}

個人的に思うことですが、Transformerプラグインの場合, テンプレートを正規表現等で置換していって管理画面をバリバリ・バキバキとカスタマイズしていく場合がこれまで多かったように思うのですが(自分もそうしていました)、このやり方にはインストールが簡単である(プラグイン本体を設置すればそれだけでOK)というメリットがある反面、今回のようなメジャーバージョンアップでCMSのテンプレートが大きく変わった時には何とも大変な修正を強いられることになります。

メンテナンス性のことを考えれば、今後はできるだけテンプレートのカスタマイズは「alt-tmpl」で行って(tmplフォルダ内のCMSのテンプレートをalt-tmpl以下にコピーしてそちらに手を入れるようにする), 動的な処理のみをプラグインにようにした方が良いと思います。

...って、書き終わったらベータ3が出てるやんけ!