こんにちは、最近積みゲーを崩す努力も怠りがちなのについ懐かしさにかられて旧作リメイクを買っちゃう系エンジニアのせんせーです。
なお夢を見る島はちゃんとクリアしました。

さて、Movable Type 7（以下「MT7」）がリリースされたときにさっそく試してみたという記事を書いたのですが、そこから1年ちょっと経ちました。
実際の制作案件もぼちぼちこなしてきたので、覚書でも残しておこうと思います。

MT7というか、コンテンツタイプ使おうとして困ったことですね。意外と後方互換はとられているので、アップグレードで困ったことは（そんなに）ないです。
どちらかというと記事やウェブページならできるのにコンテンツタイプだとNGということが結構あって注意が必要です。

まあこれほぼ社内向けの記事なんですが、同じような悩みをお持ちの方も多いんじゃないでしょうか。
もし解決方法などご存知でしたらこっそり教えていただきたい……。

カテゴリセットに追加情報を持たせられない。

カテゴリごとのアイキャッチ画像や英語表記やクラス名やアイコンやなんかをカテゴリごとに設定しておきたいというのはよくあると思うんですが、カテゴリ名とベースネームくらいしか設定できる情報はありません。
あとからカスタムフィールド追加したりできないので注意。

どうしてもやりたかったらカテゴリのメタデータを管理するコンテンツタイプを別途作って…とかできなくもないです。

コンテンツタイプの複製ができない。

プレスリリースとイベント情報ってコンテンツタイプ作るんだけど半分くらいのコンテンツフィールドは共通なんだよねという時も1から作り直しです。
フィールド山盛りなコンテンツタイプを複数作らなきゃいけないときは注意。

コンテンツタイプアーカイブテンプレートの複製ができない。

正確にはできるんですが、複製すると元のコンテンツタイプがセットされた状態になっているので、別のコンテンツタイプをセットすることができません。

ニュース用のテンプレートを元にイベント用のテンプレートを作ったりとかできないということですね。

コンテンツデータの一括操作ができない。

できるのは公開の取消のみです。
お客さまにメインカテゴリの変更くらいはできますよとか言っちゃわないように！

複数のコンテンツタイプからのデータ取得がしにくい。

MTContentsタグはcontent_typeを指定しなければサイト内のコンテンツデータ全部ひっぱってこれるんですが、5つあるコンテンツタイプのうち2つだけ使いたいパターン、あると思います。

これデータ全件とってきて配列にいれたのをMTLoopで頭5件だけ出力するような実装しかできないんでしょうか。すごくモヤモヤする！
本当はMTMultiBlogでいうところのmode="context"みたいな指定したいんですけどダメですかね。

あるコンテンツフィールドが存在するか否かが判別できない。

カスタムフィールドの値を出力する時、だいたい<mt:if tag="entryhogehoge">...</mt:if>で囲んでエラー回避すると思うんですが、これができない。めちゃ困る。

具体的にはプレスリリースとイベント情報のアーカイブテンプレート作るときに、html的にはだいたい似たようなページだから中身はモジュール化して使いまわしたりすると、プレスリリースの方にはイベントスケジュールなんていうフィールドないから再構築できないって怒られます。

「このコンテンツタイプ名がイベント情報の場合」みたいな分岐を書くしかなさそうですが、ほかに何かいい方法はないものでしょうか。
なお「コンテンツフィールドの値が空かどうか」だったら、<mt:ContentsField>....<mt:else>...</mt:ContentsField>で判定できます。

同じコンテンツタイプを参照するフィールドが作れない。

ニュースというコンテンツタイプで、「関連するニュース」を選択するフィールドを作ったりできないということです。
あるいは商品というコンテンツタイプで「こんな商品もおすすめ」を選択できないと言ってもいい。

ニュースで「関連する商品」を選択することはできます。

MTAppjQueryでできることが結構違う。

MTプラグインのド定番ですが、かなり早い段階でMT7対応してくれてこれでもう一安心かと思いきや、いろいろトラップがあります。

記事・ウェブページとコンテンツタイプでそれぞれ使えるメソッドが違って焦るので、設計の前にちゃんとMTAppjQueryのドキュメントも読んでおきましょう。

コンテンツタイプを利用することで、このプラグインによるカスタマイズが不要になった部分ももちろんあるのですが、やっぱりなんだかんだ使うので…このメソッドはコンテンツタイプでは使えませんってなると泣きが入ります。

たとえば記事の並び順をドラッグで変更できるMTAppSortableBatchEdit()はコンテンツデータの一覧では使えません。
危うくお客さまに提案するところでした。

複数行テキストのコンテンツフィールドは、リッチテキストで画像の挿入ができない。

これかなりヤバいと思うんですが、特に不満は出てないんでしょうか？
ツールバーがインラインになったの、本当に解せないんですよ。いやブロックエディタの操作性がもうちょいよければよかったって話ではあるんですが。
いわゆる本文欄は、お客さんがWYSIWYGで書くよっていう場合はMTAppjQueryのオーバーレイエディタを使ったりしています。

まとめ

これらの問題はむやみにコンテンツタイプを分けないだとか、設計レベルで解決できることもあります。
でもコンテンツの分類って入力内容の類似性とか、出力されるhtmlが似てるからとかだけで分けるわけじゃないじゃないですし。
せっかく「コンテンツの設計をシステムに合わせなくていいCMS」になったのだから、もっと自由に設計させて欲しいんですが、いかがなものでしょうか。

コンテンツタイプの登場によりすべての記事とウェブページが過去のものになるかと思われましたがそんなことはなかったし、やっぱり子サイトも作っちゃいます。

特にウェブページはやっぱり使いますね。お客さんが頻繁に触るわけじゃないページは基本全部ウェブページに突っ込めばOKで、フィールドも従来のタイトル・本文・フォルダ設定（＋CSSを追加したりするカスタムフィールド）で十分対応可能です。
ニュースなどの更新系コンテンツについては要件次第で記事を使ったりコンテンツタイプを使ったり。この辺は画面設計の段階で結構ちゃんと考えておかないと後悔するので、開発の人もあまりディレクター任せにはしないほうがいいですね。

色々書きましたが基本的にMT6から7への変化は基本的に歓迎すべきものではあって、コンテンツタイプは積極的に活用していくべきだと思います。
ただ実際作り込みしてるとやっぱりMTAppjQueryがないと生きていけないので、入力系はもうちょっと頑張ってもいいのではないかなあと思う次第です。
あとMT.netがアップデートすごく頑張ってるので、こっちにコンテンツタイプが導入されたときにどうなるのか、非常に期待しています。