2008年10月 Archive

ブログを３つ抱えているので話がややこしいですけど、『ユーティリティ』モジュールのキャッシュを外してから、初めて『家庭内外暴露日記』の再構築をしてみました。何度も書いていますが、エントリー数が3000以上です。

結果、エラー(ToT)。
最後まで終わらずに、止まってしまいます。『ブログ記事アーカイブ』だけにしても同じ結果です。

「MT4.2になって、さらにキャッシュ機能を追加して、再構築が30分ほどになったー！」と書きましたが、これは『カレンダー』をキャッシュしていた効果だったようです。どのページにもキャッシュしたタイミングのカレンダーが表示されていてはカレンダーの機能を発揮していないってことで、前回キャッシュを外したら・・・この有様です。

どうやらもう少し細かくカスタマイズしていく必要があるようです。

まず、現在使用させてもらっているmt.Vicunaの『カレンダー』ウィジェットでは、3つの条件分岐がされています。
トップページと、月別(僕は日別とか週別を使っていないので)と、個別ページに表示させるカレンダーです。

ブログとしての体裁を考えると、個別ページには『カレンダー』は要らないでしょう。トップページと、月別ページには欲しいので、個別ページに関する条件分岐を削除しました。
これで、個別ページにはカレンダーは生成されません。

ところがこれでも『ブログ記事アーカイブ』の再構築は成功しませんでした。

何と、まだ重いですか。処理が多すぎますか。

そもそも個別ページの意味とは・・・というところから考えました。
「個別のページが見たい」
そのまんまですがな。けど、やっぱり、そうでしょう。後はコメントするとか。

ならば、ここに『最近エントリーされたサムネイル画像』や『月別アーカイブリスト』なんかは不要でしょう。ってことで、どのページにも生成されるようになっていたこの２つのウィジェットのコードをちょっと加工して、個別ページでは生成されないようにしました。

そして・・・やっと、再構築成功。30分弱で終わりました。
なるほど、個別ページはダイエットが大切なんですね・・・再構築すると3000以上のページに対して処理するワケですから。

これは・・・どういうことや？
ひょっとして、ブラウザが前の情報をキャッシュしていて、それが表示されてるのかな？

慌てた僕は、FTPでトップページのhtmlファイルをダウンロードして内容を確認してみました。やはり、「カレンダーが表示されないよう。」は残っています。もう一度『カレンダー』ウィジェットの中身を確認すると、オリジナルのコードがちゃんと保存されていて、そんな情けないコメントは影も形もありません。

ここへきて、ド素人の僕はようやく気付きました。

そうか。キャッシュか。

デフォルトだと『サイドバー』というようなモジュールがあると思いますが、mt.Vicunaだと『ユーティリティ』というモジュールがあって、そこでサイドバーの部品を配置しています。
MT4.21にアップグレードして、さらにキャッシュという再構築を劇的に速めてくれる便利な存在を知って、僕はこの『ユーティリティ』モジュールもキャッシュするように設定していました。

なぜなら、コードに条件分岐のような動的なコードがなかったからです。
ところがよくよく見てみると、
<$MTWidgetSet name="サイドバー(ナビゲーション)"$>
という記述があり、さらにその中で『カレンダー』ウィジェットが使われているワケです。『カレンダー』ウィジェットには条件分岐のコードが含まれていますので、どうもこれが問題だったようです。

『ユーティリティ』モジュールのキャッシュを外して保存し直し、さらに再構築をかけると、やっと正しいカレンダーが現れてくれました。

はああ、まいったまいった。
けど、こういうアホな失敗を重ねて、ド素人は少しずつのったりと成長していくワケです。

不具合は月が変わった瞬間に起きました・・・いや、もっと前から起きていたのかも知れませんが、僕がそれに気付いたのはその時でした。
月が変わったのに、トップページのカレンダーが前月のものになっている！

ワケも分からずにいじくっていると、そのうちにカレンダー自体が表示されなくなりました。3つのブログ全部で。
『カレンダー』ウィジェットのコードを見てみましたが、よく分かりません。当たり前です。内容なんぞ理解せずにそのまま使っているのですから。

さらにいじくったり再構築を繰り返しているうちに、『最近のエントリー』の表示もおかしくなってしまいました。一番古い記事から表示されています。

一体、何が起こってるんや！？MTのバグ！？

問題が起きるとすぐに他人のせいにする悪いクセです。
とにかく、分からないながらもコードをもう一度よく見てみると、2行目に、
<MTIf name="tempName" eq="index_main">
という記述がありました。テンプレートの名前が「index_main」だったら以下の指示に従いなさい、という条件分岐ですね。

ですので、いっそのこと『カレンダー』ウィジェットを、
<MTIf name="tempName" eq="index_main">
カレンダーが表示されないよう。
</MTIf>
と書き換えて保存し、再構築してみました。

ちゃんと、トップページのカレンダーが割り当てられている部分に情けないコメントが表示されました。MTはちゃんと動いているようです(当たり前か)。

『カレンダー』ウィジェットを元のコードに戻し、また再構築してサイトを確認してみると、恐ろしい現象が僕を待ち構えていました。

トップページのカレンダーのエリアには相変わらず「カレンダーが表示されないよう。」と表示されていたのでした。

ちょっと前の話になりますが、どうやら問題はテンプレートではなかったようです。
3つあるブログのうちの2つをVicunaさんのテンプレートにしたのですが、やっぱりカレンダーの不具合は発生しました。

ブログAに10月1、2、3日の投稿があり、カレンダーにもその三日間のリンクが生成されているとします。
同じテンプレートを使っているブログBで、10月5日に投稿すると、ブログBのカレンダーがブログAのカレンダーになる、という現象でした。

なかなか分からなかったのですが、やっと見つけました。
WingMemoさんのページに書いてありました。もう2年近く前の記事ですやん(^-^;)。

問題は<$MTEntryLink$>にあったようです。キャッシュだかCookieだか、とにかく最新の情報を持ったまま投稿したブログの方にその情報が引き継がれる・・・ってことなんですかね。
WingMemoさんにはこう書かれてあります。

日別アーカイブへの飛ぶ先を<$MTEntryLink archive_type="Daily"$>などのタグにすると、ダイナミックで複数ブログを運営している場合、違うブログのエントリーへ飛ぶことがあるので、それを防ぐため<$MTBlogURL$>?でhttpから始まるフルアドレスで指定するようにしています。

これ、これ。この現象で困っていたのですヨ。
僕の場合、ブログ記事のアーカイブマッピングは『2008-10/20081005.html』というファイルが生成されるように設定していますので、リンク先をこのように変えました。

<$MTBlogURL$><$MTArchiveDate format="%Y-%m/%Y%m%d"$>.html

言ってみれば“力ずく”のワザですが、この際贅沢なことは言ってられません。
いつもお世話になっている小粋空間さんにはAjaxだの何だのと難しい対処方法が解説されていましたが、ド素人の僕に理解できるハズもなく、これで満足です。

さて、ここまで来てもやっぱり分からないことがあります。
『家庭内外暴露日記』の古い方の記事、こんな具合になっています。

それぞれの記事は<p></p>で括っているのですが、このタグを書き忘れている場合、上の記事のように、ちゃんと書いている場合は下の記事のようにちゃんとインデントされて表示されます。
旧サイトの記事をせっせと登録している時に、一部の記事ではタグを書き忘れたようです。
実際には書き忘れたのではなくて、"フォーマット：なし"で登録したのかも知れません。リッチテキストで書くと自動的に挿入されますので。

なので、上の記事のようになっている場合は、個別の記事に行って、<p></p>タグを入れて再構築する、という面倒な作業をしなくてはいけません。そんな昔の記事は誰も読まないのでほっといてもいいんですけど・・・A型としては気になります(^-^;)。

ところが、この作業中、変な事象に遭遇しました。
個別記事を見るとちゃんと<p></p>タグが記事の前後に書かれているのに、ページの表示は上の記事のようにインデントされていない表示(＝タグがかかれていない場合と同じ表示)になっている記事があるのです。

『ブログすべて』を再構築しても、『ブログ記事アーカイブのみ』を再構築しても直りません。唯一、個別記事を再構築した時だけ、直ります。

これは一体、どういうことなんでしょう？

さすがにこればっかりは原因不明です。アップグレードの時にごちゃごちゃと色んなことをしたのが原因なのかも知れませんが、分かりません。

仕方がないので、記事を一つ一つ確認して、表示がおかしい記事のみ、ちまちまと再構築している次第です。
はああ。

MTとmt.Vicuna(ブログのテンプレート)をアップグレードしたところで一段落ついたのですが、その後、管理画面から『テンプレート一覧』を見るとMT4.1とは違った点があることに気付きました。

何しろ、MT4.21にアップグレードしたとは言っても、参考書も買わず、MovableTypeのサイトを見ることもなし。つまり、てきとーに手探りでいじっているという体たらくです。分からないことや不具合に遭遇した時だけウェブで調べるという感じ。

で、気付いたのは『キャッシュ』でした。これは・・・何？

ここでやっとMovableTypeのサイトを見てみると、「MT4.1XからMT4.21にアップグレードしただけで処理が速くなり、さらにキャッシュ機能を使えばもっと速くなる！」ってなことが書かれていました。

なぁるほど、そういう便利な新機能があるのかー。

が、ちょっと躓きます。色々調べてみると、どこもかしこも「phpでうんたらかんたら」という記事ばかり。
phpに関する知識と言えば「アクセス時に動的にページを生成する」ってことくらいです。phpの記述も知らないし、負け惜しみを言えば「静的ページに拘りたい」と思っていてphpについては勉強も導入も考えていません。

phpじゃないと、キャッシュ機能はその効果を発揮しないのかなあ・・・けど、とにかく一度やってみよう。

ということで、『設定』→『公開』で、『モジュールオプション』の『モジュールのキャッシュ』にチェックを入れます。『サーバーサイドインクルード』は『無効』のまま。これで、保存。

さて、エントリ数が多い『家庭内外暴露日記』はアップグレード前、MT4.1で『ブログ記事アーカイブのみ』で再構築して約8時間かかったと書きましたが、MT4.21にアップグレードしてからは以前と同じように途中でエラーになり、最後まで再構築が完了したことは一度もありませんでした。

なので、早速試してみました。条件分岐が含まれていないモジュールを選択し、下のほうの『テンプレートの設定』を開けて『作成または更新後に無効にする』と『ブログ記事』を選んで保存します――そして、再構築。

すると・・・30分弱で完了！！

そうですか、そうでしたか。MT4.21は、単にアップグレードするだけじゃなくて、キャッシュすることによってその爆発的な効果を発揮するのでしたか。phpじゃなくても効果あるんですか。
いやー、これまでの七転八倒を経て初めてMT4.21の恩恵に与りました。

ちなみに、キャッシュするのは内容が変わらないモジュールだけですからね。ここんところだけ、要注意です。

もう一度アップグレードした時のことをざっと思い出してみましょう。

1. MT4.21のファイルたちをFTPでサーバーにアップ、元のmt-config.cgiもアップ
2. 元々使っていたプラグインやスキンのテーマ関係をFTPでサーバーにアップ
3. この時、mt.Vicunaをバージョンアップ(ver2.2.0をプラグインに上書き)
4. ブログの一つ『迷曲探偵団』にて、mt.Vicunaのver2.2.0を読み込ませるために『ブログのテンプレートを初期化』→『mt.Vicuna 2.2.0』を選択

この時に自分のサイトを見てみると、元のデザインで表示されたため、「何か分からんけど前のモジュール類が引き継がれている！」と思ったのですが、そうではありませんでした。
翌日になって『迷曲探偵団』を見てみると、デザインがオカシイ。

そう、mt.Vicuna 2.2.0のデフォルトのデザインになっているのです。
他のブログサイトはデザインがそのまま引き継がれています。つまり、こちらはmt.Vicuna.2.1.4で自分がカスタマイズしたモジュール類が引き継がれているってことですね。

考えれば、当たり前のことでした。

• MovableTypeをアップグレード＝中身(テンプレートやモジュール類)は引き継がれる
• テンプレート(mt.Vicuna)をアップグレード＝モジュール類のコードがガラッと変わるので引き継がれない

けれど、せっかくmt.Vicunaをアップグレードしたのだし、サイトには「2.2.0になってミラクルパワーアップ！」なんて書かれているので、やっぱりこちらを導入したいってのが人情です。
モジュールやウィジェット間の見通しが良くなったということなので、ひょっとしたら再構築の処理速度も上がるかも知れません。

で、まずは『迷曲探偵団』のモジュール類を元のカスタマイズに合うように修正していきました。さらには勢いに乗って『家庭内外暴露日記』も。
これは数時間で完了しました。

さあ、再構築だ(こればっかし)。

で、結果として・・・やっぱり遅いッス。『ブログ記事アーカイブ』の再構築の遅さは尋常ではありません。
結論。エントリ数が3000を超えると(もっと正確に言うと3400ちょい)MTを最新版にしても、ステキなテンプレートを使っても再構築には莫大な時間がかかるってことです。

まさしく、骨折り損ですが・・・まあ、最新版を使っているという優越感っちゅーか、気持ちよさがあるのでよしとしておきましょう。

そもそも、全体の再構築ができなくなり、次に記事一つ分の再構築ができなくなり、ついには新規登録さえエラーで止まってしまうという事態に陥った末に、今回のMT4.21へのアップグレードを決意したのでした。

ですので、アップグレード後に一通りの基本動作を確認できたこの時点で、再構築をしてみることにしました。

まず、エントリ数が100前後のブログ。
これについては、格段にスピードが上がりました。1分もかかりません。これは、凄い。

そして、問題の『家庭内外暴露日記』。エントリ数3000以上を誇ります(笑)。
実は、アップグレード前に、つまりMT4.1で『ブログ記事アーカイブ』のみで再構築を実施したところ、途中で止まることなく無事に完了しました。

ちなみにその時のEntriesPerRebuildの値は「20」。「10」でも「5」でも途中で止まったのに「20」で成功とはこれ如何に。このエントリ数だと、こういう値よりもサーバーの調子に依存するのでしょうか・・・終わるまで8時間かかりましたが(^-^;)。

それで、MT4.21では思い切って『全ての再構築』をしてみました。
カテゴリや月別のアーカイブはなかなか速い。問題は『ブログ記事アーカイブ』の再構築です。
うーん、やっぱり遅い・・・・・・しかも。

途中でエラーになってしまいました。

あんれまあ、これではそもそものアップグレードの目的であった『再構築の安定化』が果たせていないではないですか。

MT4.1の時は『記事一つのみの再構築』も『新規投稿』もなかなかできなくなっていましたが、その点ではMT4.21はちゃんと処理してくれるので、アップグレードした価値はあったのでしょうけど。

ひょっとしたら、ブラウザの問題かな、と思って、いつも使っているIEではなくてFireFoxで試してみましたが、やはり同じアラートが現れて、新規投稿できませんでした。

ひょっとしたら、パソコンが悪いのかな、と思って、会社のパソコン、しかもIE6(家のはIE7)で試してみましたが、やっぱりダメ。

うーん、困りました。
そもそも、『FCKeditor』が使えないってのもしょんぼりです。便利だったのになあ。

待てよ・・・ひょっとしたら、MT4.21に対応していない『FCKeditor』があるからアカンのとちゃうか！？
ド素人の起死回生的なヒラメキでした。

mt-config.cgiに記載していた、

#======== RichTextEditor ==========
RichTextEditor FCKeditor

を削除してみました――すると。

見事に『フォーマット：リッチテキスト』でMTのメニューバーが現れました。FCIeditorに比べたら数段しょぼーいメニューですが、この時ほどこのしょぼさが愛おしく思ったことはありませんでした。

早速、新規投稿してみます。
『保存』ボタンを押しても、あのにっくきアラートポップアップも現れません。

そして、見事に新規投稿に成功しました！
誰もこんなトコロで躓いたりしていないでしょうし、ブログのソフトでブログの投稿ができるなんて当たり前のことなんですが、とにかくまあ、感激です。

これで、一通りのチェックが完了。
後は、再構築・・・か。

そう言えば、記事投稿時におかしなところがありました。
『リッチテキスト』にしても、メニューバーが変わらなかったのです。そもそも『FCKeditor』という、Wordのような入力補助をしてくれるプラグインを入れているのに、投稿画面にはそのメニューバーが現れていません。

ひょっとしたら『FCKeditor』がMT4.21に対応していないのかも・・・と思って、調べてみましたが、そういう情報を見つけることはできませんでした。

こーなったらフォーマットを「なし」にして投稿してやろう。

けど、『保存』ボタンをクリックすると、やっぱり『このページからほかのページに移動しますか?・・・』というアラートのポップアップが現れます。
キャンセルしても保存されずに元のページに戻るだけなので『OK』にするのですが、保存が終わって元の画面に戻ると、やっぱり記事の内容が消えています。

ああ、そっか。
アラートのポップアップはこう言っています。
『保存されていないエントリーへの変更は失われてしまいます。』
つまり、このポップアップが現れるって時点で、保存できないってことですよね。

はてさて、困りました。
『MovableType 投稿 できない』
と検索しても、目ぼしい情報は出てきません。なぁんも分かりません。

ここでアップグレード開始から3時間が経過し、夜中の1時半を回ってしまったので、寝ることにしました。

再構築もしていないのに、mtVicuna 2.2.0が適用されていて、サイトもちゃんと表示されているってのは嬉しいことでしたが、やっぱりちょっと気持ちが悪い。何でそーなったのかが全然ワカランからです。

が、よくよく見ると、フッターのところが『Powered by Movable Type 4.1・・・』となっています。
あれれ？もう4.21になっているハズなのに・・・と、ここで初めて再構築してみました。
すると、『Powered by Movable Type 4.21-ja』という表示に変わっていました。よしよし。

まだ各モジュールを良く見ていないので、どこかに修正しなければならないポイントがあるかも知れませんが、まず最初に試しておきたいのは『エントリ』です。つまり、『ブログ記事の新規投稿』です。
もちろん、ついでに「速くなった」と言われているMT4.2のスピードも体感してみたいものです・・・ってか、実は、先ほど再構築した時に体感したんですけどね。

早速記事を書いて投稿してみます・・・ホイ、『保存』ボタンをクリック――すると。
--------------------------------------------------------------
このページからほかのページに移動しますか?
保存されていないエントリーへの変更は失われてしまいます。
--------------------------------------------------------------
こんなポップアップが現れました。これは、MT4.1の時もちょくちょく目にしました。例えば、何かのモジュールのコードをコピーして、特に何もせずにそのまま他のページに移動しようとした時とか。

特に気にせずに『OK』ボタンを押しました。

さあ、投稿が始まりました。
おおお、ちゃんと数ヶ所のPING先にも更新情報が送られています。こういうのまで、アップグレード時に引き継がれているんですね、感激。

ところがページが元に戻ってビックリしました。
タイトルはそのままでしたが、記事の内容がないよう(シャレを言うとる場合か！)。

記事がまったく、真っ白です。
サイトを見てみると同様で、タイトルはありますが記事の中身がありません。

MT4.1の時は保存時にエラーで新規投稿できなくなり、MT4.21では保存されているように見せかけて中身を空っぽにする作戦ですか。

無事にMT4.21のインストール(アップグレード)は終了しました。

次に、MT4.1の時に使用していたプラグイン類のフォルダやファイルをxxx/cgi-bin/mt/plugins/に入れました。
それから、同じようにブログのテンプレート類もxxx/mt-static/themes/に入れました。

このタイミングで、前回失敗したmt.vicunaもバージョンアップしておくことにしました。
サイトから最新版をダウンロードしてプラグインのフォルダに上書きしただけです。

さて、自分のブログサイトを見てみると・・・コンテンツは表示されていますが、デザインがめちゃくちゃなことになっています。
つまり、何のテンプレートも適用されていないってことですね。

ド素人的に不安だったのが、「MTをアップロードした時に、何の情報が引き継がれるか」でしたが、ここで、テンプレートは引き継がれていないことが判明しました。

一応バックアップは取ってあるのでそんなに不安はないですが、もう一度テンプレートを初期化して、各モジュールを自分がカスタムした通りに保存し直していかないといけないとなると、気が滅入ります。

とにかく、『デザイン』→『テンプレート』→『ブログのテンプレートを初期化』に進んで、『新しいテンプレートセットを適用』から『mt.Vicuna 2.2.0』を選びます。

ここでもう一度自分のサイトを見てみると・・・あれ？ちゃんとしたデザインで表示されてる！
mtVicunaのアップグレードに伴って、モジュール類も変わったハズですので、それを一から調べなおして、カスタマイズしていかないといけないと思っていたのですが・・・。

仕組みはよく理解できていませんが、とにかくまあ、便利です。素人的には迷った部分は色々ありましたが、結局、ほとんど何もしていないですよね。
新しいファイルをサーバーにアップロードしたくらいです。

ここまでで2時間くらいかかりましたが、まだ終わりではありません(笑)。

アップグレード時に「方法についてはここを見てください」ってな感じでMovableTypeのページへリンクが貼られていたので、そこを見てみます。

手順は間違っていません。

途中、黄色い背景でこんなことが書かれています。
『スタティックディレクトリがアプリケーションディレクトリ外にあるときは、それにあわせて作業します』

意味が分からんっちゅーねん。本当にマニュアルって奴は素人に優しくないですね。

いや・・・ちょっと、待てよ――。
よく考えたら、名前を変えたxxx/mt-static_41/の方は何もアップグレードしていないのと同様です。

ダウンロードしたMT4.21の中身を見てみると、その中に『mt-static』フォルダがありました。これを、外に出さなければならなかったワケです。
「出さなければならない」と言うか、僕がMT4.1をインストールした時に――どういう理由か忘れましたが、ひょっとしたら参考書に書いてあったのかも知れません――外に出していたのですね。

ってか、MTのマニュアル、こういう風に書いてくれたらもっと分かりやすいのに。
『元々mt-staticフォルダをmtフォルダの外に設置している場合は、同様にしてMT4.2の中にあるmt-staticフォルダを外に設置してください』と。

“それにあわせて作業します”って言われたって何のことか分かりまへんがな。

まあ、気を落ち着けてmt-config.cgiの中を見れば、
StaticWebPath    http://xxx/mt-static
って記述があったんですけどね。そういう設定をしたことなんて忘れていましたよ。

とにかく、xxx/cgi-bin/mt/の中に入っているmt-staticのフォルダを外に出して、MT4.1の時と同じようにxxx/mt-static/として、もう一度ブラウザからxxx/cgi-bin/mt/mt.cgiにアクセスしました。

やっと、上手くアップグレードのインストール作業が始まりました(ToT)。

アップグレード作業そのものは簡単です。問題は、その後にちゃんとMTが動作するか、サイトが表示されるか、です。

色んなサイトにもっと分かりやすい解説がありますが、自分の備忘録なんで書いておきます。

まず、元々MTが入っているディレクトリ名を変更です。
つまり、いざという時に戻れるようにバックアップを取るって感じでしょうか。

僕の場合は、
xxx/cgi-bin/mt/以下にcgiファイルやフォルダ関係を入れ、xxx/mt-static/以下にmt-staticのディレクトの中身を放り込んでいたので、それぞれ『xxx/cgi-bin/mt_41』と『xxx/mt-static_41』に変えました。

で、ダウンロードしたMT4.21の中身を、新しく作ったxxx/cgi-bin/mt/ディレクトリの中にFTPでそっくりそのまま入れました。

次に、元々使っていたmt-config.cgiファイルをxxx/cgi-bin/mt/に入れて、ブラウザからmt.cgiにアクセスします。
ここから自動的にアップグレードが始まるワケですね。

ところが――。
アップグレードで失敗！！

『アップグレード』するのボタンをクリックすると、ページが切り替わって『アップグレード進行中』のような表示(記憶が曖昧です)が表れますが、何ともダサいデザインのページです。しかも、画像が『X』表示になっています。
実際のところ、進行しているのかどうかさえ定かではありません。

どうも、アップグレード作業自体が上手くいっていない様子・・・。
よく理解されている方は、上の手順の中で何が間違えていたのか、もうお分かりですね。

ところが僕はパソコンの前でアップグレード画面と同じように固まってしまいました。

まず、FTPでファイルたちをローカルに保存することから始めました。仮にMTが動かなくなっても、HTMLファイルやCGIファイル、画像ファイルを保存しておけば、いざとなればそれをUPすればいいワケですからね。

ところが、ここでも『家庭内外暴露日記』が大変。7000以上のファイルがあるので、これをFTPでローカルに落とすだけでも一時間半くらいかかりました。
よく考えると、以前は『日別アーカイブ』も生成するようにしていたのでその残骸も残っていました。もう要らんっちゅーねん。

次に、ブログのバックアップとデータベースのバックアップ。この辺は『XREAでMTを！』を参考にしました。
まあ、前にMTの再インストールをしたことがあるので、大体の要領は分かっていたつもりですが。

さて、念には念を入れて、アップグレード方法を調べます。すると、気になる記事をいくつか発見。
例えば、『HORNET's TALK..』さんのこの記事。

つまり、XREAのサーバーを使っている場合MySQLの文字コードがEUC-JPになっているがために、UTF-8でないとダメなMTだと文字化けが起こってはちゃめちゃなことになるようです。

いや・・・待てよ。
さっきもちらっと書きましたが、2ヶ月ほど前に、タグクラウドで日本語がきちんと認識されないとか「から（にょろっとした形）」が文字化けして「？」になるという問題に遭遇して、データベースの初期化をしました。その時にしたメインの目的が、MySQLの文字コード変更だったハズ。

早速、サーバーのサイトにログインしてみました。
文字コードは『EUC-JP』のまま・・・だから、2ヶ月前の作業後、うまくいかなかったのでしょうか。
けれど、PhpMyadminにログインしてみると、『MySQL の文字セット: UTF-8 Unicode (utf8)』となっています。
よく分からんけど、ちゃんとできているようです。

ならば、アップグレードしても大丈夫なんちゃうん・・・と、まだ躊躇している僕の背中を押す悪魔か天使がいます。
よぉし、気合だっ！

その後、どれだけの効果があるのか分かりませんが、

• mt-config.cgiにEntriesPerRebuild 10を追記
• MTタグの整理(MTLinkやMTBlogURLを極力排除、MTIncludeでのmoduleをfileに変更)

等、ネットからの情報で有効かも、と思われる対処法を試してみましたが、結局のところ一向に改善は見られませんでした。

改善が見られないどころか『ブログ記事アーカイブ』のみを再構築しようとしてもできなくなりました。途中で止まってしまうのです。EntriesPerRebuildの値を5にしても同じ。

これだけの量(エントリー数)だとやっぱり無理なんですかねえ。
EntriesPerRebuildの値を減らすってことは、それだけサーバーへの負荷は低減できるかも知れませんが、処理時間は莫大に長くなりますし(多分)。

で、いっそのことMTをアップグレードしようかと考えました。

使っているのはMT4.1ですが、MT4.2になると再構築の処理が高速化されるらしいのです。ただ、MT4.2だと『カスタムフィールド』周りがうまく移行されないバグがあるということで二の足を踏んでいたのですが、何のことはない、翌日にはデバッグされたMT4.21ってのが出てたんですね(恥)。

まあとにかく、こうなったら最後の手段です。

ドキドキですねー。
うまく行かなかったら、すべてがパァになるかも知れません。
まずは、バックアップを取らないと・・・って、これが大変。だって、色々やってますから。

• 『ぷらむずぶっく』：10年近く続けているサイトで、このたびMTでCMSのようなことをしようと、リニューアル中。
• 『家庭内外暴露日記』：『ぷらむずぶっく』内の日記のコーナーですが、MT上では別のブログとして構築しています。ここ最近再構築関係の話を書いていますが、このブログのことです。
• 『サイトリニューアル奮闘記』：このサイトです。MTを導入して、ついでにサイトをリニューアルしようと決意し、備忘録の意味を込めて始めたブログです。
• 『迷曲探偵団』：MTが面白くて「えーい、もういっちょサイトを作ってしまえ」と、メインの『ぷらむずぶっく』のリニューアル作業も終わっていないのに立ち上げたサイトです。

うーん・・・面倒だなあ。

そう言えば記事としては書きませんでしたが、ページ分割を導入した時に、総合のアーカイブページだけではなくて、『カテゴリーアーカイブ』のページも分割したんですよね。

それをどこでやったかというと、『アーカイブテンプレート』の『ブログ記事リスト』です。
詳しくは書きませんが、前に説明したやり方とほぼ同じです。

で、たまたま『月別アーカイブ』のページを見てみると、ページの下のほうに「1」という表示がありました。

これ、分割したページの1ページ目、という意味です。
が、分割は50の記事ごとと設定しているので、『月別アーカイブ』に分割は必要ありません。あ、一日にエントリー数を一つ、としていますので、最大でも31の記事数になるってことです。

しかも、単に「1」だけ表示されているってのもみっともない。

『ブログ記事リスト』では一つのテンプレートで『月別』と『カテゴリ』の両方のアーカイブページを生成しているのでこんなことになっているのですね。

そこで、ふと、考えました。
ひょっとしたら、再構築時に「よっしゃー、ブログ記事リストのテンプレートではページ分割の命令が出てますナ。ホイホイ、カテゴリーアーカイブのページは分割しましたでぇ。で、次は月別でんな。えーっと、50ずつで分割でんな。お？どれもこれも50も記事はありまへんがなー！！」的な処理をしていて、それが負担になっていないか、と。

だって、『月別アーカイブ』のページだけでも100以上ありますから、そのすべてでいちいち「記事が50以上あるか確認して、あったら分割、なかったらスルー」なんてことをしていたらそりゃーMTにとっても迷惑でしょう。

なので、『ブログ記事リスト』のコードをいじって、条件分岐させることにしました。
『カテゴリアーカイブ』の場合のみ、分割しなさいよ、と。
条件分岐が増えると負担が重くなる、という話を聞いたこともあるので、どうなるか分かりませんが、とりあえず試してみます。

ネットで色々と調べていると、やはりページ分割をすることによって再構築の時間が長くなるようでした。
ド素人の推測は当たっていたようですが・・・まあ、当たり前ですかね。ページ分割が再構築にそこまで影響あるとは予想していませんでしたが。

そもそも、エントリした記事が多すぎて、アーカイブページが長くなりすぎるのを嫌ってページ分割プラグインを導入したのですが、記事が多くなるにつれてページ分割が多くなり、再構築が遅くなって、しまいには再構築でエラー続出って、本末転倒ですよねぇ。

ここは、ページ分割を諦めるしかないか・・・。

いや、ちょっと待てよ。
考えてみれば、全ての記事を収めた『アーカイブ』なんてページは不要なんじゃなかろうか。だって、『月別アーカイブ』があるんだもん。
前にしていた通り、アーカイブのページには[最新50件]くらいでいいよなあ、うん、いいよね。

と、なると問題は『カテゴリーアーカイブ』。
日記サイトでは、ただでさえ記事数が多いので、カテゴリーまで多くするとこれまた再構築が大変だと思ってカテゴリーを3つに分けているだけです。

例えば、
プライベート (1225)
ってな感じ。ね、一つのカテゴリに1000以上の記事があるんですよ(笑)。

で、ここをクリックして『カテゴリーアーカイブ』のページに移った時に、そこに[最新50件]しかないとなると、それもまた不細工。
なので、『カテゴリーアーカイブ』のページのみ、ページ分割をすることにしました。

これで再構築の負担は激減したハズ。

この『サイトリニューアル奮闘記』もそうですが、 『迷曲探偵団』も、まだ始めてから数ヶ月ですのでエントリー数としては少ないのです。

ところが、どちらも新規投稿時に時々エラーが出るようになりました。
と、なると、これはエントリー数には関係ないのかも知れません。確かに、エントリー数の少ないブログの方がエラーになる確率は低いですけど。

じゃあ一体何が原因なんでしょう？

またしてもサーバーの不調なのでしょうか。
けど、調子が悪い時にはMTにログインするのにもかなりの時間を要したことがありました。
今は、そんなことはありません。しかも、インデックスページだけの再構築なら、すぐに終わります。

ひょっとして、つい最近導入した『ページ分割』のプラグインのせい・・・？

ド素人的な考えなので、何の根拠もないですが、新規投稿をする時や、あるいは一つの記事を再構築する際に、プログラムは月別のアーカイブやカテゴリのアーカイブまで見に行って「ありゃま、ページ分割のサインが出てますなあ。よっこらしょっと。えっと、50件ずつ分割するんですな。分割ページ全部を作り直さなあきまへんな」的なことをしているような気がします。

アーカイブのページの下のほうには、
1｜2｜3｜4｜5｜6｜7｜8｜9｜10｜11｜次のページへ>>
となっていますが、例えば各ページに10件ずつの記事を設定しているとして、

1ページ目：9月1日から9月10日まで
2ページ目：8月22日から8月31日まで
・・・

となっているところへ、9月11日に新規投稿をすると、これが全部ずれてきます。

1ページ目：9月2日から9月11日まで
2ページ目：8月23日から9月1日まで
・・・

という風に、アーカイブの全てのページを作り直さなければなりません。
前に『ページ分割プラグインを使うとindex_1.html、index_2.html・・・と、ページが自動で生成される』と書きましたが、僕のブログの場合はこういうページが60以上あります。

うーん・・・ページ分割、やめよっかなあ・・・せっかく成功したのに。
けど、やめると、『アーカイブ』のページにはずらーっと3000以上の記事が並ぶことになるんよなあ。

うーん・・・・・・。

昨日の記事は、何とか投稿できました。
なのに、日記サイト(何度かリンクしていますが『家庭内外暴露日記』ってヤツです）の方は投稿しようと思ってもエラーになります。

新規投稿がでけへんかったら日記サイトとして成立しません(ToT)。

ところが、色々とやっているうちに自棄になって『すべてのファイルを再構築』してみると・・・成功しました。もちろん、1時間以上かかりましたが、エラーになることなく終わりました。

一体、これはどういうことなんでしょう・・・？

さらに不思議なことに『すべてのファイルを再構築』してエラーなく終わっているというのに、結構古い方の月（例えば1999年3月分とか4月分とか）のいくつかの記事の表示がおかしいのです。どうも再構築がうまくできていないような感じ。

なので、表示がおかしくなっている記事のみを選んで再構築しようとしたらエラー。

どないやねん(ToT)。

新規投稿もできず、たった記事一つの再構築もできずって・・・。

MovableTypeを使っていて、再構築で失敗したことがない！・・・なんて方はほとんどいらっしゃらないでしょう。

特に僕の場合は、元々の旧サイトにある日記のコンテンツをぜーんぶデータベースに入れました。MTのブログ投稿画面で、えっちらおっちらと。

しょーもない駄文の垂れ流しであることは重々承知ですが、それでも10年近く続いているというその事実のみがちょっとばかしの誇りです。

ほぼ毎日、日記率98%を超えているので、投稿数は3000を超えます。
そうです。当然、再構築で失敗します。

かと言って、有効な手段を思いつかないド素人は、何度も挑戦するワケです。上手くいくときもあるので。

で、その日記のスキンを変更して、昔の記事の表示がおかしかったので、その記事のみ再構築しようとしたら、見慣れないメッセージと共にエラーとなりました。

CGIWrap Error: Real UID could not be changed!

何じゃこりゃあ？・・・と思って調べてみると、XREAを使っているとこういうエラーになることがあるらしく、原因は「一度にサーバーの許容量を超えるアクセスがあった際に表示されます」とのこと。

たった一つの記事を再構築するだけで何でそんなエラーが出るんじゃ！

そう言えば、このブログサイトの方は最近スキンを変更したばかりで、記事を投稿したことがありません。
試しに記事を投稿してみると・・・エラー！！
何とまあ、再構築どころか、記事の投稿もできないではないですか。

サーバーが原因なのか、記事が多すぎるのが原因なのか、僕が加えたコードにムダがあるのか、僕の日頃の行いが悪いのが原因なのか・・・不明。

さて、それではこの記事を投稿してみます。成功すれば、ブログサイトの方は記事が多すぎるのが原因だと言えることになります・・・多分。

しかしまあ、そうなると対処法がないよなあ。

元々は、

<dl class="headline">
<dt>タイトル１</dt>
<dd>記事内容１</dd>
<dt>タイトル２</dt>
<dd>記事内容２</dd>
・・・・・・
</dl>

という構成だったのが、

<dl class="headline">
<dt>タイトル１</dt>
<dd>記事内容１</dd>
</dl>
<dl class="headline">
<dt>タイトル２</dt>
<dd>記事内容２</dd>
</dl>
・・・・・・

となってしまったワケです。そのために、記事の間に微妙な隙間が生まれてしまいました。これはCSSを書き直す必要があります・・・が、色んなCSSファイルで構成されているこのテンプレートは「どこを書き直したらいいのか」を探すのが非常に難しい。

やっとの思いで見つけたのは「2-class.css」でした。さらに、そのファイルのどこをどう変えれば良いのか。
色々試して、何とか無事にできました。

dl.headline dd {
 margin: 0 10px 1em 10px;
}

の部分でした。ここの下部のマージンを規定する1emを0.2emに直して、やっと解決。

さらに微調整として、スカイアークシステムさんや、MovableTypeのススメさんで解説されていた記述をちょこっとだけ変更。

<$MTPageNext delim="次のページへ>>"$>

の前に「｜」を入れました。入れなければ、

1｜2｜3次のページへ>>

と、このように表示されるんですよね。index.htmlを表示している時に「3」をクリックしたら「index_3.html」に飛びますし、「次のページへ>>」をクリックしたら「index_2.html」に飛びます。なので、間違えてクリックしないように、分かりやすいようにしたワケです。

1｜2｜3｜次のページへ>>

と、なります。おっと、<$MTPageBefore delim="&lt;&lt前のページへ"$>の後ろにも忘れずに。
細かいところまで拘りますよぉ(笑)。

Continue reading

分割したいところに<$MTPageSeparator$>を入れるということは、ひょっとして<MTEntries></MTEntries>の間に入れるんちゃうか！・・・と思い、試してみると、見事にページが分割されました。

実際にどうなるのかというと、/archive/にはもともとindex.htmlがありますが、自動でindex_2.html、index_3.htmlというページが生成されるのですね。確かに、これは便利です。

ところが、まだ問題が残っていました。index_2.html以降のページを見てみると、表示がおかしい。
すぐに原因が分かりました。

「ヘッドライン」モジュールの元々の記述のせいでした。

<dl class="headline">
<MTEntries sort_order="descend" lastn="9999">
・・・・・・
</MTEntries>
</dl>

となっていたので、

<dl class="headline">
<MTEntries sort_order="descend" lastn="9999">
・・・・・・
<$MTPageSeparator$>
</MTEntries>
</dl>

のようにしたのです。つまり、<dl>タグの途中でページ分割してしまっているワケです。
これを解決しようと思ったら答は一つ。

<MTEntries sort_order="descend" lastn="9999">
<dl class="headline">
・・・・・・
</dl>
<$MTPageSeparator$>
</MTEntries>

こうするしかありませんでした。
けれど、まだ、微調整の必要がありました。

次回に続きます。

ブログの投稿数が多い僕としては、前々から気になっていたのです。それは、アーカイブページに記事がだらだらだらあっと並ぶこと。

 『家庭内外暴露日記』のアーカイブページは、一応なんてことをして記事数を制限していますが、本意ではありません。

そこで、ページを分割するプラグインを見つけました。配布先のスカイアークシステムさんでプラグインをゲットし、MovableTypeのススメさんでタグの記述方法を調べました。

が、動きません。さすが、ド素人です。参考のために、試したとおり書いていきます。

1.まずは、アーカイブページを生成しているモジュールを探すところから始めましたが、これはすぐに見付かりました。「ヘッドライン」というモジュールでした。
この中に、 というタグがあったのですが「9999件も要らんやろ。そもそもこのタグの前にという、20件ごとにページ分割するタグを記述するんやから」と、「lastn="9999"」を削除したのですが、これが間違い。MTEntriesの方でも記事数を規定しないといけないようでした。

2.困ったのは<$MTPageSeparator$>を入れる場所です。解説では「より前」とあったので、直前に入れました。こんな感じです。

</MTEntries>
<$MTPageSeparator$>
</MTPageContents>

ところが、これでもうまくいきませんでした。

次回に続きます。

昨日の夕方、やっとサーバーが復活しました。なので、このページのスキンを変更する作業が可能だったんですけどね。

さて、問題のサーバーってのはXREAです。サイトの表示は可能だったのですが、FTPとメールの送受信ができませんでした（僕の場合はメールを使っていないので、FTPが使えずに苦労したのですが）。

正味、三日間以上ダウンしていた模様です。

XREAのユーザー掲示板には「何とかしろ！」というクレームの嵐。確かに、何のアナウンスもないというのはいかがなもんでしょう。
せめて「ハードディスクの不具合により、対応中です」くらいの公式アナウンスがあっても良さそうなものです。個別に問い合わせをしたユーザーにはそういう内容の返信をしていたようでしたが。

しかしまあ、ユーザー掲示板に、「こういう返信がきましたよ」と書き込んでくれるユーザーがいて、他のユーザーがそれを見てある程度安心できるというスタンスは、これまでのXREAのやり方と何ら変わっていないような気もします。かなり、好意的な見方ですが。

サポートや情報交換のほとんどをユーザー同士でする、というのがここの方針なんですね。だからこそ、破壊的に安い。本当に、ちょっと考えられないくらい安いです。

僕の場合は趣味でウェブサイトを運営しているワケですから、レンタルサーバーにあんまりお金をかけたくありません。ウェブサイトに広告を貼ったりもしていますが、ほとんど収入なんてありません（これについては、後日書きます）。

ですので、今回のように不具合が起こった時にはグッとガマン(笑)。たまたまスキンを変更しようと考えていたタイミングだったのでFTPが必要でしたが、普段はほとんどFTPも使いませんし。
「仕事にならない！」と焦ったり、慌てて他のサーバーを借りてコンテンツを移転しようとしていたユーザーさんもいたようですが、僕から言わせたら「そんなに重要なサイトをXREAで作るからアカンねん」です(笑)。

もし僕が仕事でサイトを構築しなければならないとしたら、不具合が多くて、サポートや情報のアナウンスもほとんどないXREAを使うことはしませんね。
費用が高くついても、もっと信頼のおけるサーバーを借ります。

「安かろう悪かろう」の典型なので、こういうところをグッとガマンできるのであれば、通常に快適に動いている時は素晴らしくコストパフォーマンスのいいレンタルサーバーだと思います。
まあ、三日間のダウンというのはあまりにも長すぎますけどね。