Blog

ブログ

MovableTypeカスタムフィールドの、filtersの動作について

Movable Type のカスタムフィールドで「テキスト(複数行)」という種類のフィールドを利用する際、テキストエリアへの入力内容に改行や空行を含めても、出力される文字列の改行や空行はすべて除去された状態で出力されてしまいます。

本エントリーでは、この事象を解消する方法を紹介します。
小粋空間:カスタムフィールドのテキストエリアに入力した改行をページに反映させる

mtformat

複数行のカスタムフィールドを、本文と同じように<p>と<br />でマークアップするには、「filters="default"」モディファイアを指定するのが良いとされています。

ですが、この方法では詳細に改行を制御できません。
旧来からあった「convert_breaks」モディファイアとどう違うのか、というのも気になりますが、シックスアパート社からも詳細な解説は出ていません。

MovableType4.2で、「改行を変換」「リッチテキスト」などの各フォーマットでのカスタムフィールドの挙動を、詳しく検証してみました。

結論から言うと、
「複数行カスタムフィールドの改行や空行は、再構築時に反映されない」
という解説は、MovableType4.2においては正解ではありません。

複数行カスタムフィールドにモディファイアを何も指定しなかった場合は、「各記事の本文・追記に指定したテキストフォーマット」が優先されるのです。

なので、IDが1の記事のフォーマットが「改行を変換」ならば本文と同じですが、IDが2の記事で「なし」や「リッチテキスト(WYSIWYGエディタ含む)」に変更すると、本文フォーマットが優先され、改行がなくなってしまいます。

MovableType4は後者のフォーマットで使っている人が多いために、上記のような定説ができたのか、バージョン4.0、4.1の挙動が違ったのかはちょっとわかりません。すいません。

mtformat2

なので、何らかのモディファイアでカスタムフィールドの書式を縛ることになるのですが、
一般に推薦される「filters="__default__"」は
完全に固定的なものではありません。

まれなケースですが、フォーマットを「markdown」にしたときのみ、<br />が書き出されず、意図した表示になりません。
また、

  • 「どんなフォーマットを使用しても改行を変換させない」
  • 「<p>はいらないが<br />は変換したい」

ということは、「filters="__default__"」ではできません。
(引数の__default__を別の値にする方法も考えられますが、MovableTypeのコアファイルを調べてもわかりませんでした)
この場合は、昔からあった「convert_breaks」を使用するのが確実なようです。

convert_breaksモディファイアは、本文でのテキストフォーマットを「常に無視」します。
また、「convert_breaks="0"」で、改行を変換させないようにできます。

<br />のみを変換する「nl2br」もconvert_breaksと同じ性質を持っているので、
ちょっと複雑になりますが、下記のようにすると<br />のみ有効になります。

<$mt:CF_HogeHoge convert_breaks="0" nl2br="1"$>

自分だけがブログをカスタマイズ・運用している場合や、カスタムフィールドが本文の一部であればフォーマットが変わっても良いのですが、
大抵のカスタムフィールドは特定のマークアップを行った箇所に出力したり、テーブルのセル内に出力したりと、イレギュラーな使われ方をします。
同じカスタムフィールドでも、出力先のテンプレートによって改行の個別制御が必要なこともあります。

「更新したときの気分」でフォーマットが変わってしまってはのちのち面倒ですし、CMSとしてMovableTypeの構築をする場合は、更新担当者のあらゆる設定変更を想定しなければなりません。

プログラミングにも通じることですが、的確なグローバル・モディファイアを指定することで、想定外の不具合をできるだけ予防しておきたいものです。