超有名サイトなので今更紹介もないのですが、有料サイトは全部紹介しよう！という考えに立ち紹介します。MovableTypeで行こう！はMovableTypeの最新の動向等をウォッチするのに最適です。また、当然アップデートに関する情報やアップデートのやり方なども詳しく（インストールも詳しい）、うちのサイトでもいくつかリンクを貼らせてもらっています。

RSSリーダーというのはその使い方を知ってしまうととても便利なものなのですが、

記事の文書が段落や改行を無視して、すべて一行で繋がってしまう

自分の登録したRSSが全て読みやすくなるわけではなく、自分の発信するRSSのみが読みやすくなるだけですが、この輪が広がれば素晴らしいことですね。

というわけで、どの程度技量がいるのか（どの程度の面倒くささなのか）を確認してみます。

そこで、遅ればせながらtarget="_blank"を自動でいれる方法を探すことにしました。

すると、Nitch.net blogや21世紀のアフィリエイト通販生活などで紹介されていることがわかりました。

MT3.2のやり方は

mt-static/mt_ja.jsを開き（MT3.3の場合はmt.js）、function insertLink の中の、setSelectionの行を探します。

setSelection(e, '<a href="' + my_link + '">' + str + '</a>');
これに差し替え！

setSelection(e, '<a href="' + my_link + '" target="_blank">' + str + '</a>');
これでエントリー投稿画面からのリンクは全てtarget="_blank"がつきます。

ということらしいです。しかし自分はMT3.1なので、別のやり方を探さなければなりません。

（いっそのことこれを機会にMT3.2に上げるか、しかし、特段不便を感じていないので今しばらくこのままいじりたくない気持ちもある、そうすると、target="_blank"のところは二度手間になるし）

と思案していたところ、MovableTypeを攻略せよ！のコメントにステキなアドバイスがありました。

もっと簡単な方法を知らずにやってましたー ＜head＞内に ＜base target="_blank" /＞ いれるだけで実現してますよー どんな環境でもいけるかは疑問 でも、試す価値あり。

by 通りすがり - 2005/05/22 03:02
ふおっ！
たしかに＜BASE＞タグなら……
目からウロコがぽろりぽろり。
今からはじめる方は是非この方法で！！
わたしは，直すのが面倒くさ……
by ＪＫ - 2005/05/25 14:32

ということで、これならバージョンを気にせず対応できるので早速やってみましたが、問題無しです。
しかも、うちのように複数サイトを運営していても、Head部分を生成するだけのインデックステンプレートを用意し、複数ブログ（かつ複数テンプレート）共通として作成してあれば、修正箇所も1箇所だけと、超お手軽なわけです。

目からウロコとはまさにこのことですね。

ということで、Baseタグを使うことはボツで、先にMT3.2に上げることを検討したいと思います。というわけで、それまではいままで通り、target="_blank"は手でカット＆ペーストすることになりました（泣）

【2006/1/19追記】
3.2にアップグレードして上記の修正を行ないました。快適です！

【2006/9/9追記】
3.3にアップグレードしたのでやり直しました。修正対象がmt_ja.jsファイルでなくmt.jsファイルに変わりました。

昨日、今日の投稿であればさほど苦労せずに修正できますが、投稿数が100を超えてくると、過去の記事の修正がかなり面倒です。

記事タイトルで検索をかけて修正すれば早いですが、修正頻度が多いとはいっても、毎日頻繁に修正しているわけではなく、過去記事に関してはせいぜい月に1回か、もしかすると四半期に1回程度の割合であり、そんな頻度では、検索をかけるという技もいざというときには忘れてしまっていることでしょう。

そんなわけで、直したい記事が見つかったときにすぐにその記事の編集画面に飛ぶリンクが直感的に分かりやすい場所に用意されていることの方がずっと便利です。そんな方法がARTIFACTで紹介されていました。

それも面倒なら、indivisualのテンプレートに

<a href="<$MTCGIPath$>mt.cgi?__mode=view&_type=entry&id=<$MTEntryID$>
&blog_id=<$MTBlogID$>">EDIT</a>
　こんなソースをどこかにいれておきましょう。

そして、なぜこのようなものがリンクされているのか、素人が見て混乱させるだけのような気がするのですが、RSSリーダーのためには必要なのかなぁ、という程度の認識で置いておく訳です。

確かに、RSSリーダーでRSSファイルへのパスを入力しなければならないため、リンクが貼られていると便利です。しかし、RSSのファイルのパスは、サイトのURLが分かればプログラムが勝手に取得してくる仕様になっているRSSリーダーが大半だと思いますので、必ずリンクが貼っていなければならないわけではなさそうです。

そうしたところ、ADPでスタイルシートを使ってRSSファイルを人間が読めるようにする方法が紹介されていました。

まず、W3Cのライセンスに関する文面を見て一礼する（それでいいのか？？）。

次に、ADPのstyles-rdf.cssをかっぱらい、index.rdfが置かれるディレクトリ（<$MTBlogURL$>にあたるディレクトリ）に放り込む。インデックス・テンプレート中、RSS 1.0 Indexの2行目に、

<?xml-stylesheet href="<$MTBlogURL$>styles-rdf.css" type="text/css"?>
を書き込む。場合によっては、RDFファイルのMIMEタイプをtext/xmlか、application/xmlに変える必要がある。

styles-rdf.cssファイルはこちらから。

私の場合、最初、FTPの転送が甘かったようで、かなりあせりました。そこで、マイナーなRootFTPをあきらめ、FFFTPに乗り換えて再チャレンジしたところ、うまくいきました。

FFFTPでは『オプション』-『環境設定』-『転送３』で『*.cgi』を『755』に指定しておくと、後で属性変更しなくて済むので便利です。

とにかく、MovableType3.2導入手順さまさまです。ここのお陰で何とかアップグレードが完了しました。

up-rebuild.cgiを開くとmt.cfgという文字列がありますが、3.2からはmt.cfgがないので、ここをmt-config.cgiに置き換えます。

読みにくい文章というほどではない（はずな）ので、最初からじっくり読み直して行くことで、徐々に記憶が蘇ってきましたが、こうした現象を目の当たりにすると、適度な間隔でバージョンアップが行なわれるということは、「面倒臭い」と思うのは間違いで、「記憶の呼び覚ましの上で非常に有用」と捉えるべきだと分かります。

そういうわけで、MovableType3.32へのアップグレードをしようと決意し、まずはMovableTypeがどんなシステムで、自分はどういうカスタマイズを遂げてきたのかを、『MovableTypeを活用して脱初心者！』の過去記事をよく読んで理解することから始めました。自分の備忘録のために、このサイトを作っておいて本当によかったと思います（笑）

過去記事を読むことがおまじないとなって、「単なるアップグレードにおいて怖いものなど何も存在しない」と確信するにいたり、早速アップグレードを開始しました。アップグレードは、ロリポップのインストールガイドを見ながら進めればあっという間に終わってしまいますが、インストールとアップグレードは違うため、ちょっとだけ不安に思い、Milano::Monologも参考にさせてもらいました。

さて、3.32にアップグレードしてみたところ、いくつか変更点があるようです。一番目に付いたのは投稿画面の『タグ』という文字です。これについては別で取り上げますが、かなり進化した印象を持っています。その他にも有用な点が見つかり次第、主に備忘録のために投稿していきたいと思います。

アップグレードにより、『リンクにtarget="_blank"を自動的に入れる方法』をやり直す必要があることが判明しました（当然ですが）。3.3からはmt_ja.jsファイルの変わりにmt.jsファイルを修正すればできます。

色々調べてみた結果、『タグ』という用語が少し混乱を招く存在のような気がします。少なくとも短期的な視点では。

簡単に言ってしまえば、ここで用いられている『タグ』とはキーワードのことです。しかし、そうすると『タグ』の上に存在する『キーワード』とかぶってしまいます。従来のキーワードが主にロボット検索にヒットさせることを主眼においていたのに対し、『タグ』は人間が検索しやすいように発展させられたキーワードといえ、『タグ』を使うことで、本でいう索引が簡単に作れます。

ところが、『タグ』は、確かにより人間の感性（期待）に近い『キーワード』の性質を有しているのですが、それで止まらない可能性を秘めていると思います。したがって、『索引』だけが目的にならない、新たな用法が考えられるのではないでしょうか（既に考えられているかもしれません）。

となると、『キーワード』という用語は、固定観念を打破する障害になりますので、あえて『タグ』という用語を用いたと言えなくもありません。しかし、従来の『タグ』の概念との衝突がありますので、私的には『ネオ・キーワード』あたりになってくれれば、固定観念を打破するに十分な力強さも備わるし、理解しやすいと思ったりします。

まあ、『ネオ』という用語を安易に使ってしまうと、次の変革のときに『ウルトラ・ネオ・キーワード』になってしまい、更に変革を遂げたら、『ハイパー・ウルトラ・ネオ・キーワード（HUNK）』とかになって、『ハンク』とか言われて訳が分からなくなってしまうでしょうから、安易に『ネオ』という用語を使わなかったのは、長い目で見て正解だったのかもしれません。

随分と御託を並べてしまいました。『タグ』の利用について、少しだけ触れておきます。

『タグ』を理解するには従来の概念と比較するのが一番です。

『タグ』と『キーワード』との比較に関しては、上記でも簡単に述べているように、『タグ』を利用した索引を楽に提供するというものの他に、『タグ』で設定したキーワードが入っているエントリーが何個存在するのかという統計的な情報も提供してくれるようです。そういうわけで、繰り返しになりますが、活用の余地が増えたというのが実体でしょう。

『タグ』と『カテゴリ』の比較では、『カテゴリ』がトップダウンであるのに対して、『タグ』はボトムアップです。つまり、『カテゴリ』は綿密な計画の下に行なわれないと収拾がつかなくなり、無意味なものに成り下がりますが、『タグ』は行き当たりばったりでやっていてもうまくまとめてくれる可能性を秘めています。つまり、『カテゴリ』が硬直的なのに対して、『タグ』は柔軟であり、21世紀型と言えるかもしれません。

この結果、例えば、当初ボリュームの少なさから『育児』というカテゴリで発進したけれども、だんだんボリュームが増えてきて、子供別に記事を一覧したくなったときに、『タグ』が埋め込まれていれば、簡単に子供別にフィルターをかけることができます。

逆に、当初から、綿密に計画し、恐らく投稿が増えるにしたがってカテゴリの細分化ニーズが発生するであろうから、当初からカテゴリを細かく分けるという手法をとっていた場合、やってみたところ、思っていたほどボリュームが増えず、寂しいカテゴリが生まれてしまい、処分したくなるときがあるものです。こういった先の心配を軽減させる安心感を『タグ』は有しているともいえるでしょう。

また、子供と地域のプラレールイベントに行った場合など、『育児』カテゴリにかかわることだけれども、『趣味』カテゴリのプラレールにもかかわり、また『地域』のカテゴリでもあるという具合に、カテゴリ体系が複雑になります。従来から、『サブカテゴリ』の設定は可能であったため、この不満を解消することはできないことはなかったわけですが、あまりやりすぎると、複雑すぎてカテゴリの意味がなくなってしまいます。やはり、こういう複数の視点から区分する場合は索引的な使い方が便利でしょう。

タグに関する詳しい解説は、『小粋空間』及び『Movable Type テンプレート 無料配布』に譲ります。

但し、『迷惑トラックバック』に入っているトラックバックスパムのうちのいくつかについては、MTEntriesRecentlyPingedタグが反応してしまうようで、スパム先へのリンクは作られないのでまだましですが、『最近のトラックバック』の箇所に、意味不明に、記事へのリンクのみが出来上がってしまいます。

『迷惑トラックバック』を空にして再構築すると、この意味不明な記事へのリンクが無くなるのですが、早いときは1時間もたたないうちに新たなトラックバックスパムを受けて、同じ繰り返しとなるので、いたちごっこのようで悲しくなります。実害としては、例えば最近のトラックバックとして10件表示させるようにしていて、その10件が全てトラックバックスパムによって意味不明なリンクだけになってしまうことです。これの対策が見つかると非常にすっきりするのですが、今のところお手上げ状態です。

Googleのページランクのアルゴリズムが、ページランクの高いトップページからのリンクが多い場合、優良なサイトに認められたサイトであるので優良であろうという仮説から、多くのリンクを受けているサイトであることがページランクが上がる要素となっており、これにトラックバックが有効であった時代があったそうですが、Googleも馬鹿じゃないので、進化して、スパムを無視するアルゴリズムが形成されているはずです。そもそも、なぜこのような浅ましいことまでしてランクを上げることに執着するのでしょう。

何が目的かを見失ってしまっていると思います。ランクを上げることは目的ではなくマイルストーンでしょう。また、仮にサイトのランクを上げて、お金儲けにつなげるとしても、お金を儲けることもやはり目的ではなくマイルストーンのはずです。トラックバックスパムを集中的に行なって、ランクが上がったら大人しくして、信用のあるサイトとして振る舞い、愚者からお金を搾り取ろうとしているのでしょうか。仮に、お金を手にして自分の欲望を満たすことだけが目的であるとすれば、憐れんでしまいます。

あるいは、自分の主義主張を世の中の多くの方に理解してもらうことが目的であるとしたら、トラックバックスパムをすることが自分の主義主張に適っているのでしょうか。「トラックバックスパムは成功のための手段であり、問題は切り離せる」と思っているとしたら、あまりにも世の中を甘く見ているとしか思えません。

こうしたトラックバックスパムが日本人から来ていないようであることは私としては救いです。トラックバックスパムが全くの時間の無駄であり、潔くなく、卑怯であることを理解しているからだと信じています。

【2006/10/18追記】

禁止IPアドレスの設定を行うようにしてみました。
一つ一つちまちまと設定するのはあほらしいので、一括でできないものかと探してみましたところ、『AutoIPBanプラグイン』というのを見つけました。

設定画面に『禁止IPアドレス』タブが表示されていない人は、まず、『mt-config.cgi』に

ShowIPInformation 1

を入れてください。

ダウンロードしたAutoIPBan.plをMovable Typeのpluginsディレクトリにコピーするだけで完了です。

すると、迷惑トラックバックに表示されたトラックバックを全部選択して、『その他の操作』ドロップダウンリストボックスから『AutoIPBan』が選択できるようになっています。これを選択し、『Go』ボタンを押せば、選択したIPが全て『禁止IPアドレス』として一括登録されます。

ところで、禁止IPを設定した場合、悪意がない人も排除する可能性があります。その点は承知の上で、やはり必要ということであれば実施してください。

前者は、同居するユーザーによるWebサーバー上でのcgiの利用が膨大となったためで、後者は、やはり同居するユーザーによるDBサーバーへのトラフィックが膨大となったためで、サーバーが違いますが、結局のところユーザー数が増えすぎていることが原因でしょう。

表示が重いのを解決しなければ、訪問者も我慢の限界を超えて閲覧しに来てくれないので大きな問題ですが、この問題はロリポップを使用している限りどうしようもない問題なので、とりあえず脇に置いておいて、再構築時間の増大の問題を解決しようと思いました。

ということで、このままでは時間も無駄に消費されてしまいますし、投稿データが消えてしまうリスクもあるので、MySQLよりも調子が良いとうわさのSQLiteに移行を決断した次第です。

移行には、『Ogawa::Memoranda』さんの『Movable TypeのデータベースをDB間で相互にコンバートするCGIスクリプト』を活用させていただきました。

基本的に何も考えないで移行できますが、移行手順に関する私なりの留意点を述べておきます。

• ゲットした『mt-db-convert.cgi』をアップロードし、これをブラウザで実行すると移行前のパラメータが既に読み込まれています。但し、MySQLのパスワードが未入力になっていますので、『mt-config.cgi』からパスワードをコピペします。
• 移行後のパラメータはファイルのパスだけです。私が勘違いしていたのはディレクトリのパスを指定するのかと思っていたことで、最後に『/』を入れていたのですが、これが間違いでした。
• 例えば『./db』というように指定すると、mt-db-convert.cgiのあるディレクトリ上にdbというファイルが出来上がります。拡張子はありません（指定していないので）。これがデータベースになるわけです。
• 多少の警告メッセージのようなものが出ますが、気にしないでよさそうです。間もなく移行が完了します。
• 完了時に、『mt-config.cgi』のデータベース指定を書き換えるための代替案が提示されますのでそれを『mt-config.cgi』にコピペします。
• 『mt.cgi』を実行していつもどおりにエントリー等の編集が可能で移行に問題が無かったことを確認し、これまでのMySQLのデータベースを削除します（ちょっと勇気がいります）。やり方は、ロリポップであれば、『Webツール』の『データベース作成』を表示させ、『削除』ボタンを押すだけです。

【追記】

移行後の使用感ですが、再構築はかなり速くなった感じです。ページの移動もデータベースへのアクセスが短くなった分だけ多少きびきびした動きに感じられます。

なお、ディスク使用量が、51Mから54Mに３Mほどアップしました。つまり、MySQLでのデータベース使用分はカウントされていなかったことが確認できたわけですが、僅か３MをケチるためにMySQLを使い続けるのが馬鹿らしいと思うほどの快適さはSQLiteは提供してくれているようです。但し、自宅サーバーの方であれば、ユーザー数の増大によるトラフィックの増大がないと思いますので、MySQLの方が良いと思います。

【2006/10/19追記】

再構築時間を比較してみたところ、MySQLよりもSQLiteに軍配が上がりました。

なお、『mt-db-convert.cgi』で「MySQL→SQLite」の変換は一発でできましたが、「SQLite→MySQL」の変換は、何度もこけました。MySQLの方が重いことが分かりましたので、逆の変換をしようとする人は少ないと思われ、実害はあまりないかもしれませんが、ご報告しておきます。

早速申込を行ない、ロリポップのファイルをごそっとダウンロードし、そのままチカッパにアップロードしました。cgiファイル等のパーミッションを変更し、mt-config.cgiファイルの中で指定しているパスを書き換えて、mt.cgiを立ち上げました。

その後、設定とテンプレートで記載されているパス及びテンプレートのファイルのリンクパスをしこしこ書き換え、全インデックスファイルを再構築し、また、カウンター等のcgiファイルに記載されているパスを書き直して一応移行が完了しました。

ブラウザでの表示速度は、今のところ変わりがあるようには思えず、「通信回線の問題なのかな」と思ったりします。

まあ、お試し期間が15日間あるので、もう少し併行して使用してみてから、移行するかどうかの最終判断をしようと思います。

【追記】
再構築時間比較（306エントリ；17日21時前実行）
チカッパ（DB：SQLite）：４分５秒
ロリポップ（DB：SQLite）：３分55秒

通信回線による誤差があるのでロリポップが速いと断言できませんが、チカッパにしたからといってデータベース操作が速くなることはないようです。MySQLならサーバーのスペックによる違いが出てくるかもしれませんが、SQLiteにしている限り一緒の可能性が高いです。

【2006/10/19追記】
再構築時間比較（308エントリ；19日17時実行）
チカッパ（DB：SQLite）：１分43秒
ロリポップ（DB：SQLite）：１分54秒

前回と今回では実効命令した場所が違うので通信回線の太さが違うと思われます。また、前回は21時前、今回は17時前ということで、時間帯による混雑具合も異なると思われます。

再構築時間比較（308エントリ；19日19時実行）
チカッパ（DB：SQLite）：１分37秒
ロリポップ（DB：SQLite）：２分10秒

再構築時間比較（308エントリ；19日20時実行）
チカッパ（DB：SQLite）：１分03秒
ロリポップ（DB：SQLite）：１分20秒
チカッパ（DB：MySQL）：１分55秒

チカッパとロリポップでは再構築時間を比較すると、僅かにチカッパに軍配が上がるのかもしれません。一方、一度しかトライしませんでしたが、MySQLにDBを変換してやってみましたが、MySQLはチカッパにおいても遅いようです。

【2006/10/24追記】
再構築時間測定（316エントリ；24日１時実行）
チカッパ（DB：SQLite）：43秒

ロリポップとの比較は行なっていませんが、未だかつてロリポップでこれほどのサクサク間を味わった記憶がないので、チカッパ優位は確実と見て良いように思います。

ここで気になるのが、オーナー以外に書き込み権限を与えないとコメントやトラックバックがアップされないのではないかという疑問ですが、mt.cgi経由のcgiによる書き込みはオーナーとみなすようで、『644』でも問題無いようです。

しかし、MovableTypeは通常『666』のファイルを生成しますので、これでは、作ったたびにちまちまと属性変更するはめになります。

DBUmask 0022
HTMLUmask 0022
UploadUmask 0022
DirUmask 0022

を入れると自動生成されたファイルが『644』になってくれます。
数字の意味ですが、『777』から引く数ということですが、デフォルトが「0111」のようで、「777-0111=666」というのがデフォルトで、上記の記述をすることで「777-0111-0022=644」となるようです。

基本的に、MovableTypeをインストールした『mt』ディレクトリはパーミッションが最適になっているようなので、各レンタルサーバーの指定したファイル以外にいじる必要はないと思います。

『archives』ディレクトリ以下のファイルはほとんど全て『644』で問題ないはずです。カウンター用のcgi等、自分で導入したcgiファイルが利用するdatファイルなどは、そのcgiプログラムの仕様に従って下さい。

なお、『mt-config.cgi』はバージョン3.3から非常にすっきりしましたが、上記を含めていくつかの設定を付加しておいた方がよいようで、『MovableType備忘録』に詳しく説明されていますから、そちらをご参照ください。

というのは、『PHPで軽量化！』において$MTCategoryLabel$を利用したファイルの生成方法を説明したからです。

本日、文字化けファイルを作らない方法を知りましたので、そちらについては『PHPで軽量化！』の追記部分をご参照ください。

ここでは、せっかく文字化けファイルを生成しないで済むようになったにもかかわらず、過去作った文字化けファイルが消せない現象を解決する方法を提供します。

適当に『dell.cgi』というファイルを作り、そこに

#!/usr/bin/perl
system("rm -rf /home/sites/lolipop.jp/○○○/*.inc");
exit;

と記載します。
『#!/usr/bin/perl』の部分はサーバーによっては『#!/usr/local/bin/perl』の場合がありますので、他のcgiファイルの一行目を確認してください。

パスを指定している部分はフルパスで記載します。MovableTypeを利用している方であれば、設定を見ればすぐ分かるでしょう。

問題はファイル名で、文字化けしているので正確なファイルパスが記載できないのですが、私の場合、文字化けしているファイルは全て拡張子が『inc』でしたので、ワイルドカードの『*』で消しました。

この『dell.cgi』をcgiが稼動可能な『mt』ディレクトリあたりにアップロードし、属性を『700』とかに変更して実行ファイルとし、実行します。実行すると『500エラー』が出るかと思いますが、ちゃんと消えていますので安心してください。FFFTPで消えていることを確認したうえで、dell.cgiを削除してください。

データベースをMySQLからSQLiteに切り替えたことで、ロリポップのままでも不自由ない常態になったので、月額250円のロリポップから月額500円のチカッパに移行することがコストパフォーマンス的にどうかと悩みました。

速度的には、再構築時間が多少早くなるような気はするのですが、どちらかというと通信回線が空いているか混んでいるかの方が影響が大きいように思い、サーバーの能力の問題はそれほど大きくないように感じました。

レンタルされるディスク容量が250MBから500MBに上がり、更に１GBまで拡張できる余地があるのですが、今のところ60MBしか使っておらず、今後もファイルサイズの大きいデータを扱う予定も無いため、この点で魅力はあまり感じません。

複数のドメインを管理できるマルチアカウントマルチドメイン機能は確かに魅力ですが、今すぐこの機能を使うことはなさそうです。

ロリポップの転送量がいくつに設定されているのか分かりませんが、チカッパより低いことは確かです。となりますと、今後、NamePが写真を扱ったページを増やす、アクセス数が増加するということを見越すと、転送量１日１GBというのは、それによって今すぐ恩恵を感じることができなくとも、押さえておくべきポイントなのかもしれません。

さて、こうしたところを押さえた上で両者を比較して見ましたが、やっぱり結論が出ない、というか踏ん切りがつきません。それをある情報が決め手となってくれました。

それは、「チカッパ」という名称は、博多弁と「力いっぱい」から来ており、九州男児を表現しているという情報です。日頃、「ロリポップ」というナウでヤングな女性受けを狙ったレンタルサーバーを使用しているということに負い目を感じていた私としては、「男子たるものロリポップに安住するべきではない。チカッパこそ男の生きる道である。」と考えました。

ということで、まんまとpaperboy&co.の思惑通りになってしまった感がありますが、自分の判断に満足しています。

なお、チカッパの上位に当たるレンタルサーバーとしてハイスペックなヘテムルというのがありますが、こちらはクリエーター向けという扱いで、私なんぞには猫に小判です。

Web製作会社に入ってから、本格的にWebサイトの製作法を学ばれている稲盛はるなさんの奮闘記的な指南サイトです。