タグ: Movable Type

  • とりあえず、サイトの移転を実施。
    今回の移転において、変更があったのは主に以下の2点。

    サーバを入れ替えたのは、以前使っていたCoreserverのs16サーバがずーっと負荷率が高いままで、Coreserver側のサポートに全く期待できなくなったため。負荷率が高いとMovable Typeの再構築も頻繁に失敗するようになり、使い勝手が著しく低下する。そりゃあ更新頻度もどんどん落ちていくわ。

    ツールを入れ替えたのは、上記と関連して、Movable Typeの再構築の遅さが相当ネックになってしまったから。現在、記事は全部で1800以上あるのだけれど、これだけあると何か一つアクションを起こす度にやたらと時間がかかるようになる。更新するのが苦痛なレベル。
    また、Movable Typeは一般ユーザーがどんどん離れてしまっているため、プラグインのコミュニティがあまり活発では無い。そのため、あまり多くの機能追加が望めないという難点も抱えていた。

    そんなわけで、今回ついに移転と相成った。
    サイト丸ごと入れ替える大工事だけど、外見上の変化は最小限に抑えた。そこに特に意味は無いけど、単なる自己満足の世界です。ただし、今回はIE6をガン無視で作ったので、その辺は知ったこっちゃないです。

    いくつか移動できてないページもあるけれど、そこはまぁ、追々やっていく方向で。

  • 現在サイト移転作業中で、今日か明日中に移転作業を終わらせる予定。
    …とは言っても、URLが変わるわけでも、外見上の変化があるわけでもないです。ただ、ほんのサーバが変わって管理ツールがMovable TypeからWordPressに変わるだけです。
    まぁ正直な話、相当な大工事なんだけど、表面上は何事も無いかのように振る舞うための下準備に時間がかかってしまった…。

    とりあえず、これからサーバの設定とドメインの設定をして、移転作業にかかります。
    さようならMovable Type、さようならCoreserver。

  • 最近、Movable Type 5にアップグレードした時に、動的生成ページが表示されなくなり、以下のようなメッセージが表示されるようになった…という不具合を、1ヶ月近く放っておいた。

    #0 /virtual/xxxx/public_html/melog.info/mt/php/extlib/adodb5/adodb-active-record.inc.php(494): adodb_throw('pdo', 'ADODB_Active_Re...', -1, 'No primary key ...', 0, 0, Object(ADODB_pdo))
    #1 /virtual/xxxx/public_html/melog.info/mt/php/extlib/adodb5/adodb-active-record.inc.php(402): ADODB_Active_Record->Error('No primary key ...', 'UpdateActiveTab...')
    #2 /virtual/xxxx/public_html/melog.info/mt/php/extlib/adodb5/adodb-active-record.inc.php(136): ADODB_Active_Record->UpdateActiveTable(false)
    #3 /virtual/xxxx/public_html/melog.info/mt/php/extlib/adodb5/adodb-active-record.inc.php(198): ADODB_Active_Record->__construct('mt_blog_meta')
    #4 /virtual/xxxx/public_html/melog.info/mt/php/extlib/adodb5/adodb-active-record.inc.php(228): ADODB_Active_Record->hasMany('mt_blog_meta', 'blog_meta_blog_...', 'ADODB_Active_Re...')
    #5 /virtual/xxxx/public_html/melog.info/mt/php/lib/class.mt_blog.php(134): ADODB_Active_Record::ClassHasMany('Blog', 'mt_blog_meta', 'blog_meta_blog_...')
    #6 /virtual/xxxx/public_html/melog.info/mt/php/lib/class.baseobject.php(308): require_once('/virtual/xxxx/p...')
    #7 /virtual/xxxx/public_html/melog.info/mt/php/lib/mtdb.base.php(258): BaseObject->blog()
    #8 /virtual/xxxx/public_html/melog.info/mt/php/mt.php(645): MTDatabase->resolve_url('/archives/2006/...', 2)
    #9 /virtual/xxxx/public_html/melog.info/mt/php/mt.php(488): MT->resolve_url('/archives/2006/...')
    #10 /virtual/xxxx/public_html/melog.info/mtview.php(7): MT->view()
    #11 {main}

    正直、何のことかさっぱりわからん!色々試してはみたのだけれど、そもそもこのMovable Typeというツールが静的ページを前提としているためか、ダイナミックページを使おうと思っても設定がイマイチ分かりにくく、最初の設定時にこういったエラーがよく発生していたように思う。
    こういうとき、ユーザー数の少ないツールを使ってると不便だなぁ。情報がちっとも出てこない。

    そんなわけで、対策としてはダイナミックページの生成やめることにした。…そもそもダイナミックページの使用したのは、再構築に時間がかかりすぎるという難点があったためだったので、これをやめるのもちょっと抵抗があるのだけれど、背に腹は替えられない。

    今のサーバは最近動作が重いし、Movable Typeも情報が集まりにくくなってきたため、サイトの運用自体に少々問題が出てくるようになってしまった。
    サイト自体を止める気はないのだけど、サイトの移転とか色々考えたりする今日この頃。別にドメイン自体はmelog.infoから変わるわけではないので、こちら側の運用の問題です。

  • Movable Type用OAuth対応Twitter投稿プラグイン PostTwiOAuth 0.40 クライアント機能搭載 – BSDあれこれ

    Movable Typeの投稿をTwitterに通知するプラグイン「PostTwiOAuth」導入してみた。
    設定がゴチャゴチャしてて分かりにくかったのだけど、多分これでいい…はず。
    導入手順は以下参照。厄介なのは、Twitterとは別にbit.lyの登録を行わなくてはいけないこと。
    何かアカウントがあれこれ増えて厄介だなぁ。

    小粋空間: Movable Type用OAuth対応Twitter投稿プラグイン「PostTwiOauth」

  • 本サイトのMovable Typeのバージョンを4から5.03にアップグレードしました。

    物凄い久々にアップグレードして気付いたのだけど、世間のほとんどはWordPressに移行しているのね。以下、Googleトレンドの結果。

    20100924_mt-vs-wp.png

    まぁそれはさておき、アップグレードは公式のマニュアルを参照しながら実施。
    Movable Typeのバージョンを上げたら管理画面ががらっと変わっててビックリしたけど、機能的に特に大きく変わったわけではない。
    とりあえず、使ってみて気付いたことがあれば適宜修正していく方向で。

  • このサイトは長い事CMSツールとして、Movable Typeを利用している。長い事使っているので、それなりに記事数も蓄積されている。しかし最近、それに伴ってサイトの構築にやたらと時間がかかるという問題を抱えるようになってしまった。

    Movable Typeは記事を書くと静的なページ(要するにhtmlファイル)を生成する。これは、閲覧者がサイトにアクセスした際にHTMLのダウンロード以外の負荷がかからない一方、リンク等の整合性を保つために多数のページを更新するため、記事を書いた際の負荷が高い(ただし1度だけ)。ただ、複数ユーザーでの利用やコメント、トラックバックを頻繁に受信するなど、更新が頻繁になると負荷がそれなりに高くなる。
    逆に、閲覧者がサイトにアクセスする度に随時ページを生成する方式を動的生成と言う。こちらは記事を書く際の負荷は低いがアクセス数が多いと負荷が高くなるので、サーバに対してあまり優しくないという側面を持つ。

    MovableTypeの静的生成は記事数が多くなると、1つ記事を書くだけで結構な時間がかかるようになる。記事数が増えるに従って徐々に時間が長くなり、最近はこれが結構なストレスになるようになってきた。
    最近は、動的生成型のWordPressを利用する人が多いようなので、こちらに乗り換える事も検討してみたけど、今さら乗換えるのも移行作業に時間がかかって大変だし、できればもう少し様子を見たい。
    そこで、Movable Typeで「一部」を動的生成する方法を取った。Movable Typeでは多くの使い方として静的生成を行うけど、動的生成を行う事も可能。
    ここで「一部」というのは、見出しとなるインデックスページの事。個別の記事とトップページを除いた多くのページが該当する。要するに、記事を書く際、整合性のために大量に更新されるこれらのインデックスページの静的生成をやめる事にした。

    すると、記事を書いた際に反映されるまでの時間が驚くほど減少。以前は一つ記事を書く度に更新に30秒~1分ぐらい待たされたのに、10秒ぐらいになった。正直、これほどの差が出てくるとは思わなかった。
    そんなわけで、月別ページやカテゴリページ等のインデックス用のページは開くのに時間がかかるようになってしまったけれど、記事の更新がやりやすくなったのでとりあえず満足。WordPressの利用の検討はまた今度。
    ちなみに、動的生成にしたページのアドレスは見かけ上「.html」になっているけれど、これは.htaccessでアドレスを置き換えただけのなんちゃってHTML(何それ)なので、動的生成はされている。

    とりあえず、まだ置き換えたばかりでページのエラーが出る箇所もあるかもしれないけれど、とりあえず徐々に直していく方向で。

    追記

    的生成(ダイナミック・パブリッシング)に変更した際、するといくつかのページで「ページが見つかりません」というエラーメッセージを吐くようになってしまった。調べてみると、以下のような事象を発見。

    小粋空間: Movable Type 4.261 でのダイナミックパブリッシングエラーについて
    うろうろ…

    何だ、ただのバグか…。とりあえず手作業でソースを修正して事なきを得る。

  • Webサイトを運営する上で厄介な事といえば、コメントスパムトラックバックスパム

    このサイトで現在使用しているツールはMovable Typeだけど、このツールは利用者が多いだけあってスパム対策も色々考えられていたりする。そんなわけで、このサイトで現在利用しているMovable Typeのスパム対策について。

    コメントスパム対策

    現状のMovable Typeのコメントスパムフィルタはそれなりに優秀なので、ある程度のスパムは弾いてくれる。ただ、普通のコメントでもリンクが多数含まれているとスパムと判定されてしまう、コメントスパムリストに多量のスパムコメントが蓄積される、スパム処理によってサーバのCPUリソースが費やされる、といった問題がある。

    Movable Typeのバージョン4から標準採用された画像CAPTCHAを利用することで、コメントスパム を相当抑えることが可能(参考:コメントに CAPTCHA 認証を利用する | Movable Type 4 ドキュメント)。少なくとも本サイトでは、採用以降のコメントスパムは完全に途絶えた。まー、サイトの規模にもよりけりだと思うので、どのサイトでも完全にシャットダウンできるかどうかは分からない。
    CAPTCHAにはMovable Type既定の物以外に、reCAPTCHAという別のプロバイダが提供するプラグインも存在する。作ろうと思えば音声や問題形式のCAPTCHAプラグインも可能と思うが、存在は確認できていない。

    デメリットは以下の通り。

    • 現状では基本的には画像によるCAPTCHAとなるため、画像が読み取れない(表示しない)ユーザーに対しての配慮が無い。
    • ユーザーに対し、強制的に文字入力というワンアクションを強制する事になる。
    • CAPTCHAのテンプレートタグが柔軟性に欠け、出力されるHTMLがInvalidな物になる可能性や、柔軟性に乏しい構造を吐く可能性がある。っていうか既定のHTMLタグは何とかしてくれ。
    • CAPTCHA技術は既に対抗手段が現れており、完全ではない(ただしマイナーな個人サイトに対してそこまで執拗なスパムが無いと思われるので、対策としては有効)。

    CAPTHAを使用する以外の対策としては以下のような物が考えられる。なお、デフォルトのテンプレートタグを変更して機械的な読み取りを阻害するのはほとんど効果が無い。

    • 環境変数のThrottleSecondsを変更する(緩和させる)。
    • 設定でスパム判定の基準を厳しくする。
    • 登録ユーザーのみコメントを受け付ける。
    • そもそもコメントを受け付けない。

    トラックバックスパム対策

    コメント同様、現状のMovable Typeのトラックバックスパムフィルタはそれなりに優秀なので、大体はスパムとして判定してくれる。しかし、トラックバックスパムリストに多量のスパムコメントが蓄積されることによって許容可能なトラックバック上限を簡単に突破してしまう、スパム処理によってサーバのCPUリソースが費やされる、といった問題がある。

    スパム対策として、トラックバックSPAM防止プラグインを利用する。使ってないけど、Movable Type で言及リンクのない TrackBack ping を弾くプラグインでもいいと思う。要するに、トラックバック元にトラックバック先へのリンクが含まれていなければスパムと判断して弾く、というプラグインを導入する。本サイトでは導入以後、トラックバックスパムを完全にシャットダウンする事ができた。
    デメリットは以下の通り。

    • 少なくともトラックバック元記事の本文にトラックバック先へのリンクが無いと受け付けないため、トラックバック用途を強制的に限定させてしまう。
    • 処理負荷が増加する。

    プラグインを使用する以外の対策としては以下のような物が考えられる。

    • 環境変数のThrottleSecondsを変更する(緩和させる)。
    • テンプレートのMTEntryTrackbackDataタグを削除する。
    • 設定でスパム判定の基準を厳しくする。
    • そもそもトラックバックを受け付けない。

    ちなみに、環境変数のOneHourMaxPingsOneDayMaxPingsを変更することで、一時間 or 一日で受け付けられるトラックバック量を制限できるが、これはスパムを受けても場合もカウントされるため、この上限をあっという間に突破してしまい、「HTTP error: 403 Throttled」というエラーを吐いて本来のトラックバックを受け付けられなくなる可能性がある。プラグイン導入後はそもそもスパムを受け付けなくなるので、無意味に上限を超えることは無くなる。

    ちなみに「トラックバックSPAM防止プラグイン」を使用する場合、スパムを受け取った際にログにメッセージを吐き出すが、本サイトではこれが一日に数百件とか出てきて非常に鬱陶しかったので、ログを吐き出さないように以下の行の先頭に「#」を加えてコメントアウトする変更を加えている。ログなんてそもそも確認しないので、出力されてもあんまり意味は無いしね。

    41 :     $app->log($app->translate($message) . qq/(U:$url,B:$blog_name,T:$title,E:$excerpt)./);
    

    まとめ

    そんなこんなで、Movable Typeのスパム対策のまとめを書き連ねてみた。
    ネットが普及するに従ってスパムは日々増加し、その手段も徐々に巧妙になっているけど、完全とは言わないまでも対策案が色々考え出されていたりする。ここで紹介した物が将来に渡って有効かどうかは怪しいけど、とりあえず現状では有効な手段であると、本サイトの実績から述べる事ができる。

  • Melog: Works > Junk > Movable Type テンプレート

    本サイトで使用しているMovable Typeテンプレートを公開します。2008年2月3日現在におけるテンプレートとなります。

    …まぁこんな物を公開したところで、自分以外の誰にも使えない代物なんだけど。標準のテンプレート要素は完全に残っておらず、完全にこのサイトに特化して作られているので、かなり手を加えないと利用は無理。要するに参考資料程度の役割にしかならない。

    この前リリースされたMovable Type 4.10にバージョンアップした際、追加されたタグによってテンプレートが大部整理され、他人に見せてもそれほど問題ない形まで持って行けたような気がするので、せっかくだし公開しておくか、と。ついこの前までは見せるのがはばかられるぐらい酷かったから…。

    しかし、最終的な出力の改行を整えるために改行の挿入箇所がやたら不自然になっているので、現状でも汚いといえば汚い。まー、これは仕組みを考えるとしょうがないんだけどね。

  • ここ数日で以下の変更を行った。

    • Movable Typeを 4.1 にバージョンアップ
    • それに伴い、Movable Typeのテンプレート修正。主にMTSetVarsタグを使用したテンプレートのモジュール化。
    • 一部にアイコン追加。

    Movable Typeのバージョン4.1がリリースされたので導入。この4.1のバージョンアップではいくつかタグが追加されていて、その中に「MTSetVars」がある。これは変数を設定するタグ。従来のMTSetVarMTSetVarBlockと異なるのは、こちらはブロック内で変数を一括指定できること。なお、複数行に渡る値はやはり従来通りMTSetVarBlockを使う必要があるようだ。これはMTSetVarsブロック内でも宣言できる。

    Moavble Typeで変数を使う主な目的は、同じ情報群のテキストを一纏めで管理できることや、テンプレート別に変数を設定することで、インクルードされたモジュールの挙動を呼び出し元別に変更できること等が挙げられる。
    また、従来あった「MTSetVarをページの先頭で宣言すると、改行が挿入されてしまう問題」もこれによって解決できる。(参考:ページ先頭の改行を削除する – The blog of H.Fujimotoページの先頭に改行が入る問題(MTRemoveBlank) – MovableTypeのススメ
    今回は、そのテンプレート別にヘッダ情報を変更するといった形で、テンプレート内容を簡略化したことが主な変更となるので、外観上はほとんど変わってない。

    そのテンプレート修正ついでに、サイトにアイコンを追加した。転送量が増えることや、外部ファイルが多くなってファイルの煩雑になるといった理由でサイトのデザインに画像を使ってこなかったけど、最近何となく気が変わった。
    そもそもそんな真剣に考えるほど転送量が増えるわけでもないし、ユーザビリティの観点から考えると、視認しやすいアイコンの存在はそれなりに必要とされるのではないかと。

    ただし、恐らくユーザの割合が最も多いであろうInternet Explorerではこのアイコンは見えない。何故ならば、CSSの「content」プロパティによってアイコンが追加されているから。これは現状、IEでは未サポート。CSS2への完全対応が予定されているIE8になって、初めて見えるようになる…はず。

    CSS 2に対応したForefox、Opera、及びそれぞれでは以下のように見える。

    Firefox
    Firefox
    Opera
    Opera
    Safari
    Safari

    img要素ではなく、CSSのcontentプロパティで行ったのは、この場合はあくまでもアイコンとテキストは別々の要素ではなく、全体で一つの要素を形成しているため。主体はリンクであり、アイコン画像はテキストを修飾する付属物であると考えられるため、アイコンをリンクのスタイルとしてCSSで指定する事は、理にかなっていると言える。
    …などともっともらしい理由をつけたけど、正直なところは、一々imgタグ挟むのがめんどいから。とはいえ、前に挙げた理由も正しい理由であることに変わりはない。

    ちなみに、今回使ったアイコンは以下のサイトにあるアイコン。結構有名なサイトのようで。

    DHTML Site – Free 16×16 Icons

  • ここ数日、Vistaいじりと平行してこのサイトのファイル管理方法を変更していた。その作業内容について。

    以前までは、アーカイブページ(エントリー等)で使用されるアップロード画像については、パスを「/archives/images/」としてその下に全部放り込み、画像以外のファイルは「/archives/files/」以下に放り込むという感じで管理してた。ちなみに、ファイル名は必ず「[年4桁][月2桁][日2桁]_任意の名前.xxx」という規則に基づいて管理している。
    しかしながら、このサイトを開始した2004年からの画像全部合わせると結構な数になる上、画像以外のファイルがさっぱり増えないという非常に偏ったファイル管理になってしまっていたので、大きく見直すことにした。

    以後は、アップロードファイルを「/archives/items/<年4桁>/」として全種別のファイルを年ごとに区切って全部放り込む事にした。現在、ファイルのアップロードに「Better File Uploader」というMovable Typeのプラグイン(有料)を使用しているけど、これを使うと、アップロード先のディレクトリ指定に自動的に年を付加する事が可能。
    月単位の管理にしなかったのは、1ヶ月の間にほとんどアップロードが行われない月もある上、ディレクトリが細分化されてしまって管理が煩雑になる事を避けたかったため。

    既にアップロードされてしまったファイルについては、ファイルを移動させた上で、.htaccessを使用して元パスにアクセスした際にリダイレクトされるよう設定。

    RedirectMatch permanent /archives/(files|images)/(200[4-8])(.*) http://melog.info/archives/items/$2/$2$3

    しかし、内部リンクをリダイレクトさせておくのも気持ち悪いので、既存のエントリに書かれた旧パスをMovable Typeの置換え機能を使って一括編集し、新パスに置換えることにした。ちなみに、Movable Typeが正規表現の後方参照をサポートしていないのか上手く動作してくれなくて、一度うっかり大量にパスを書き間違えるという失敗をしてしまったので、怖くなって正規表現を使わずにパスの変更。
    これで、内部リンクからのリダイレクトは解消。

    また、Movable Type のバージョン4から登場した(とてつもなく貧弱な)ファイル管理機能に関して。ファイルアップロード先を動かしたので、当然ファイル管理画面で「ファイルが無い」という警告が表示される。これに関しては無視しても良かったのだけど、何だかすっきりしないのでAsset Handlerなるプラグインで、新しい保存先のファイルを一括でファイル管理に追加した。

    なお、この作業に伴ってapacheのファイルリストを使ったアップロードファイルのリストを公開。まぁ、あんまり褒められないような画像ばかりなのだけど。

    Index of /archives/items

    HTML出力はいじれそうにないので諦めた。使用サーバ(CORESERVER)の標準状態ではアイコンが無かったので、Silk Iconsという16×16のアイコン(png)を用意。ただし、「Parent Directory」のアイコンだけは適当な物が無かったので、組み合わせて作成。32bitアイコンなので、IE6では背景が灰色になってしまうけど、まぁ気にしない。
    .htaccessをいじってみたけど、何故か「DefaultIcon」の設定が正常に動作せず…何でだろう。

    とりあえず、今回やった作業はそんな感じで。

    追記

    アイコンをいじってたら、何だかこのサイトにもアイコンを入れたくなってきた。個人的に、転送量が増える等の理由で今までアイコンを忌避していたのだけど、機能に対する視認性の向上、デザインの豊かさ、既にアイコン程度のサイズでは転送量として問題にならないといった点を考慮していくと、アイコン等の画像を使用するのも悪くないと思えてきた…。

  • Movable Typeはver4になって非常にお節介になった。
    その一つとして挙げられるのは、文字の置換え機能。いくつかの文字をエンティティや代替文字に自動的に置換えてしまう。
    管理画面の設定から「Word特有の文字を置き換える」の項目で変換の有無を変更することができるが、ここで「置き換えない」と設定しても、何故か三点リーダー(…)だけ(他にあるかもしれない)は勝手にエンティティ「&#133;」に置換えられてしまう。本文中の三点リーダーを置換えるならまだいいのだけど、これがタグ名まで勝手に置換えてしまう。そのため「地球へ…」のタグに上手くアクセスできなくなるという事態に。
    もうこの置換え機能はハッキリ言って鬱陶しいので、この三点リーダー問題を解決する方法は無いかと思って調べてみるとピタリの記事が。

    MovableType4で三点リーダーを表示する方法 – オンライン小説なオリジナル小説サイト うにたな

    [ブログ記事設定]内で[Word特有の文字を置き換える]という項目がある。デフォルトでは[Smart Replace]の[対応するASCII文字]にチェックがはいっていると思う。[置き換えない]にチェックをいれてしまいそうになるが、これは罠。[置き換えない]にチェックをいれてはいけない(三点リーダーとMovable Type 4(さらなる疑問)参照)。

    [Smart Replace]で[エンティティ]か[対応するASCII文字]にチェックがはいっていると、[置き換えるフィールド]という項目が表示される。[置き換えるフィールド]では、[タイトル]や[ブログ記事]などにチェックがはいっている。チェックを外せば文字の置き換えはおこらない。三点リーダーが晴れて表示されるようになる。

    なんて罠を仕掛けるんだ、SixApart。でもこれ、明らかに挙動としておかしいね。普通に考えれば、三点リーダーだけ変換されてしまう動作の方がまともじゃない。
    いつもの事だけど、どうもMovable Typeの初物は変なバグがてんこ盛りだなぁ。

    なお、既存のページを「&#133;」から「…」に置換えたい場合、Movable Typeの管理画面から検索・置換えで一括処理可能。

  • ApacheはURLに「%2F」が含まれていると404エラーを返す。

    kawama.jp: PATH_INFOに「%2F」が含まれていると404エラーになる(AllowEncodedSlashesで解決)

    “%2F”は、”/”(スラッシュ)をURLエンコードした物。これがあると、Apacheは404 Not Foundを返すそうな(もちろん、末尾のクエリ文字列にある分には問題ない)。回避策として、Apacheの設定でAllowEncodedSlashesをOnにするという手段があるそうだけど、バージョンは2.0.46以降でないと使えない。

    もう一つの回避策としては、URLエンコードされた文字をさらにエンコードするという手段がある。つまり、「%2F」を「%252F」とする。

    デジットさんの動的ページを静的ページに見せる2(PHP)

    本サイトでは以前、タグページのURLを静的アドレスに見せかけるという変更を行ったけど、この際タグ名に「/」が含まれていると、上記の問題が発生するため、mod_rewriteが機能しなくなる。生憎現在使っているレンタルサーバは1.3.37だそうなので、1つめの回避策は最初から対象外。
    そこで、Movable Tyep側でタグ名をURLエンコードした際、アドレスに含まれる”%2F”を置換える処理を追加した。具体的には、以下のようにする。

    <$MTTagName encode_url="1"$>
    ↓
    <$MTTagName encode_url="1" regex_replace="/%2F/","%252F"$>

    これはMovable Type 4から追加された、「regex_replace」という出力値を正規表現で変換するモディファイアを利用している。
    これにより、”%2F”→”%252F”という変換が行われる。この値をURLとして利用することで、上記の問題を回避することができる。

  • Captcha – Wikipedia

    Movable TypeにおけるCaptcha機能とは、自動生成される画像に描かれた文字を入力させる事で、人間の手による入力か否かを判定する、最近よく見かけるようになってきた認証技術。日本では「画像認証」と呼んだ方が通りがいい。これは、アカウント取得や書き込み時の認証に用いられ、コンピュータによる自動処理やスパムを弾く役割を果たす。
    ただし、「Captcha」とは別に画像の読み取りに限らずコンピュータと人間を判別する技術の事なので、音声による認証、問いに対する答えを入力する事で認証させるような物も指す。念のため。

    今回、このサイトにCaptchaを導入。コメント入力欄に「Captcha」という項目を設けて、コメント入力時の認証に使用している。まぁ導入とはいっても、Movable Type 4には標準でCaptchaの機能があるので、それを有効にしたというだけの話なのだけど。
    その効果の程はというと、毎日大体5~6通溜まってたスパムコメントが、導入後に一切来なくなっているという結果に。これにはさすがに感心してしまった。

    ただし、導入に当たって難点が1つ。
    Captcha入力用のテンプレートタグが自由にいじれない事。Movable TypeでCaptchaを使用する場合、テンプレートに以下のタグを貼り付ける。

    <$MTCaptchaFields$>

    すると、再構築時に以下のようなタグが生成される(見やすさのため改行を挿入)。

    <div class="label">
    <label for="captcha_code">Captcha:</label>
    </div>
    <div class="field">
    <input type="hidden" name="token" value="********" />
    <img src="http://melog.info/mt/mt-comments.cgi/captcha/2/********" width="150" height="35" /><br />
    <input name="captcha_code" id="captcha_code" value="" />
    <p>画像の中に見える文字を入力してください。</p>
    </div>

    これは現在のところ変更できないので、とりあえず妥協するしかない。そのうちいじれるようになる事を祈ろう。

    あと問題点と言えなくもない点として、Captcha自体がアクセシビリティを妨げている点。書いてある事を入力させるだけなのだけど、ユーザーに対して作業工程を一つ強制する事になる。また、画像を「目で読む」必要性があるため、視覚的な認証が行える人間のみが相手となってしまう。
    まぁその問題自体はCaptchaという技術の根本的な問題点なので如何ともし難いのだけど。

    そんなこんなで、Captchaの運用開始となります。

    ちなみに自分がCaptchaという技術を一番最初に見たのは、マイクロソフトのMSNアカウント(現在のhotmailよりも前)取得時だったかな。2001~2002年頃と記憶している。技術自体は2000年に開発されたそうだ。わずか数年でこんな一般ユーザーが容易に扱えるレベルまで実用化されるという辺り、この技術の需要の高さが窺える。

  • Movable Typeにはタグ機能がある。
    「タグ」とは言っても、<>で囲まれるアレではなくて、エントリーに対して設定するキーワード機能。両者とも ラベル付けするといった意味の「タグ」ではあるのだけど。以前、Movable Typeはこのタグ機能を「エントリータグ」、テンプレートに使うタグを「テンプレートタグ」または「タグ」と呼称していたけど、今は逆に「タグ」と呼ぶと「エントリー・タグ」の方を指すようだ。っていうか、ヘルプから「エントリータグ」の名称がスッパリ消えてる。

    さて、このタグ機能。特定のタグを含むエントリーの一覧ページへのリンクを作りたい場合、そのアドレスはMovavle TypeのテンプレートからMTTagSearchLinkを呼び出せばいい。しかしこの場合、アドレスは”http://xxx/mt-search.cgi?tag=xxx&blog_id=1″という感じで出力されてくる。
    これは要するに、「作成した複数のブログの中からID=1に該当するブログで、かつタグ名xxxを持つエントリーを探す」ことを意味する。要は、検索機能を応用したもの。

    困ったことに、サイトを移転すると設定によってはIDが変更されてしまう場合があり、「blog_id=1」(「IncludeBlogs=1」の場合もあり)の部分で引っかかってくる可能性がある。というか、実際に最近移転の際に引っかかった。こうなると旧来のアドレスは使えなくなる。リンク設定とか色々面倒くさいし、検索エンジンからの来訪者にも悪い。IDが異なるだけで以前のアドレスが使えなくなるのは、馬鹿馬鹿しいにも程がある。
    なるべく環境依存の要素を排除したい自分としては、このMTTagSearchLinkによって作られるアドレスは好ましくない。そんなわけで、.htaccessをいじってアドレスを偽装(人聞きが悪い)することにする。

    アドレスの変更

    今回、タグページのアドレスを以下のように変更することにした。

    “http://melog.info/mt/mt-search.cgi?tag=xxx&blog_id=1”

    “http://melog.info/archives/tags/tag=xxx”

    これは、タグページのアドレスをarchivesディレクトリ以下にすることでアーカイブの一部として見せかけること、クエリを示す「?」を排除して検索エンジンに拾われやすくすること、IDを削除すること、といった目的がある。実は最初、”http://melog.info/archives/tags/xxx”というアドレスに設定しようと思ったけど、「.htaccess」「.htpasswd」といったタグへのアクセスは弾かれてしまうし、「index.html」といったタグが存在した場合に処理がややこしくなるため、頭に「tag=」を付けることにした。.htaccessをいじって回避させることもできるけど、あまりイレギュラーな設定をすると後で困りそうだし、セキュリティ上好ましくないため、やめた。

    とりあえず”tags”ディレクトリを作成し、index.htmlのみ配置。
    ここで、.htaccessに以下のような記述を追加する。

    RewriteEngine On
    RewriteCond %{REQUEST_URI} !^/archives/tags/index.html$
    RewriteRule ^archives/tags/tag=(.*)$ mt/mt-search.cgi?tag=$1&blog_id=2 [L]

    これで、”http://melog.info/archives/tags/tag=xxx”のアドレスにアクセスすると、”http://melog.info/mt/mt-search.cgi?tag=xxx&blog_id=2″のデータが表示されるようになる。
    ついでに、過去のアドレスにアクセスした場合、現在のアドレスにリダイレクト(転送)されるような設定も追加する。

    RewriteEngine On
    RewriteCond %{QUERY_STRING} .*tag=(.*)\&blog_id=3.* [OR]
    RewriteCond %{QUERY_STRING} .*tag=(.*)\&IncludeBlogs=3.*
    RewriteRule ^mt/mt-search.cgi$ /archives/tags/tag=%1%2? [R=301]

    ええ、昔はID=3でした。今は2です。本当は1にしたかったのだけど、どうしてもMovableTypeで最初に強制的に作られる初期ユーザーが1になってしまうので諦めた。
    ちなみに、RewriteRuleの転送先は末尾に「?」を付けないと、転送元のクエリがそのまま残ってしまうという不思議な挙動が見られる。そういう仕様だそうだけど、何だかなぁ…。あとこれ、下手をすると無限ループが発生するので注意。mod_rewrite難しい。

    リンクの変更

    タグページが本来のアドレスではなくなったので、当然アドレスの取得にMTTagSearchLinkは使えない。…いや、別に従来のアドレスが消滅したわけではないので使えないわけではないけど、それでは意味がない。そこで、代替手段で何とかする。
    タグページのアドレスにある「tag=xxx」のxxxは、タグ名をURL用にエンコードした値が使われている。そこでMTTagNameをURL用にエンコードして取得する。

    <$MTBlogArchiveURL$>tags/tag=<$MTTagName encode_url="1"$>

    encode_urlは、MovableTypeにおけるテンプレート要素の汎用属性。対象の値をURL用の値に変換してしまう。これで、”http://melog.info/archives/tags/tag=xxx”というアドレスが確保できる。あとはこれをaタグのhref属性に入れるなり何なりすればいい。

    そんなわけで、タグを含むエントリー一覧のアドレスを操作するお話でした。

    追記

    敗…。
    このやり方だと、apacheタグ名に”/”(スラッシュ)があると上手く転送されないことが判明。

    kawama.jp: PATH_INFOに「%2F」が含まれていると404エラーになる(AllowEncodedSlashesで解決)

    つまるところ、パスの中に「%2F」が存在している事が駄目らしい。クエリの中なら大丈夫だったのだけど…。
    解決にはapacheのVer.2.0.46以降で、AllowEncodedSlashesをONにする必要があるそうだけど、今使われているapacheのバージョンは1.3.37…さて、どうしたものか。

    ちなみに、「%2F」ではなく「%252F」と書くと上手く動いてくれる。%2FをさらにURLエンコードしたもの。
    これを何とか適用させる方法を考えるか…。

  • カテゴリのページの先頭に、タグクラウドを表示するようにした。例えば、Informationカテゴリのページには、そのカテゴリーに含まれる記事に付けられたタグの一覧が表示される。これは最近色々なサイトで見かけるようになってきたけど、情報のインデックス化手法として面白いと思ったので自分のサイトでも採用してみた。しかし、Animeのタグの多さはどうしたもんか。
    なお、Movable Typeの初期の頃はタグ機能が無かったので、最初の方の記事にはタグが付けられていない。そもそも、タグ付け方は自分の感性で適当に決めているので、あまり確実な情報インデックスではないのだけど、まぁ見た感じ面白いのでいいかな、と。

    Movable Typeでこれを実現するには、MTCollateというプラグインを用いる。これは大雑把に言えば、一覧データを一度取り込んだ後、その一覧データを整形して出力するというプラグイン。

    例えば今回のように、現在のカテゴリに含まれるタグの一覧出力するには、カテゴリアーカイブのテンプレート内部で以下のような記述を用いる。

    <MTCollateCollect name="TagList">
    <MTEntries><MTEntryTags>
    <MTCollateRecord>
    <MTCollateSetField name="TagLabel"><$MTTagLabel$></MTCollateSetField>
    <MTCollateSetField name="TagSearchLink"><$MTTagSearchLink$></MTCollateSetField>
    <MTCollateSetField name="TagRank"><$MTTagRank$></MTCollateSetField>
    </MTCollateRecord>
    </MTEntryTags></MTEntries>
    </MTCollateCollect>
    <MTCollateList name="TagList" sort="TagLabel:distinct">
    <a href="<$MTCollateField name="TagSearchLink"$>" class="tagRank<$MTCollateField name="TagRank"$>"><$MTCollateField name="TagLabel"$></a>,
    </MTCollateList>

    MTCollateCollectの中でリスト情報を取得して変数に格納、MTCollateListの中でリストの出力を行う。
    この場合、カテゴリー一覧よりタグを抜き出して、それを昇順にソートして出力するという処理を行っている。MTCollateListのsort=”TagLabel:distinct”は、TagLabelの値でソート&重複データは出力しない、という意味。TagLabelにはMTColalteCollect内でMTTagLabelの値を入れている。

    MTCollateプラグインは、標準の方法ではできないような並び替えや出力を行う事ができる汎用性のあるプラグインなので、これが使えると、MovableTypeデザインの自由度はかなり高まる。そんなわけで、割とお勧め。

  • 最近、サイトの構成を色々いじっているため更新をさっぱりしていないという、本末転倒な事をしている。

    特に大きな変更は、カテゴリ構成を変更している事。以下は、新たに追加したカテゴリー。

    Trip:外出・旅行の感想(Myselfのサブカテゴリ)
    Broadcast :新番組、放送情報についての感想(Topicのサブカテゴリ)
    Release:新発売、新公開情報についての感想(Topicのサブカテゴリ)
    Movie:映画を見た感想(Videoのサブカテゴリ)

    それに加えて、AnimeをVideoのサブカテゴリに移動。
    カテゴリ分けが大雑把でどうしても特定のカテゴリに記事が集中しがちだったので、ここいらで少し整理する必要を感じたのだけど、作業が面倒で面倒で…。あと、Movable Type 4にしたはいいけど、これがインターフェースが異様に重くて使いにくい。

    もう少し色々いじりたいな…。旅行記もさっさと書かないと。

  • Six Apart – Movable Type

    ブログソフトウェア「Movable Type」の最新バージョンとなる4.0をこのサイトに導入。
    アップグレード自体の作業は物凄く簡単。ほとんどの作業は自動でやってくれる。この辺の操作の簡素さは他のソフトも見習うべき。

    でまぁ、インストールしてその設定画面の変わりようにビックリだ。何か全然違う画面になっている。まぁ設定項目はほとんど変わってないので、実態はそれほど変わってないと思うのだけど。
    しかし、アップグレードしてからいくつかのプラグインが正常に動作していない事が分かった。あと、メイン画面のエントリーの並びがおかしい。この辺はちょっと修正する必要があるな…。

    Movable Type 4 で追加された新しいテンプレートタグ

    タグがいっぱい増えて困ったもんだ。一応、できること/できないことを把握するために一通りの機能は把握しておきたい。3.xなら一応大体の機能は把握してたんだけどね…。これだけ追加されるとなかなか大変そうだ。

  • いつもこのサイトを見ている人は気付かれたかもしれませんが、本日本サイトで、Movable Typeの機能の一つである「エントリー・タグ」の機能を有効にしました…っていうか、自分でテンプレートHTMLを書き換えたのだけど。

    エントリー・タグというのは、エントリーにタグ(キーワード)を与えて、共通のタグを持つエントリーを一括りで扱えるようにして分類するための機能。もちろん、自分でタグを与えてやる必要がある。エントリーを構造化して分類するカテゴリーとは使い方が異なる。
    ちなみに、カテゴリーのような分類をトップダウン型、エントリー・タグのような分類をボトムアップ型と言う事を、最近初めて知った。

    さて、以前書いたようにこのエントリー・タグ、Movable Typeのデフォルト状態では、共通のタグを持つエントリーを抽出し、それをカテゴリーによって構造化するという手法が無い。ただ単に同じタグを持つエントリーを列挙するだけでは、情報が煩雑になってあまり意味を為さないと考えたため、列挙したエントリーをさらにカテゴリで分類する方法が無い以上、このカテゴリー・タグを使う気にはならなかった。
    しかし、それを何とかして実現できないかと考え、色々プラグインを漁ってみたところ、何か良さそうなプラグインが見つかった。

    MT Extensions: MTCollate 1.1

    これは、一度複数の情報(主にエントリー)を再帰的に呼び出してそれを要素としたリスト(複数の要素も可)を作り、そのリストをソートしたりして出力させるという物。つまり、一度同じタグを持つエントリーを抽出し、それをソートして出力させることで、目的の構造化を達成できる。これの詳しいやり方については、時間があればまた。

    このエントリー・タグ結果、何時間かかけてサイト構成を見直し、いくつか手直しを行った。
    まず、従来のカテゴリをいくつか削除し、置き換えた。例えば、今まで「ローゼンメイデン」のアニメ感想をまとめたページがあったのだけど、それを「ローゼンメイデン」というタグを持つページの抽出結果で代用する事にした。
    あと、当然の事ながら各エントリーに対して、タグおよびタグリンクを出力するようにした。
    また、エントリー・タグ専用のインデックスも作成した。

    とりあえず、昔のエントリー・タグ機能が無い頃のエントリーに関しては、後から修整をしていくしかない。カテゴリーを置き換える上で必要な物は変更したけど、あんまり目立たないエントリーの扱いは困るな…。もうすぐエントリー数が1000を達成してしまうだけに、昔に遡るのはちょっとしんどい。

    ちなみに、「カテゴリー」「エントリー・タグ」などと書いても普通の人は何のこっちゃという感じだと思うけど、このサイトの場合はカテゴリーを「記事の種類」、タグを「記事の内容」と置き換えて考てもらえると有り難い。カテゴリーの種類はこの先ほとんど変わらないと思うけど、エントリー・タグの種類はモリモリ増加していく。
    本当はこんな呼び方より、他者に分かりやすい表記(さっきの「記事の種類」とか「記事の内容」)にしようと思ったんだけど、インターフェース的な部分の文字はASCII文字で統一したいと考えているので、結局表記はそのままに…。本当は、どういう意図で用いて何を表した物なのかを明確に理解できる表記にする事が望ましいんだけど(さらに言えば、日本人が対象なら、変に気取らず日本語が望ましいと、個人的には思う)。

    さて、あと色々手直ししないといけない箇所があるな…。

  • Movable Typeのバージョン3.3から、「カテゴリー・タグ」なる機能が追加されている。

    これは、記事にキーワードを付加する事で、共通のテーマを持つ記事を探しやすできる機能。自分は、まだHTML上に出力してないだけで、一応このエントリー・タグの入力はしている。まだデータ上存在しているだけ。使い所が難しいのでまだ保留している状態。

    既に「カテゴリー」という機能はあるけど、こちらはカテゴリーがツリー構造となるため扱いが難しい。例えば、「ゲーム」とういカテゴリーがあったとして、ここにゲームの感想を入れるとする。他に「日本ファルコム」というカテゴリーを作り、ここに日本ファルコム関連の記事をまとめるとする。じゃあ「日本ファルコムのゲームの感想」はどちらに書けばいい?と考えると話が難しくなってくる。恐らくこれは人によるだろう。もっとも、以前から2つ以上のカテゴリーを付加する機能はあるのだけど。ただ、常に限定された情報を書くサイトならともかく、新しい事をする度にカテゴリー追加を行うのは面倒臭い。

    ver3.3から追加された「エントリー・タグ」によって、記事にキーワードを付加する事で、同じキーワードを持つ記事を抽出することができるようになった。恐らく、このMovable Typeを利用した多くのブログサービスでは、既に同機能が提供されているのではなかろうか。実際、最近いくつかのブログサービスでも見かけるようになった。
    これは、記事を書く際に筆者のセンスで適当に書き加えるアバウトな物。例えばこの記事なら「Movable Type」「エントリー・タグ」「カテゴリー」というタグが書き加えられている(最後の「カテゴリー」は我ながらどうかと思うが)。ただ、「パソコン」と「PC」は別物になったりするため、綺麗にカテゴライズしようと思ったら、事前に既存のエントリー・タグを見て綴り間違い等が無いかどうかチェックが必要になる(ある程度の補正はしてくれるようだ(英文限定?))。
    形態素解析の機能でも付加されれば、そのうち自動的に付加されるような仕組みが出来上がるかもしれない。

    さて、この二つのカテゴライズ手段をどう使い分けるか、と考えるとまた話が難しくなってくる。エントリータグ一本に絞るのもアリといえばアリだけど、煩雑になりすぎてしまうのもどうかなぁ…と。
    そこで、ちょっと考えてみた。
    カテゴリーの側に、「アニメ感想」「ニュース」「ソフトウェア」といった記事の大まかなジャンルを設定する。サブカテゴリまで使うなら、「映像 – アニメ」「ニュース – スポーツ」といった感じで。
    エントリー・タグの側に、「日本ファルコム」「ZEGAPAIN」「ディスプレイ」といったような、固有名詞や製品のジャンルといった、具体的な情報を設定する。
    こうする事で、「日本ファルコム」の「ニュース」とか、「ZEGAPAIN」の「アニメ感想」といったような、形でカテゴライズできるようになるのではないか、と。つまり、カテゴリー機能には記事のジャンル・方向性を、エントリータグには記事の対象・テーマを、といった形でカテゴライズすれば、上手く機能するんじゃないかと考える。

    もちろん、どこまでをカテゴリーで扱って、どこまでをエントリー・タグとして扱うか、という点を考慮する必要はある。これも人によりけりだろう。指針としては、「[どんな物]の[どんな記事]」といった感じで考えると分かりやすいかな。「デジタルレコーダー」の「ハードウェアレビュー」とか。この場合、[どんな物]がエントリー・タグ、[どんな記事]がカテゴリー、という事になる。記事の種類なんて別に無限に増えていく物ではないのだから、カテゴリーの種類をある程度決め打ちしてしまって、後はエントリー・タグによる追加を行っていくのがいいんじゃないかと思う。
    この方法ならば面白い作用もあって、ある特定の作品に対してアニメ、漫画などの別のメディア等が存在する場合、それぞれを明確に分割したい時にも使える。例えば、「ローゼンメイデン」の「アニメ感想」、「ローゼンメイデン」の「漫画感想」、「ローゼンメイデン」の「イベント」、「ローゼンメイデン」の「自作絵公開」など。

    ただ問題は、現在のバージョンのMovable Typeにおいて、それらを上手く出力する手段が存在しないという事。(ダメすぎ(笑))
    例えば、カテゴリー「アニメ感想」に含まれる、エントリー・タグが「ZEGAPAIN」の記事、という表示方法は、タグ仕様を見る限り現状では無理。それができるようになれば、扱いやすいサイトが構築できると思うんだけど…。
    SixApartに意見書でも提出してみようか。

  • Six Apart – Movable Type News: Movable Type 3.3 正式リリース
    Six Apart – Movable Type News: お詫び: 再ダウンロードのお願い

    ウェブサイト(主にウェブログ)の管理・運営を行うためのスクリプト、Movable Type のバージョン3.3がリリースされました。リリース直後にファイル差し替えという珍事はあったものの、とりあえず無事リリースされた模様。

    というわけで、3.2から早速差し替え。差し替え時は、mt-config.cgiファイルと、自分でインストールしたプラグイン、自分でMovable Typeのスクリプトを書き換えていた場合はそのファイル、仮にデータベースを使っていなければアーカイブを保存したディレクトリ、といった物についてバックアップをとっておいて、現在Movable Typeがインストールされたディレクトリ以下をそっくり置き換えてしまえば完了。
    ただ、今回からmt-config.cgiファイルの中身が必要最低限の記述のみで必要に応じて「Movable Type 3.3 マニュアル: 環境変数」を参考にしながら自分で追記していく形になり、内容がスッキリしたので、mt-config.cgiも置き換えた方が良いかもしれない(以前はファイルの中に全部記述されていた)。

    で、使ってみたけど3.2から何が変わったのかよく分かりません。何やら「WidgetManager」というサイト上に表示するコンポーネントをカスタマイズする機能が追加されたり、サイトのスタイルを簡単に変更する事が出来るなったりしたみたいだけど、テンプレートをフルカスタマイズするという暴挙をやった自分には、あまり魅力がありません。
    あとは、「エントリー・タグ」なる機能が追加されたみたいだけど、これがどんなものかがよく分からんので保留。

    とりあえず、そんな事はどうでもいいからファイルアップロードのディレクトリを記憶するよう改善しろと。何でデフォルトがサイトのルートパスなんだ。別の所にアップロードしても設定は保存されないし。画像を頻繁にアップロードする人には毎度アップロードする事になるのでかなり面倒臭い作業になってしまう。これは以前から不満だったけど、一向に改善されない。ルートの直下にいつも画像やその他ファイルを置く人がいたら、逆に教えてもたいたいところだ。
    そんな事だから、わざわざ「Better File Uploader」などという皮肉っぽい名前のプラグインが作られるんだ。
    …って、3.3になってから、このプラグインが使えなくなってるじゃないか。プラグインの作者は少し待ってと言ってるので、多分そのうち対応バージョンが出てくるんだろうけど。

    今回のアップデートはデザイン面の変更が目につくばかりで、一部互換性が失われてしまうといった問題が起こった事は、正直ガッカリだ。

  • Movable Typeのテンプレートに用いる事のできるタグには、いくつか汎用的な属性を用いる事ができる。これは、タグの値を目的の形式に整えたりする時に用いる。例えば、タグによって出力される文字を全て小文字にしたりといったもの。その中に、「dirify」という属性がある。これは、タグの中に「dirify=”1″」と書き込む事で、出力される文字列をファイル名に適した形に変更する。例えば、ファイル名に適さない文字を除去したり、置き換えたり。

    前置きはここまで。最近、このサイトはMovable Typeのバージョンを3.2に上げたけど、どうもこのdirifyの挙動が変わっているらしい。今回目に付いた変化は、カテゴリー名にこれを用いた場合。今までこのサイトは、カテゴリーHTMLのファイル名を「category/c<$MTCategoryID zero_pad=”2″$><$MTArchiveCategory dirify=”1″$>.html」としていた。つまりこれは、c[カテゴリーに割り振られる一意のID2桁][カテゴリー名のdifiry].html、といった形。例えば今現在、「Book」カテゴリーのHTMLファイルは「c06book.html」というファイル名になっている。
    IDをファイル名につけるのは、重複を避けるため。というのも、このdifiry属性、日本語を除去する働きをするため、例えば「ローゼンメイデン」と「絶対少年」という2つのカテゴリーの場合、日本語が除去されてしまうと両方とも空の名前になってしまい、重複が起こる。そのため、このIDをファイル名に設定する必要があった。
    ところが今気付いた点として、このdirifyによって文字が空になった場合、勝手に「cat[カテゴリーに割り振られる一意のID]」という文字列が生成されるようになった模様。だから、今まで「ローゼンメイデン」カテゴリーのHTMLファイルは「c13.html」だったのに、今現在は「c13cat13.html」というファイル名になっている。
    これは、Movable Typeを扱う上ではあまり問題が無いのだけど、例えばそのカテゴリーHTMLに対して静的リンクを張った場合や、検索エンジンからの来訪には対応できない。だから、サイトを運営する側にとって、こういった仕様変更はあまり感心できない。せめて、以前の形式も併用できるように何らかの互換性を持たせて欲しかった。

    それ以前に、このカテゴリーに割り振られるIDはサイトを移転したりするとIDが振り直されてしまうため、できることならあんまり使いたくないんだよねぇ。
    ITmediaニュース:Movable Type開発は日本主導に 企業ニーズに対応」より、開発が日本に移された暁には、真っ先にこのdirifyの挙動を何とかしていただきたい、と思う。

  • Movable Typeでは、MTEntries タグを用いて最新の投稿エントリーを順番に一覧表示させる際(例えば、ホームページなどで用いられる)に、大きく分けて二つの方法がある。
    一つ目は、「lastn=”N”」を用いる方法。これは、最新の N 個のエントリーを表示させる。必ず N 個のエントリーが表示されるけど、短期間にエントリーを N 個以上作ると、1個目のエントリーからガンガン削られてしまう。
    二つ目は、「days=”N”」を用いる方法。これは、最新の N 日以内のエントリーを表示させる。どれだけ多くても N 日以内のエントリーが全て表示されるけど、N 日以上更新しない場合、次に更新した時にいきなり何も表示されなくなるか、新たに記述したエントリーしか表示されなくなる。
    つまり、前者は頻度の高い更新に弱く、後者は頻度の低い更新に弱い。よって、どちらの方法も安定した表示が行えるとは言い難い。

    そこで、これを解決する方法が無いかと思ってあれこれ調べてみた(自分で書ければいいんだけね…、Perl分からない。覚える気があまりない)。すると、海外のサイトで以下のページを発見。

    Alexei’s Weblog ≫ MTIndexEntries: Making Movable Type indices a little more reasonable

    ここにある「MTIndexEntries」なるプラグイン。これは、「lastn」と「days」を同時に指定する事で、どちらかエントリー数の多い方の表示方法を行うプラグイン。
    例えば、高い頻度で更新した場合、数日の間に多数のエントリーが作成される。この時、エントリーの数は lastn < days となるので、「days=”N”」が優先され、N 日以内のエントリーが表示される。しかしその後、更新を数日休んだとしても、今度は lastn > days となるので、「lastn=”N”」が優先され、次に更新しても今度は最新の N 個のエントリーが表示される事になる。これによって、柔軟な表示が行えるようになる、という理屈。まぁ言い換えると、最低「lastn」分の表示数を保証した「days」、ということになるのかな。
    ちなみに、MTEntries で「lastn」と「days」を同時に使用しても、「lastn」が優先される様子。

    使い方は、プラグインをpluginディレクトリに放り込んで、<MTEntries>タグを、そのまま<MTIndexEntries>に置き換えれば良い。

    追記

    …っていうかさ、Movable Type側で最初から「最後に更新されたN日分のエントリー」を表示させる方法を提供してくれれば、こんなに悩まずにすむのに…

  • 最近、Movable Typeのバージョンを3.1から3.17に変更した。別に大した理由があったわけでもなく、何となく。で、ちょっとテンプレート・ タグを眺めていたら、設定が追加されている事に気付いたので、それを使ってテンプレートにちょっと手を加えてみた。

    それは、「日付タグのフォーマット」の部分。これは要するに、日付などの時間を出力するためのタグで、曜日も出力することができる。この曜日の出力が、以前のバージョンでは「○曜日」という出力方法しかなかった。ところが、久々にバージョンアップしてみると、ここが「○」という出力ができるだけでなく、language属性を設定することで、英語も出力することができるようになっていた(Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, Saturday / Sun, Mon, Tue, Wed, Thu, Fri, Sat)。
    この曜日文字列を用いて、曜日別のスタイルを設定してみる。今回やったのは、日曜と土曜の場合に色を変える事。
    例えば、Movable Typeによって生成されるHTMLの中から、スタイルを適用したい適切な要素に対して、

    class="week<$MTEntryDate language="en" format="%a"$>"

    とすることで、日曜ならclass=”weekSun”、土曜ならclass=”weekSat”といったclass属性を付けることができる。あとはこのクラスに対して、CSSでスタイルを適用する。これによって、曜日別のスタイルが設定できる。

    …とまぁここまで書いて気付いたけど、class属性の値って普通に日本語使えるのか…。知らなかった(ちなみに、id属性は日本語無理)。まぁ互換性を考えれば使わない方がいいとは思うんだけど。しかしそれ以前に、Movable Typeが吐き出す日本語の曜日はエスケープ文字だったので、バージョンアップする以前から元々問題なかった事にも気付いてしまった。以前、何故これと同じ事をしようとして諦めた記憶があるんだけど…何でだろ。CSSの視認性と、値が冗長すぎたのが問題だったのかなぁ。

  • 現在使用しているMovable Type (以下MT)のバージョンを、3.0から3.1に(正確には、3.01-jaから3.11-jaに)バージョンアップ。今回のMTでは、サブカテゴリが使える、動的生成が使えるようになるという話が何処かの雑誌に書いてあったような気がしたので、その辺りの機能を割と楽しみにしていた。
    バージョンアップして早速手をつけたのが、サブカテゴリ。元々自分のカテゴリ分けは、こういったサブカテゴリを使う事をある程度視野に入れて作ってたので、早々とサブカテゴリを作っておきたかったというのがその理由。サブカテゴリを作るプラグインがあるらしい、という事は知っていたので、いつかそれを使おうと思っていたところ、正式に導入されたので手間が省けた。
    で、テンプレートタグをあれこれいじり回してみたけど、これが結構面倒臭くて分かりにくい。ドキュメントを読みながら、あーでもないこーでもないと試行錯誤しながら、やっと何とかそれっぽく作れるようにはなった。あとでGoogle見て気付いたけど、もうすでに英語版等を導入した人が書いた資料が結構あるのね…。それにしても、MTのテンプレート・タグのドキュメントは分かりにくい。色々と中途半端な感じがする。もう少し論理体系を考慮したドキュメントが書けそうな気がするけどな…。少なくとも、コンテナタグと単体のタグを一目で分別できるように、スタイルを考慮してほしいところだ。
    まぁそれはさておき、今のところカテゴリの分別はこちらのページに書かれているような感じになっている。もう少し色々追加するかもしれないけど、今のところはこんな感じで。あまり細々と分けても、エントリー書くときにちょっと大変になってしまいそうだ。…カテゴリ選択のインターフェースが、全カテゴリを文字順で並べたものをリストした単体のプルダウンメニューというのは、何とかならないものだろうか…。
    あと、親カテゴリから子カテゴリへのリンク等、ページ同士のリンクも全然作ってないので、その辺も後で何とかしておかないと。

    Web見れば色々と資料があるので不要かもしれないけど、一応サブカテゴリに関してあれこれメモを書き残しておく。

    カテゴリのリストについてメモ。

    従来のカテゴリのリスト表示方法 MTArchiveList コンテナの archive_type=”Category” 、および MTCategories コンテナでは、トップレベルカテゴリもサブカテゴリも一緒に読み込む。新しく追加された MTSubCategories なら、サブカテゴリを任意の方法でリスト表示できる。これは普通、Categories コンテナを置き換えることで実現するが、MTArchiveList コンテナの archive_type=”Category” で、サブカテゴリを任意の方法でリスト表示させる方法がよく分からない…というか、無いと思う。ちなみに、MTSubCategories では従来と違って、エントリーが存在しない場合でもカテゴリを強制表示させる。解除方法は知らない(これも無いのかな?)。

    で、自分は以下のような構造でリスト化することにした。

    トップレベルカテゴリ
    └ サブカテゴリ
    トップレベルカテゴリ
    トップレベルカテゴリ
    ├ サブカテゴリ
    │ └ サブカテゴリ
    └ サブカテゴリ

    このようなリスト構造を実現する方法は複数ある。好きな方で。

    (1)
    <ul class=”categoriesList”>
    <MTSubCategories>
    <li><a href=”<$MTArchiveLink$>”><$MTArchiveTitle$></a>
    <MTHasSubCategories>
    <ul>
    <$MTSubCatsRecurse$>
    </ul>
    </MTHasSubCategories>
    </li>
    </MTSubCategories>
    </ul>

    (2)
    <MTSubCategories>
    <MTSubCatIsFirst><ul></MTSubCatIsFirst>
    <li><a href=”<$MTArchiveLink$>”><$MTArchiveTitle$></a>
    <$MTSubCatsRecurse$>
    </li>
    <MTSubCatIsLast></ul></MTSubCatIsLast>
    </MTSubCategories>

    ちなみに、MTSubCatIsFirst と MTSubCatIsLast というタグ、マニュアルを読むと “MTSubCatsIsFirst”、”MTSubCatsIsFirst”となっているけど、これはマニュアルの間違いの様子。これだとタグが機能しないので注意。
    また、dl要素を使ってカテゴリ概要も記述する場合は以下のような感じで。これも2種類できるけど、かたっぽの方で。

    <dl class=”categoriesList”>
    <MTSubCategories>
    <dt>
    <a href=”<$MTArchiveLink$>”><$MTArchiveTitle$></a>
    </dt>
    <dd>
    <$MTCategoryDescription$>
    <MTHasSubCategories>
    <dl>
    <$MTSubCatsRecurse$>
    </dl>
    </MTHasSubCategories>
    </dd>
    </MTSubCategories>
    </dl>

    ちなみにこのこれらの場合、サブカテゴリの段階別にスタイルを設定するということができない(2段までなら何とか…)。いや、もしかしたら上手くスタイルを指定する方法があるのかもしれないけど、自分は分からない。現在サブカテゴリの何段目なのかを取得するMTタグを希望。

    今日はこのカテゴリ関連で力尽きたので、動的生成に関しては気が向いたらいじっておこう…。

    追記

    h5>10月21日 12:40

    <$MTArchiveLink$>、<$MTArchiveTitle$>は、
    <$MTCategoryArchiveLink$>、<$MTCategoryLabel$>と置いた方がよさそう。MTArchiveList をそのまま引きずってしまったので前者の方で書いてしまったけど、カテゴリ関連のコンテナ内ではこっちの方が正しい…と思う。一応どっちでもできると思うけど。

  • Movable Typeは、標準状態で個別のアーカーイブを
    [アーカイブディレクトリ]/[年4桁]/[月2桁]/[タイトルに基づくファイル名].html
    という場所に保存する。以前からいじくってたのに、さっきそのこと気付いた(遅すぎ)。
    まぁディレクトリ構成はそれでいいんだけど、そのファイル名が問題だ。タイトルに基づくファイル名というのは、英字ならそのまま出力されるのだけど、日本語だと支離滅裂な英字で出力される。ハッキリ言ってファイル名による視認性は最悪だし、意味のあるソートもできないので機能的にも最悪だ。こんな設定がデフォルト状態になっているというのはいかがなものか。
    というわけで、これを何とかしようと思い、色々調べてみた。まず、管理メニューの「ウェブログの設定 > ウェブログの設定 > 以前の形式の個別アーカイブへのリンクをつかう」(Ver 3.01D-ja の日本語メニュー。以下同)にチェックを入れてみる。何やら、以前はidで管理していたらしい。そっちの方が遥かにマシだと思うけど…と思っていたが、この設定、ディレクトリの分別無しにアーカイブディレクトリに全部のhtmlファイルを押し込んでしまうらしい。…以前はこんな管理してたのか。どうも設計側の思想が理解しかねる。
    で、他に方法は無い物かと思って調べてみたら、「ウェブログの設定 > アーカイブの設定 > アーカイブ・ファイルのテンプレート」の中のという項目をいじればいいらしいということが判明。早速変更。結果、

    個別アーカイブ:
    <$MTArchiveDate format="%Y"$>/<$MTArchiveDate format="%m"$>/<$MTArchiveDate format="%d"$>_<$MTEntryID pad="1"$>.html
    月別アーカイブ
    <$MTArchiveDate format="%Y"$>/<$MTArchiveDate format="%m"$>/index.html
    カテゴリーアーカイブ
    category/<$MTArchiveCategory dirify="1"$>.html

    ということに。これはまぁ、個別が
    [アーカイブディレクトリ]/[年4桁]/[月2桁]/[日2桁]_[id8桁].html
    月別が
    [アーカイブディレクトリ]/[年4桁]/[月2桁]/index.html
    カテゴリーが
    [アーカイブディレクトリ]/category/[カテゴリー名(最適化)].html
    といった感じ。

    あー、すっきりした。でもこの作業してる間、画像一つ間違えて消してしまった…。ちくちょう。

%d人のブロガーが「いいね」をつけました。