富山市の観光活性化を目的とするNPO法人「富山観光創造会議」様のサイトを制作しました。

http://kankou-toyama.com/

ベースはMovableType5のオープンソース版で、新着情報のみ管理しています。
CMS構築のお仕事では最もシンプルなタイプです。

サイト自体を立ち上げたのは一年前ですが、デザインリリューアル・CMS埋め込みを機に実績に追加させていただきました。

このサイトの新着情報には、三種類のリンクがあります。

• 個別記事へのリンク
• PDF資料へのリンク（PDFアイコン付）
• 外部サイトへのリンク（別窓アイコン付）

一見するとカスタムフィールドやタグで分岐をさせているように見えますが、特にイレギュラーな細工はしていません。
「本文」と「追記」を以下のように使い分けることで、三種類のリンクを作れるようにしています。

1. 本文がなく、追記に記述がある
   →追記の内容をhref属性にした外部リンク
2. 記事にPDFがアップされていて、かつ本文の文字数が非常に少ない
   →PDFリンク
3. 上記二点に当てはまらない
   →個別記事へのリンク

団体のサイトは活動報告の配信だけでなく、運営上報告自体を記録／保管することも重要な目的になります。
観光創造会議様の場合は、ほとんどの書面がPDFで発行されています。

以前はHTMLの知識がある更新担当者様に「PDFをFTPクライアントでアップロード」→「HTML直書きでリンク追加」という作業をしてもらっていたのですが、MovableTypeOSを組み込んだことで更新頻度が増え、マークアップの間違いも出なくなりました。

単純に一覧／個別記事で構成されたサイトを作るだけでなく、利用する人の状況に合ったオーダーメイドのCMS構築を心がけたいと思います。

Twitterで記事を紹介して下さい（-人-）

コンテンツトップ

コンテンツ個別

MovableTypeで上の画像のような、コンテンツトップと個別ページでデザインが大きく変わるページを作る場合、「フォルダ／ウェブページ」ではなく「カテゴリー／エントリー」で構成するのが一般的です。

ウェブページにはコンテンツトップの役割をするアーカイブがないため、ウェブページ用テンプレートの中でコンテンツトップと個別ページを切り替えるための細工をしなければならないからです。
先頭に「@」を付けた「隠しタグ」を記事に付与したり、カスタムフィールドを使うのが定番です。

ですが、デザインが違うのがフォルダごとに１ページだけなら、もっとスマートな方法があります。

ウェブページはエントリーページと違い、フォルダ構成とファイル名をきちんと指定することが前提になっています。

その考えでいけば、コンテンツトップのファイル名は絶対に「index」になるはずです。

なので、以下のように現在のページのファイル名を変数で習得して
「ファイル名がindex／indexではない」を判定させれば、コンテンツトップのみ全くレイアウトが違うウェブページを出力できます。

<mt:Ignore>
### 下記条件でレイアウトが変わります
### ファイル名がindex＝インデックスページ
### ファイル名がindexではない＝通常ページ
</mt:Ignore>
<mt:SetVarBlock name="Page_Basename"><$mt:PageBasename$></mt:SetVarBlock>
<mt:If name="Page_Basename" eq="index">
<p>コンテンツトップページです</p>
<mt:Else>
<p>個別のウェブページです</p>
</mt:If>

これを応用すると、フォルダ内のローカルナビゲーションも
「コンテンツトップが必ずリストの先頭に来る」ように出力することが可能です。

<mt:SetVarBlock name="Folder_Label"><$mt:FolderLabel$></mt:SetVarBlock>
<ul>
<mt:Pages folder="$Folder_Label" sort_order="ascend" limit="99">
<mt:SetVarBlock name="Local_Basename"><$mt:PageBasename$></mt:SetVarBlock>
<mt:If name="Local_Basename" eq="index">
	<li><a href="<$mt:PagePermalink$>" class="navi-index"><$mt:PageTitle encode_html="1"$></a></li>
</mt:If>
</mt:Pages>

<mt:Pages folder="$Folder_Label" sort_order="ascend" limit="99">
<mt:SetVarBlock name="Local_Basename"><$mt:PageBasename$></mt:SetVarBlock>
<mt:Unless name="Local_Basename" eq="index">
	<li><a href="<$mt:PagePermalink$>"><$mt:PageTitle encode_html="1"$></a></li>
</mt:Unless>
</mt:Pages>
</ul>

classを付ければ、CSSでボタンの装飾を少し豪華に変えたりできます。

私自身は、MovableTypeは4も5も、「ウェブページの必要性が感じられない」というのが正直なところです。

「ファイル名」を出力するURLに反映させることは、エントリーアーカイブでも設定次第でできますし、ひとつのCMSシステムの中に操作感が同じなのに役割の全く違う投稿画面がある状況は混乱します。
さらに、MovableType5になってから「ウェブサイト」と「ブログ」の管理画面の構成が紛らわしくなり、今編集しているのがウェブページなのかエントリーなのかさえ迷ってしまうようになりました。
MovableTypeに慣れていないクライアントに操作を説明する時も難儀します。

なので、クライアントから特に要望がない限り、ウェブページはあまり積極的に使わないようにしています。
管理画面に関しては、今後のバージョンアップで改善してほしいものです…

サンプルページには以下の人物写真素材を使用しています。

写真素材　足成

• http://www.ashinari.com/2009/05/24-020839.php?category=34
• http://www.ashinari.com/2009/04/08-016458.php?category=33
• http://www.ashinari.com/2009/07/27-025413.php?category=34
• http://www.ashinari.com/2009/04/17-017188.php?category=33

Twitterで記事を紹介して下さい（-人-）

ダウンロードはこちら。
Movable Typeでエントリの表示オプションを全ユーザーで同一にする。 – Junnama Online

特に設定はありません。有効にしている間、MTの動作が以下のように変わります。

• システムまたはブログ管理者が「表示オプション」を変更したタイミングで、その内容が全ユーザーに反映される
• 管理者権限のないユーザーの投稿画面には、表示オプションが出なくなる
• プラグイン有効化前に各ユーザーが個別に表示オプションを変更していても、管理者が変更をした時点で強制的に上書きされる

1. MovableType4・5・Power CMS for MTで動作を確認しています。
2. 新規アカウントを追加したタイミングでも同期される機能があったようですが、動作しないようです。現状では「表示オプションを変更したとき」のみ行われます。

かなり実務向けのプラグインなので、機能をざっと書いてもピンと来ない人も多いかもしれません。
必要な場面や技術的な捕足は、追記以降をご覧くださいませ。

MovableTypeの表示オプションの仕様について

MT4以降では、投稿画面の入力項目の表示・並び順を細かく設定することができます。
カスタムフィールドを多用するCMS的な構築には必須の機能ですが、ひとつ面倒なところがあります。

新規で記事を書くときの大まかな「項目の表示」については、各ブログの「設定」→「投稿」で前もって指定できるのですが、
投稿画面右上の「表示オプション」で指定できる「項目の並び順」に関しては各ユーザー個別となります。

つまり、MovableTypeの管理者が
入力しやすいようにカスタムフィールドの項目を整頓していても

更新担当者のアカウントでログインすると、
初期状態に戻ってしまうのです。

ブログやアカウントの数がほとんどないのであれば大した問題ではないのですが、大規模案件などでブログ10個・アカウント10個となってくると、10×10で100回分の表示オプションの設定を行わなければならないのです。

ぶっちゃけやってられま(ry

そんなときに「EntryPrefsFixer」を使うことで、下位ユーザーの環境を管理者側で簡単に整えることができます。
後々アカウントが増えたときの表示オプションの変更回数も、ブログの数だけで済みます。

技術的な捕足

このプラグインは、@Nick_smallworldさんと私(@webbingstudio)のTwitterでの会話を、@junnamaさんが見て作成してくれたものです。

@Nick_smallworldさんに許可をいただいたので、ログを技術情報として追記します。
DBを直接編集することで対応したい人や、同様のプラグインを作ってみたい人は参考にしてください。

【緩募】MovableTypeで、Aさん（もしくはシステム管理者）がカスタムフィールドの並び替えをしたときに、他ユーザー（Bさん、Cさん）も強制的にAさんの並び順にさせる方法をご存じの方、いらっしゃいますでしょうか。 11:56 PM Apr 29th

@Nick_smallworld MTの項目並び替えの件、遅レスですが私も調べたことがあるので、情報流しておきますね。この先しばらく連投になりますが失礼。 10:22 AM Apr 30th

管理画面項目の表示／非表示、並び替えは「mt_permission」テーブルの[permission_entry_prefs]がブログID、ユーザーIDをキーに管理しているらしいです。 #movabletype 10:24 AM Apr 30th

.@Nick_smallworld すいません、これの一個前Replyにしませんでした。…なのでメインユーザーのpermission_entry_prefsを他ユーザーに複製すると並び順は同じになるのではないかと考えられます。 #movabletype 10:25 AM Apr 30th

.@Nick_smallworld このことをサーバー担当の方に伝えたところそれでうまくいったぽいのですが、残念ながら私自身はまだ検証できていません。 #movabletype 10:27 AM Apr 30th

.@Nick_smallworld にっくさんのように「強制的に」と考えている場合、編集のタイミングでプラグインを起動させる／cronか別途プログラム起動で、該当DBを修正させる／という手がある気がします。 #movabletype 10:29 AM Apr 30th

@Nick_smallworld カスタムフィールドの並び順に関して私の方でわかってるのはこのくらいですが、少しでも参考になれば。てゆか誰かプラグイン作ってくれないかなあ。 #movabletype 10:30 AM Apr 30th

@webbingstudio ありがとうございました！ばっちりできました。permissionのほうに定義されていたとは気がつかず「blog_かauthor_の方だろうなー、でも項目が無いなー」と思って探していましたｗ　6:01 PM Apr 30th

@Nick_smallworld あれでできましたかー。結局、項目の表示順は全ユーザーで統一することが多いですよね。今後の案件にも役立ちそうなので、私も試してみます！ 8:52 PM Apr 30th

あと名前出せないのですが、私の検証を元に実際にDBを書き換えて動作確認してくれた当時の某社サーバー担当者様、ありがとうございましたー＞＜。

Twitterで記事を紹介して下さい（-人-）

MovableTypeの初期テンプレートセットには、「最新記事のフィード」という、Atom1.0形式のフィード用テンプレートが含まれています。
サイトから配信するRSSフィードは普通は「新着記事」になるので、よほどこってりしたカスタマイズをしない限り、このテンプレートをそのまま使うことになります。

しかし、テストサーバーで記事を入れ込み→本番サーバーに移行という流れで構築をしている場合、このテンプレートの扱いにはちょっとした注意が必要です。

「最新記事のフィード」テンプレートの14行目に、以下のようなコードがあります。

<id><$mt:EntryAtomID$></id>

MTタグ「<$mt:EntryAtomID$>」はAtomフィード内で各エントリーに一意のIDを振るために用意されているものです。

これが、再構築すると以下のような文字列に変換されるのですが、

tag:[記事を書いた時のブログのドメイン名],[記事の公開年]:[ブログトップのサーバー内相対パス]/[ブログID].[記事ID]

[記事を書いた時のブログのドメイン名]と、[ブログトップのサーバー内相対パス]は、ドメインやサーバーを変更してもそのままデータベースに残ってしまいます。

つまり、もしも ｈttp://exmaple.testserver.com/test/ というURLにテストブログを作って記事の入れ込みをしていた場合、本番サーバーへ移行した後も、

tag:exmaple.testserver.com,2010:/test//1.999

という文字列がAtomフィードに残ることになります。

AtomIDは一意の値を振るためのものなので、存在しないドメイン名が残っていても問題はないようですし、わざわざソースコードを見ない限り、このIDが一般の閲覧者の目に触れることはありません。
ですが、自社サーバーで作業していた場合などは、やはりテストサーバーのドメインは知られたくないところです。

対策としては、データベースを直接書き換える手も考えられますが、<$mt:EntryAtomID$>自体を使用せず、他のMTタグを組み合わせて同じような書式を作ってしまう方法が手っ取り早いです。

<id>tag:<$mt:BlogHost$>,<$mt:EntryDate language="en" format="%Y"$>:<$mt:BlogRelativeURL$>/<$mt:BlogID$>.<$mt:EntryID$></id>

上記のようにタグを書くと、再構築をした段階のドメイン・サーバーの情報を元にIDが再発行されます。

Twitterで記事を紹介して下さい（-人-）

需要が高いと思いますが、MovableTypeは意外にも、2010年1月の時点でこの機能を追加できる有力なプラグインがないようです。
手作業でのカスタマイズ方法は下記ページで紹介されていますが、投稿画面編集・GoogleMapsの座標取得の知識が必要です。

Movable Typeの記事投稿画面にGoogle Mapsを表示｜Skyward Design

もうひとつの選択肢として、「Mapper」プラグインを使って、管理画面で入力した「住所」から地図を自動表示させる方法があります。
今回はさらにjQueryプラグイン「thickbox」を連携させ、モーダルポップアップで表示するカスタマイズを紹介します。

デモサイト

本記事のデモサイトはこちらです。（ベース：MovableType5）

Mapperプラグインデモ ＊ 道民部がたむろしている店

時間ないので店は数件しか登録してないですが…w

お店の個別ページで、「地図を表示する」リンクをクリックすると、住所を参照した地図がthickboxのポップアップで表示されます。
住所欄には正規版の機能であるカスタムフィールドを使っていますが、追記欄をうまく活用すればMTOSでも可能です。

注意点

住所から検索・変換をしているため、正確性にやや難があります。
（デモサイトの場合、串鳥の座標が東急の真上になってしまってます）
吹き出しの内容も詳細指定するなど、完璧さを重視する場合はGoogleの公式コードを直接書き込むなど、別の方法を検討してください。

プラグイン・ライブラリを用意する

まず、カスタマイズに必要な素材を用意します。

「Mapper」は、任意のMTタグ内に書かれた[map:住所]という「Mapタグ」を地図に変換するMovableTypeプラグインです。

http://code.google.com/p/ogawa/wiki/Mapper_Plugin

「thickbox」は、リンクに特定のclassを指定するだけで、画像やHTMLをモーダルポップアップさせるjQueryのプラグインです。

http://jquery.com/demo/thickbox/

jQuery本体も、まだ使ったことがない場合はこちらからダウンロードしてください。

http://jquery.com/

thickbox自体の設置方法はここでは割愛します。必要なファイルをサーバーにアップロードしておいてください。

GoogleMaps API Keyを入手する

Mapperを利用するには、API Keyを取得する必要があります。

下記ページで利用するサイトのURLを登録し、キーを取得してください。

http://code.google.com/intl/ja/apis/maps/signup.html

プラグインを有効化する

MovableType内にMapperをアップロードします。
管理画面内のMapperの設定画面に入ると、GoogleMaps API Keyを求められます。さっき入手したキーをコピペして保存してください。

住所のカスタムフィールドを作成する

住所欄のカスタムフィールドを作成します。
ここでは「CFaddress」としました。ここのベースネームを変更した場合や、追記を利用する場合は、以降のGoogleMapsを呼び出すテンプレートのMTタグを読み替えてください。

ブログ記事テンプレートを２つ作る

Mapperで生成される地図はJavaScriptを多用しています。このため、コンテンツ内のMETAタグの指定や、今回使うthickbox等のjQueryライブラリと衝突しやすいです。
それを防ぐために、地図だけインラインフレームで呼び出します。

MovableTypeは同じアーカイブで出力URLが違うページを複数作ることができるので、これを利用して「ブログ記事テンプレート」を２つ設定します。

画面のように設定すると、

ブログ記事

[ブログのURL]/[カテゴリー]/post-[エントリーID].html

Google Maps

[ブログのURL]/[カテゴリー]/map-[エントリーID].html

という、二種類のHTMLが記事ごとに生成されることになります。

コンテンツ用テンプレートの作成

「ブログ記事」という名前のテンプレートの方が、コンテンツ（地図を呼び出す本ページ）となります。
HTMLソースを書き、head内に以下のコードを追加してください。

<link rel="stylesheet" type="text/css" href="[ファイルへのパス]jquery.thickbox.css" media="All" />

<script type="text/javascript" src="[ファイルへのパス]jquery.js"></script>
<script type="text/javascript" src="[ファイルへのパス]jquery.thickbox.js"></script>

地図を表示するポップアップのリンクを表示したい個所に、以下のようにコードを書きます。
a要素内のURLの詳しい記述方式については、thickboxのページ内の「Inline Content」の項を参照してください。

<mt:If tag="CFaddress">
<a href="#TB_inline?width=600&height=480&inlineId=mapframe&modal=true" class="thickbox">&raquo;&nbsp;地図を表示する</a>
</mt:If>

さらにページの末尾、bodyの閉じタグの上あたりに、以下のコードを書きます。
フレームのwidthとheightは任意調整してください。

<mt:If tag="CFaddress">
<div id="mapframe" style="display: none;">
  <p class="map-title"><$mt:EntryTitle encode_html="1"$>の周辺地図</p>
  <iframe src="map-<$mt:EntryID$>.html" width="600" height="400" marginwidth="0" marginheight="0"></iframe>
  <p class="map-close"><input type="submit" value="×閉じる" onclick="tb_remove();" /></p>
<!-- /#mapframe --></div>
</mt:If>

重要なのは、インラインフレームの内部HTMLを指定している部分です。

map-<$mt:EntryID$>.html

上記のようにEntryIDタグを仕込むことで、２つ目のエントリーテンプレートを呼び出すことになります。

ポップアップ用テンプレートの作成

「Google Maps」という名前のテンプレートの方は、ポップアップ用です。以下のコードが全てになります。
地図のwidthとheightは任意調整してください。

<html>
<body style="margin: 0; padding: 0;">
<mt:If tag="CFaddress">
<mt:Mapper width="600" height="400" zoom="18">
  <p>[map:<$mt:CFaddress convert_breaks="0"$>]</p></mt:Mapper>
</mt:If>
</body>
</html>

Mapperで拡張されたMTタグを使い、カスタムフィールドの「住所」を表示します。
段落でマークアップさせないよう、「convert_breaks」モディファイアに「0」を指定しておいた方が安全です。

METAタグなどは敢えて指定しない方が、各ブラウザでちゃんと表示されるようです。

最後にテンプレートを再構築し、リンクをクリックするとポップアップが出るか確認してください。

Twitterで記事を紹介して下さい（-人-）

私の場合、制作会社から依頼を請けることが多いので、そこの担当者＝ディレクター、またはその会社の、MovableType／WordPressのスキルを持つ制作の方がコードを見ることがあります。

個人でテンプレートの構築をしていた頃は、変数や独自タグを駆使してけっこう複雑なコーディングもしていたのですが、チーム制作に関わるようになってからは
「自分以外のテンプレート制作者が見ても、理解しやすい構造になっているか」
を考慮するようになりました。

特に質問されることが多いのが、自分以外には見通しが利きにくい、以下の二つです。

• 何度も使い回す関係でモジュール化して、インクルードで読み込んでいる部分
• mt:SetVarやPHPの変数を使用している部分

特にMovableTypeの「mt:Include」には多彩な機能があり、下のようにモディファイアに変数の値を渡したり、

<$mt:Include module="Module_Hoge" foo="Var"$>

（↑読み込み先の「Module_Hoge」モジュールで変数名fooに値Varが渡されます）

「mt:IncludeBlock」という、変数の値を渡すことを前提としたタグもあります。

<mt:IncludeBlock module="Module_Hoge2">
Movable Typeへようこそ！
<mt:IncludeBlock>

（↑読み込み先の「Module_Hoge2」モジュールで変数名contentに値「Movable Typeへようこそ！」が渡されます）

ですが、私はこういった変数の渡し方はできるだけ避けています。

このような変数の渡し方をコード全体に渡ってやってしまうと、モジュール側の方のコードを見て
「あれ？ここで参照されてる、変数fooってなんだろう」
と思ったときに、読み込み元と思われるベーステンプレートを上から下まで探さなければいけなくなります。
繰り返しや条件分岐などの一時変数以外は、わかりにくい場所で変数を宣言するのは避けるべきです。

私の場合、サイト内で頻繁に利用されることがわかっている固定値は、
「mt:SetVars」「mt:SetVarBlock」などを使い、テンプレートの先頭でまとめて宣言してしまうようにしています。

全テンプレートに使用する変数はやはりモジュールとなりますが、少なくとも変数について訪ねられたら
「グローバルテンプレートの『Module_Config』を見てください」
とか
「テンプレートの文書宣言の次辺りに書いてあります」
と、簡単に変数を宣言している場所を答えることができます。

モジュールの呼び出し方に関しても、

と、外側のレイアウト用のdivが残るように、かつHTMLタグを分断しないように呼び出し、各テンプレートのHTML構造を見通せるよう気を付けています。

また、複雑な条件分岐などをしているところでは、mt:IgnoreやPHPコメントなどで説明を添えることも多くなりました。

<mt:Ignore>### ○○のときは△△を表示します ###</mt:Ignore>

これまでのTipsでもう出てきていますが、変数やモジュールの命名に関しても
「Global_」や「Module_」などの接頭語を統一して、それらが何に使われているのかが名前を見ればわかるようにしているのも、テンプレートをわかりやすくするための工夫のひとつです。

…と、何だか高度なことをやっているような書き方をしましたが、これらはシステムそのものを作り、かつ日常的にチーム制作をしているプログラマにとっては、基本中の基本だろうと思います。

「デザイナー」を名乗っていると、デザインをテンプレートで再現することに集中しがちになりますが、HTML/CSSコーディング同様、テンプレートの構築もプログラミングの一種です。
テンプレートコーディングに関しても、より早い構築・改修ができるよう、定期的にブラッシュアップをはかりたいものです。

Twitterで記事を紹介して下さい（-人-）

MovableTypeは、記事中に画像などの「アイテム」をアップロードして貼り付けると、アイテムに関する詳しい情報も記録されるようになります。
これは、ブログ全体であれば<mt:Assets>、エントリー中であれば<mt:EntryAssets>で呼び出すことができます。

WordPressにも近い機能があるのですが、

• アイテムにエントリーとは別個の「タグ」を付けられる
• テンプレート側でサムネイルのサイズを細かく指定できる
• アップした元ファイルと生成されたサムネイル・ポップアップが別ディレクトリで保管される

という点でMovableTypeは優れています。
（WordPressのように正方形にトリミングできないのが残念ですが）
写真・イラスト中心の個性的なサイトを作るのに力を発揮するでしょう。

追記：2009年9月25日
<$mt:AssetThumbnailURL$>にsquare="1"を加えると正方形にトリミングできます。はてブにコメントくれたaklaswadさんありがとうございます！

<mt:Assets>の強力な機能を使ったtipsをご紹介します。

タイプが「画像」のアイテムを表示する

まずは基本的な使い方です。

<mt:Assets>は、lastnモディファイアで出力される数、typeモディファイアで出力するアイテムの種類を固定できます。
typeをimageとしておくことで、もし動画やPDFが混じっていても確実にサムネイルを出すことができます。

また、サムネイルを出力する<$mt:AssetThumbnailURL$>にwidthとheightモディファイアを指定しておくと、サムネイルはその値を超えないサイズで生成されます。

特定のタグが付けられた画像をリンク・alt付きで表示する

<mt:Assets>にtagモディファイアを付けると、その値のタグが付いているアイテムのみリストアップします。対象はアップロードしたときに付けるアイテムのタグであって、エントリーのタグではありません。

記事中に何枚か貼ったアイテムのうち、タグを付けた画像のみを一覧にサムネイル表示することもできます。

<$mt:AssetProperty$>はpropertyモディファイアの値によって、説明文・ファイルサイズ・縦横サイズ等を取得できます。
アップロード時に入力した説明文を代替テキストにすると、よりアクセシビリティを考慮したHTMLソースを生成でき、jQueryのギャラリー生成ライブラリとの連動もしやすくなります。

<$mt:AssetProperty$>をうまく利用すると、MTOSでも正式版のカスタムフィールドのような拡張が可能なのです。

特定サイズ以下の画像はサムネイルを生成しない

サムネイルを生成する<$mt:AssetThumbnailURL$>には、欠点があります。
指定したwidth・heightモディファイアよりも小さな画像をアップすると、画像が逆に引き延ばされてしまいます。

もしも小さな画像もアップされる可能性がある場合は、<$mt:AssetProperty$>で取得した「画像の幅」「画像の高さ」を<mt:SetVarBlock>で変数に渡し、想定している最大サイズで二段構えの条件分岐を行う必要があります。

やや複雑にはなってしまいますが、上記のようにするとどんな画像をアップしても適切なサイズで表示されることになります。

PDFファイルだけHTMLを変える

CMS等でアップロードされるアイテムには、「PDF」や「Excelファイル」「圧縮ファイル」などもあります。
しかし、これらはMovableType内ではどちらも「type="file"」として判断されるので、最初のtipsではPDFだけを判別できません。

この場合は、アイテムの「拡張子」を取得する、<$mt:AssetFileExt$>を利用します。
PDFであれば値は必ず「pdf」になるはずなので、変数に渡して条件分岐を行うことで出力されるHTMLを変えたり、リンクにクラスを付けて、CSSでPDFアイコンを付ける演出を加えることもできます。

このように、ブログシステムに関わらずかなり高度な画像処理ができるMovableTypeですが、肝心のアップロード画面がお粗末です。
初期状態のまま特に意識せずにアップロードすると、サイトルート＝トップページがある場所に画像が保存されてしまいます。

サムネイルの保管先ディレクトリは環境変数で設定できるのですが、アップする画像そのものの保存先は上の画像のポップアップのHTMLを手入力かプラグインで書き換えるしかありません（いい方法があったら教えてください＞＜）。

また、画像関連の独自タグが入るとサムネイル生成処理が必要となるため、分岐が複雑になるとかなり更新処理が遅くなっていきます。

MovableTypeの画像処理機能は、オープンソース版でも使えるにも関わらずかなり便利なので、次バージョンの5で、ぜひこのあたりを改善してほしいものです。

Twitterで記事を紹介して下さい（-人-）

本サイトをリニューアルしました。

案件がたまっているのに何をやっているんだという感じですが、「4月からチクチク作っていて、サイト自体は今週の頭には完成していたのです！」「トップページにOSCとCSS Niteのバナーを貼ったのでイベントまでにアップしたかったのです！」
と言い訳します。

WEBデザイナーとしてお仕事をはじめてから、4回目のリニュになります。

2006年1月

2006年10月

2008年4月（いっこまえ）

…変なサイトばかりです。

なので、今回は当初、わりとまともなサイトを作ろうとしました。
でも、それはボツになりました。

勝ちを見据えたおとなしいサイトは、私のサイトではないです。

ブログカスタマイズやCMS構築が一般の人にも知られるようになって、
CMSを扱う技術者に、閲覧者が求めているものは
「静的サイトでは実現できない情報配信力」と
「ブログでは実現できないインパクト」だと思ってます。

だから今回はホワイトボードになぐり書き風にして、「WEBデザインのよさげポイント」すらぶち壊しました。

昔のブログを見てみると、私は4年前にも同じことを考えてます。

「柔よく剛を制す」。
これって、WEBにも当てはまるところがあると思うのです。

文書構造は大事です。SEOも考慮しなければお客は来てくれません。
トラックバックやRSSも、交流の幅を広げるのに重要な要素でしょう。その点でブログ形式が有利なことは確かです。

しかし、訪ねて来た閲覧者が見たホームページが無個性で、味も素っ気もないデザインだったら。
記事が全然無くて、それが丸コピー・ペーストしたような文章ばかりだったら。
アフィリエイトであれば、コメントもなくただ写真が貼ってあるだけだったら。
記事を読んだ後は、その閲覧者が二度と来ることはないでしょう。ウェブサイトは他にも何十億とあるのですから。

文章でも、デザインでも、イラストでもいい。何か閲覧者の心に残る「技あり」な部分があれば、もう一度見に来ようと思ってくれるかもしれないし、再びそのサイトを訪れたときに「あっ、ここ前に来たことがある！」と思い出してもらうこともあるでしょう。

閲覧者から華麗に一本を取れ : ウェビンブログ（旧）

一本を取ろうとする柔道は、なかなか勝てません。
お仕事では簡単にできません。

それでも、日々技を磨いて、いつかは華麗に一本を取りたいと思うのです。
自分のサイトはその練習場です。

というわけで、お仕事に戻ります。
しょうもないところで詰まってしまって、まだおわんないです。
自分のサイトを作っててお仕事の方がgdgdになりました、なんてことになったらシャレにならないですからね；；

Twitterで記事を紹介して下さい（-人-）

WordPress2.8とほぼ同時にMovableTypeも、バージョン4.26がリリースされました。

細かいバグフィクス以外には大きな変更はないのですが、私のような業務等で頻繁に新規インストールする人には重要な変更点があります。

Movable Type 4.26 を新規インストールで利用する場合

Movable Tyoe 4.26 を新規インストールで、使用するデータベースを MySQL にする場合、環境設定ファイル(mt-config.cgi)に環境変数 SQLSetNames を追加してください。

SQLSetNames 1

データベースの文字コードに「Latin 1」以外を指定して、ダイナミック・パブリッシングを使ったときに文字化けする問題の対策とのことです。

追加しなかった場合問題が起こるのは上記の点だけなのか、
追加しなかった場合インストールそのものが失敗してしまうのか、
その辺りが書かれていないので詳しいことはわからないのですが、mt-config.cgiの最終行に

SQLSetNames 1

の一行を加える、ということを頭に入れておいた方が良さそうです。

追記：
mt-config.cgiはインストール時に自動生成されます。
なので、インストールそのものに失敗するということは考えなくても良さそうです。
インストール後にmt-config.cgiをダウンロードして書き換える必要があるかどうかは、実際に新規インストール時に試してみないとわからないですが…

Twitterで記事を紹介して下さい（-人-）

上の画像は、MovableTypeをダウンロードするときに必要な、シックスアパートユーザーID（SAID）の登録フォームの一部なんですが。

「自分の知っている人の名前と住所を5人分入れておいて、後でランダムに出てきた配列から正しい組み合わせを選ぶ」という認証システムを採用してます。

※自分はこのシステム使ってないので、このリストの中に知人はいません

単語の羅列ではなくて、自分だけが知っていそうな長期記憶を利用する認証方法を「パスメモリー認証」といいます。

「あなたの卒業した小学校は？」「母親の旧姓は？」
というクイズ形式のはよく見ますが、こういうのはあまり見かけないなあ。
しかも、大抵はパスワードを忘れたときのメール送信用に使われますが、SAIDの場合はこれ単独でもログイン可能です。

自分的に気になるのが、
有名人や、会社の社長や、珍しい名前の人を登録してしまうと分かりやすすぎてザルなんじゃとか、
「全然付き合いのない同僚」を登録してその同僚が辞めちゃったりしたら覚え切れるかなあとか、
「誰を登録したのか」を忘れてしまったらとか、
電話帳などのデータからランダムで出るとしたら、激レアな私の苗字が出たりしないだろうなとかwww

それでも

単語の羅列で覚えられないから、メモ帳に書いてデスクトップに置いてます☆

というスイーツなことをされるよりはいいかもしれませんw

もともとSAIDは、MovableTypeの最新版をダウンロードしたり、サポートへメールをしたりするのに使う程度で、流出しても登録者の個人情報以外の損害は少ないものです。
軽い認証で充分なものは、パスメモリー方式を採用した方がユーザーの負担も減って、いいかもしれませんね。

Twitterで記事を紹介して下さい（-人-）