アップグレートして、テンプレートの初期化も行わず利用してるのですが、同じテンプレートが別名で作られており、かつ編集不能のテンプレートが出来てます。

正確には、編集は出来るけど編集結果が反映されないテンプレートが利用されてしまう、という症状。

上の画像はシステムテンプレートの状態。
名前は別名(意味は同じ)なのですが、以下のそれぞれが同じものとなってます。

• Comment Preview Template ＝ コメントプレビュー
• Dynamic Pages Error Template ＝ ダイナミックパブリッシングエラー
• Uploaded Image Popup Template ＝ ポップアップ画像

例えば「Comment Preview Template」を開いて、保存しようとすると「ブログに同名のテンプレートが存在します。」とのエラーが発生して保存する事が出来ません。
「Comment Preview Template」を開いたはずなのに、開いたもののテンプレート・タイトル名が「コメントプレビュー」に変化までしちゃってます。

ただ、この点は再構築マーク(緑のマーク)がついてるテンプレートを保存する場合には発生しないのでなんとかヨシって感じです。

• 保存不可×・・・Comment Preview Template
• 保存可能◎・・・コメントプレビュー

問題なテンプレートは・・・？

問題は、改変不可なテンプレートとして「Uploaded Image Popup Template ＝ ポップアップ画像」がある事です。

新機能である「アイテム管理」を使ってみようと思い、画像をひとつアップしてみました。
ポップアップさせると、例えばこの場合、アップした画像ファイルを表示させるためのHTML(PHP)ファイルが発生するのですが、このテンプレートが、
「保存出来ない Uploaded Image Popup Template の内容が適用されてしまう」
という点です。

先にコメントプレビューで例を出しましたが、こういった感じです。

1. 保存可能◎・・・コメントプレビュー
2. 「コメントプレビュー」を改変
3. ポップアップ用のテンプレートとして「Uploaded Image Popup Template」が適用されてしまう

つまり、ポップアップ用のテンプレートも、改変して保存する事は可能なのですが、それが本来適用される場面になると、保存する事が不可能なテンプレートの方が適用されて出力されてしまってる、って事です。

解決策は？

ずばり、今のところ判りません(´･ω･)ゞ⇒解決しました。

データベースの中で、ふたつのテンプレートの何らかのデータを入れ換えてあげたら出来るのかもしれませんが。。。今のところそこまで試そうかな？とは思わないので保留中。
何らかの方法が判ったら、その時にでもやってみようと思います。

まとめ

基本的にはファイルアップしてのイメージポップアップを使う事はないので、今のところ問題ではないのですが、改変して使う事が出来ないって点が引っ掛かってます。

あと、ひょっとしたらと思い、これもMT4の新機能であるブログコピーを使えば、ひょっとしてテンプレートの関連付けなんかがリセットされて直るかな？と思い試してみたのですが、ダメでした。

Sixapartさんに尋ねてみようかな。。。？

【追記】

phpmyadminを使って、Database内をテンプレート名で検索して、開いてるテンプレートIDを元にしてテンプレートを特定し、template_text 内を書き換えたら反映されました。

【追記その2】

触っていて思ったんですが、Database内のデータを直に書き換えても良いとは思いながらも、やっぱりアップグレードした後は、一度テンプレートは「初期化」を行った方が良いと思いますー。

以前に起こった出来事はこちら。
■お疲れさまでした - ブログシボウ発生

で、何が悪かったのかというと、
「MTFilterCategories で指定しているカテゴリー表記が悪かった」
のですね。
FilterCategoriesについては割愛しますが、簡単にいうとエントリーの表示をカテゴリー単位で指定・抑制出来るもの、です。
そして、カテゴリーの並び替えに話を移します。
カテゴリーの並び替えに関してはいろんな方法があるのですが、そのうちのひとつであるとある方法も試した事があります。

■カテゴリーのディレクトリ名と並び替えを調整する

この時変更した MTFilterCategories で指定しているカテゴリー表記をそのままにしていたために起きているエラーでした。

で、MTFilterCategories で指定して表示させているエントリーの内容は全部、他のプラグインを用いてる内容でして、そのため、フィルター指定も間違っててその中身で動作するはずのプラグインくんが「カテゴリー見つからないよ！」と言って動作を止めちゃってるのでした。
なので、表記をきちんと現状に則したものに変更したらエラーは出なくなりましたとさ。。。

同様の症状が発生してお困りの場合は、テンプレート内に記述の カテゴリー表記 なんかを再チェックしてみると良いかもです。
もちろん、保証はないしそれで確実ってわけではないですけど。

ちょこっとヒント

良く良く眺めて気付いたことがあったので、それについてもちょっと紹介。
MTには「DebugMode」なるものがあって、これは mt-config.cgi に下記の1行を追記すると有効になります。
「DebugMode 1」

これを有効にすると、管理画面の下の方にMT動作についての情報が出るようになります。全部じゃないです。少し。
それで、私はいつもこれを有効にして動作確認の一助として利用しているのですが、良く良く眺めてみると「あるプラグインの動作がおかしいよ！」と言ってくれてる気がしないでもない事があとから判りました。。。
もっと落ち着いてしっかり分析すればヨカタよ（泣

解決したから良いんじゃないの？

確かに解決したのは良かった。うん嬉しい。
しかし、これの解決に気付いたのは「新しく既存サイトをコピーコピーで作り終えた瞬間」でした。

PHP化してるので、モジュール単位に区分けしてあるパーツ部分を再構築してると新しく作ったのに同じエラーが！！
こ、これは・・・！？
で、そのパーツ内のMTタグやカテゴリー表記をチェックして気付いてしまった・・・というワケなので、非常になんというか・・・ね。

・・・・・(つω-`)

ま、せっかく構築したからまた何かの時に利用しよと思います。

気になる点

解決出来たエラーですが、これのおかしい点がひとつあるのです。
それは、同じ表記ミスをXREAに上げてる本番サイトでも行ってるのに、こちらではエラーが発生しない点。
なんなのでしょ。エラーは実は発生していたけど、ちゃんとサーバーの方で問題を切り分けてその部分だけ動作しないようになってた、とかなのかな？判んないけど。
とりあえずそんな風に思っておこ（ ´ω`）

あとがき

そんな感じで解決出来たには出来たのですが、結局はきっと、新しいコピーサイトでそのミスのあるテンプレートを再構築させるまでは気付かなかったんだろうなーって感じです。
とても良い経験になりました。

それを踏まえた上で、恐らく解決するであろうその時までのために、状況を記しておこうと思います。
先日動作テストを行ったMovableType Background Rebuilder Pluginについてはこちら。
■再構築をバックグラウンドで行ってくれるプラグイン

• XSASローカルサーバーで稼動
• XREAサーバーで稼動

■Junnama Online: MovableType Background Rebuilder Plugin(2).
新しくなって、動作結果等を出力してくれる仕様になってます。
こちらをDLして、前回同様ディレクトリごと MTルート/plugins の中に入れます。

設定は全てデフォルトのままで動作テスト

基本的に、先ずはローカルサーバーで動くもののみをXREAの方に上げてるんですが、今回はちょっとだけそっちにも上げてテスト。

ブラウザは下記にて。

• Firefox 2.0 (Portable)
• IE6.0，IEエンジンを用いるunDonut

XSASにての動作状況

プラグイン自体は、MTの方でちゃんと認識してます。設定も行えるし”動いてる”ように見えます。

＜再構築実験＞

1. アーカイブテンプレ別にバックグラウンド再構築
2. 「全てを再構築」でバックグラウンド再構築
3. すべてのブログを再構築

再構築ボタンは押せるのですが、前回は出ていた「再構築プロセスを開始しました」の表示が出ず。しばらくそのままにしておいたのですが、配布先の解説にあるような「完了結果」表示は出ませんでした。

これは何かおかしい？(･ω･)と思い、ファイルの更新状況を確認。
ここで、MTの私のローカルサーバー上でのファイル更新についてちょっと記述。ここでは、「再構築」と「保存」について書いてみます。
それには、
■「最近のエントリー」を記事の「更新日」順に並べるようにする
を例に出してみると私も説明し易いので、これをもとに動作の違いを書いてみる事にします。このサイトで用いてる「Recent Update」の仕様はこうです。以下は、そこに表示されてるエントリーの、更新を掛けた時の動作。

＜保存(エントリー編集画面にある保存ボタン)＞

• エントリーは上に繰り上がって表示されます
• 「ファイルの更新日」は書き換えられます

＜エントリー一覧画面にある「再構築」ボタン＞・・・チェックを入れて使用するボタン

• エントリーは上に繰り上がり「ません」
• 「ファイルの更新日」は書き換えられます

つまり、今回の実験の検証確認は「ファイルの更新日」をもとにしてます。すると、行ったバックグラウンドにより書き換えられるはずのファイル日時がそのままでした。一応、上記も踏まえてエントリーを再構築してみたのですが、その作業ではちゃんと「更新日」が変ってます。ということは、バックグラウンド・リビルドが動作していない可能性が高い、って事に気付きました。
ちなみに、「全てを再構築」に関しては、「通常の全てを再構築」を行うと、ファイルは更新されてました。(アーカイブ以下)

私の場合、過去にcgiファイルのperlパス内に「-w」が付いてるか付いてないかでも動作が変った事がありますので、そこも書き換えてみたりしたのですが、結果は同じでした。

XREAにてちょっとだけテスト

あまりにも気になったので、今回はXREAにもちょっとだけ上げてみました。
すると、動作はXSASの時と変りませんでした。FTPソフトにFFFTPを用いてるので、このソフトを通じて見える「ファイルの日時」に関しては、
(恐らく「更新日」が表示されてるとは思うのですが、「作成日」なのかはっきりとは知らないです)
変化が「ありません」でした。

あとがき

私の環境は色々と不備が多いと思うので、フィードバックとしてはきっと不適切。なので、もうしばらくテストしてみたりして、様子を見ようと思います。プラグインの作者さんの環境では動いてるんですよね。だから恐らく、何らかのこっちの悪い環境要素が働いてるんだと思います。ちなみに作者さんの環境は、

• Firefox1.5
• Safali2.0

とのコト。FF1.5で試したいけどどうしようかな・・・(´･ω･)
他の利用者の方のアナウンスとか、作者さんよりの続報を待つ事にしました。

[参考記事]
■Junnama Online: MovableType Background Rebuilder Plugin(2).

• テンプレートの変更が即座に反映されます
• 再構築の必要がなくなります(正確にはちょと違うけど)
• ディスク・スペースの消費を抑える事が出来ます

上記は利点ばっかりですが、今のとこ何も悪い点が浮かばないのでしょうがありません。
・・・テンプレート内でPHP関数であるreadfileやincludeが使えないとか？
・・・判んないから実行あるのみ。

ローカルサーバーはいつものXSASです。
MTサイトはリネーム＋丸々コピー。DBもリネームコピー。
MTのconfigファイルを開いて、DBの指定とサイトのパスを書き換えます。

• CGIPath
• DB指定部分
• StaticWebPath

新しいサイトにログインしたら、サイトの公開設定からURLパスやアーカイブパスを書き換えて、全て一旦再構築します。
前回導入した「バックグラウンドリビルド」が早くも大活躍です。静かで安心して作業出来ます。
私の場合はWidget内にreadfileを用いてテンプレートを読み込ませているので一苦労。。。だって全て書き換えないと(。。|||)

ここで注意するのは、WidgetManagerを用いてテンプレートを管理している場合、このWidgetを「一旦保存」する必要があることです。
これを行わないと、WidgetManagerで管理しているテンプレート部分はいつまで経っても前の状態のまま、になってしまいます。

ここまで済んで、新しいテストサイトが用意出来たらいよいよDynamic Publishingに挑戦です。
※htaccessファイルを置いてる場合は、バックアップ取って一旦削除しておいて下さい。(後述)

ダイナミック・パブリッシング用プラグインのDL・UL

■The blog of H.Fujimoto：再構築不要化カスタマイズ（MT3.3専用版）　[The blog of H.Fujimoto]
上記よりプラグインをDLしたら、
MTルート/plugins の中にディレクトリごとULします。

プラグインをULしたあとは、最初のログイン時にDBのアップグレードが促されるので、指示のままに従います。

ダイナミック・パブリッシング用プラグイン設定変更

設定→公開 タブ と進んで、「公開」部分にある
「テンプレート別に、スタティックHTMLもしくはダイナミック・パブリッシングを選択します 」を選びます。

次に、プラグイン タブ に進み「Dynamic publishing by Perl」の設定を表示させて、「初期化する」を選びます。
※ここで上記の「公開設定」を行ってない場合は、親切にその旨をお報せしてくれます。うーん・・・優しい(つまりドジった管理人)

＜初期化終了＞
一時ファイル用ディレクトリとキャッシュ用ディレクトリを作成しました。
mt-dynamic.phpのテンプレートを作成しました。
sqlsub_mysql.phpのテンプレートを作成しました。

Perl版ダイナミック・パブリッシングの設定

それぞれの設定を行います。
私は全てPHP化してるので、拡張子をphpに。
ページが見つからない場合の移動先ページも、用意していた404ページを指定してみました。
キャッシュ機能についてはとりあえず"使いたがり"なので指定。
キャッシュはどこに保存されるのだろう？(´･ω･) ←「phpcacheDir内でした」
初期設定ではキャッシュ10MB(10000000byte)。テストなのでこの数値も変更して5MBにしてみます。
設定を保存したら、Blogのメニューに戻ります。

テンプレートをダイナミック・パブリッシングに指定する

環境設定のテンプレートに進んで、ダイナミックパブリッシングしたいテンプレートを開いて、「ダイナミック・ページ」のチェックを入れます。
この段階で「再構築チェック」などが消えちゃいますが焦らず。ドキドキ
こうやって、各々のテンプレートをダイナミック・パブリッシング指定に変更して行きます。

全部終ったら、ブログ全体を一旦再構築します。

トラブル発生

ここまで一通りやったら、既存の静的ファイルは「～.static」と名前を変えて存在してます。
これは全部削除。

で、いざインデックスやその他アーカイブ内のURLにアクセスするも、404か403が出てことごとく失敗しました。
こんなエラーが発生するのはhtaccessのせいだろうと目星をつけつつ、手順確認。
プラグインの配布元によれば「初期化」の段階でhtaccessを書き換える、との事。
私はエラーとタグのURL短縮表示の制御をhtaccessで行っているため、この既存のファイルを確認してみると『書き換えが行われていない』。
ので、このファイルを消して再度：手順「設定変更」のところからやり直し。
今度はhtaccessが作成されて、URLにはアクセス出来るようになりました。

陥落

出来た出来たと喜びつつしばらく様子を見ていると、今度は
「キャッシュファイルのコピーに失敗しました」と表示がなされ、一切のアクセスが不可に。
・・・・・Σ(ﾟДﾟ)

幾度手順を確認しても、やり直してみてもウンともスンとも言わなくなりました。
DBに潜って、fileinfo辺りが怪しいと睨んでみてもどうにも出来ず。
ちなみに消してみたけどダメでした。
というワケで、ダイナミック・パブリッシングは「失敗」に終りました。

あとがき

ちょっとの間アクセスして画面が表示されてる時は楽しかったです＾＾
Wordpress(EUC)ではこの動的生成はちょっと体感していたのですが、Movabletypeでは動いてないテンプレート部分はどこなんだろう？とか、今までファイルが在っただけに、その箇所に何もないのに、ページが生成される、って動作が面白かったです。

それにしても「キャッシュファイルのコピーに失敗」かぁ。。。ディレクトリはちゃんと出来てるし、書き込めない制限なんてないハズなんだけど。
MTのD・パブリッシングが作用しちゃってるのか、Perl版が動いてるのかもはっきり判らず。
ApacheのログにはFeedのエラーが連綿と・・・って、えぇ！？
なんですかこれは(つω-`)

せっかくテンプレートの変更が即座に適用されるっていうので、これを用いてテンプレートの改変を行って、再構築せずに直ぐ適用確認！したかったのに。
無念(･ω･)

[参考記事]

■Movable Type 3.2 マニュアル - ダイナミック・パブリッシング
■Movable Type 3.3 マニュアル - ダイナミック・パブリッシング
■The blog of H.Fujimoto：再構築不要化カスタマイズ（MT3.3専用版）　[The blog of H.Fujimoto]

上記で配布のプラグインは、関連するエントリーを表示させてくれるプラグインです。
コンテナタグとして
＜MTRelatedEntries＞を使用します。

TagSupplementals.pl

■TagSupplementals Plugin.ja JP - Ogawa Code　[Ogawa Code]
を導入すると、使用出来るコンテナタグにMTRelatedEntriesコンテナタグが追加されます。

どちらかの使用を止める

• TagSupplementals・・・キーワード登録があって活躍します
• RelatedEntries.pl・・・キーワードの有無に左右されません

上記は使用する際の一基準として。

そのエラーの解決法です。

上記よりMTTagInvokeプラグインをDLして、

MTルート/plugins/MTTagInvoke/中身

という風にアップします。

MTルート/plugins/MTTagInvoke.plが入ってる場合は、削除します。

エラーの詳細について

以上

[参考記事]
■ＭＴ3.3でMTTagNameタグが閉じられていませんというエラー：商用ＢＬＯＧ専門店

[配布元]mt-keywords2tags.ja JP - Ogawa Code　[Ogawa Code]
上記よりDLさせて貰い、mt.cgiと同階層に入れてアクセスして実行。

※mt-cats2tags - Ogawa Code を使ったらどうなるんだろう？と思って試してみたら、上記にて行ったタグを、カテゴリー名で全て上書きされちゃいました。

• MT3.2時には、インプットするキーワードの区切り文字に「,(カンマ)」を使用していたのですが、今のところ問題なし
• アルファベット順にソートしてタグに変換してくれてる
• キーワードの区切り文字だった「,」が消えて「半角スペース」になっている
• タグの区切りが「,＋半角スペース」で出力されている

MT3.32のタグ機能

先ずは試しに表示させてみようと思い、MT3.32に入っているWidget機能を用いて設定してみたところ、まったく表示されませんでした。この辺りはまたぼちぼち、解消を探っていこうと思います。
ちなみに、MT3.32のタグ検索結果画面は、MTの検索結果画面と同じかも。と思って3.32のディレクトリの中を覗いていたら
MTルートディレクトリ/alt-tmpl
の中って空っぽなんですがこれはこれで良いのだろうか・・・。って思ったらこの中身ってBigTemplateで使われてるディレクトリじゃないか（泣

それからこちらのエントリーにて、Tagwire+mt-xsearchとタグの違いをとても判り易く述べてらっしゃいます。
■greenplastic.net: 未だにMT3.3へ移行できない理由
とてもためになるのでリンク記述。コメント、リンク先共に併せて要チェックです。

[参考記事]
■TagSupplementals Plugin.ja JP - Ogawa Code　[Ogawa Code]
■カイ氏伝: Movable Type 3.3へのアップグレードからタグクラウド設定まで

2006/11/02 04:48:49：記事書き直し

MTルートディレクトリ/lib/MT/Util.pm
を修正します。

サイトで起きた問題

1. テキストエリアを中央寄せにしようと思い、align=center でエリアを括ったところ、Textarea内で改行タグが発生
2. pre，code を用いた場合、レイアウトが崩れてしまうので使えず。この点はまた調査という事で、やっぱりTextarea記述に戻す
3. 行数はその都度指定しているため、上記ファイル修正では追いつかない
4. align=center を外す
5. 解消

pタグが入ったり、改行タグが入る点に関してはもうちょっと勉強しなくてはなりません。。。

参考記事：
■小粋空間: エントリーにpタグとbrタグが入る仕組み（その3：textareaにbrタグを挿入しない）　[小粋空間]
■小粋空間: エントリーにpタグとbrタグが入る仕組み（その2：blockquoteにbrタグを挿入）　[小粋空間]

関連記事：
3.32 → 3.2 へダウングレード
3.2 → 3.32 へのアップデート

●以前のMTは、必ず残しておく
1.MTをリネームしておく。又は新しいMTを別ディレクトリに入れる
　こうする事で、以前の「MT部分に関しては」楽に戻せます。

2.データベースのバックアップ
　データベースをdbディレクトリに保存するタイプ、SQLite，BerkleyDBの場合は、もうMTディレクトリをそのままDLしておきましょう。

　phpmyadminを用いる際には、文字コードを変更しないように注意。デフォルトではUTF-8ですね。

複数のデータベースが利用出来る場合は、同じものを用意して試験的にやってみるのも良いかもです。アップグレードを行うと、データベースはMT3.3用になっちゃうので、以前のバージョンでは使わない方が良いと思います。アップグレードの際に、以前のテーブルを食い潰すようでなければ、そのままいけるかもしれませんが。。。

●mt-static ディレクトリ
このmt-static ディレクトリですが、サーバーやその他の要因でデフォルトの
MTルートディレクトリ/mt-static の場所ではきちんと作用してくれないことがあります。あとはcgi-bin ディレクトリにMTを入れなくちゃならない場合とか。
それを改善するために、ブログのindexと同階層にこれをコピー(Copy又はMove)して使ってると思いますが、こちらのバックアップも忘れないようにしましょう。

これを戻しておかないと、ダウングレードを行った際に、MTを戻してデータベースも戻したのに、管理ログイン画面がなぜか3.3仕様、Version表記は3.2という妙な具合になっちゃいます。ログインは出来るのですが、そのブログ一覧画面にエントリーの画面表示設定か、エントリー一覧の表示設定部分が出てきます。
(スクリーンショット取り忘れが残念)
テンプレート画面も開く事が出来ませんでした。他にも幾点かおかしな動作があったと思います。なので、アップグレードの際もダウングレードの際も、このディレクトリは要注意です。

これに気付くまでに実は、けっこうな時間を要してました（泣
何回もデータベース入れ替えてみたり、MTもConfigを見直したりとか。とにかく、これでダメだったらもう諦めよう・・・という直前まで逝きかけた時、ふと中身を思い出したのが良かったです。

MT3.3にアップグレードする際は、一通り中身を見比べておくと良いですね。
(目を通しておいてほんと良かった・・・)
この3.32仕様のままだったディレクトリをもとの3.2の中身に入れ替えたら、無事3.2が3.2として稼動しました。

●プラグイン
たいていのプラグインは、*.pl ファイルを plugins ディレクトリに入れるタイプですが、中にはMTの php/plugins の中に追加しなければならなかったり、extlib ディレクトリの中に入れなければならないものもあります。
アップグレードの際には、こういったファイル・ディレクトリも忘れないようにしましょう。

ちなみに、MT3.32にアップグレードして再構築を行っている最中に、
「Can't locate bradchoate・・・」
というエラーが出て止まってしまう場合には、
MTルートディレクトリ/extlib/bradchoate
存在しないために起こるエラーなので、以前にそこにディレクトリを作った憶えのある場合は、それを同じようにアップしてあげましょう。私の場合はこのディレクトリ内に catx.pm ファイルを入れてました。忘れててごめんね。

MTルートディレクトリ/php/plugins を使うプラグインには、MTBogrollプラグインなんかがあります。

●3.32のTag と Tagwire＋MT-Xsearch(TagX)
3.2では埋め込んだキーワードをタグとして利用していたのですが、3.3ではタグ機能が実装されました。そのために不要といえば不要なのですが、個人的には残して使いたかったので、出来れば両方実装の方法を探りつつやってました。

・アップグレードした際にどうなったか？
　再構築を施すとタグ(正確にはキーワード)は表示されたのですが、これをクリックしても検索結果がひょう・・・・・

と、ここまで書いてひとつ思い出しました。
MT-Xsearchプラグインって確か、先に述べた extlib ディレクトリ使ってましたよね？
MTルートディレクトリ/extlib/MT/XSearch.pm
はいありました。。。（泣

というワケでここまで。
先ずはローカルMTで試してみようと思います。
うまくいくと良いなぁ・・・・・今度は(´-ω-`)

2006/10/25 21:33:04：記事書き直し
2007/01/31 22:29:14：記事書き直し

MTの削除

MT3.32を削除します。
私の場合は以前と異なるディレクトリにインストールしていたので、削除してしまえばそれで良いですね。
以前と同一のディレクトリに入れてる場合は、削除してリネーム保管していたもとのMT3.2を戻しましょう。

それから、「mt-static」ディレクトリも元に戻す事を忘れないように。
3.3と3.2では中身全然異なります。これが残ったままだと大変な目に遭います。遭いました。これについては別エントリーにて。

データベースの復帰

バックアップしていたもとのデータベースを戻します。
＜phpmyadminの起動＞

1. 「データベース」
2. データベースの選択
3. 上段メニューの「SQL」を選択
4. 「参照」からバックアップしていたデータを選択して「実行する」

再構築

特に意味はないかもしれませんが、3.32で構築したサイトファイルは全て一度削除しました。それから全てを再構築。
インデックスファイルと共に構築されないようにしていたファイルはひとつひとつ構築。
再度3.2の再構築により出力されたサイトの動作を確認して終了です。

以上

2006/10/20 22:24:38：記事書き直し
2007/01/31 22:30:48：記事書き直し

phpmyadmin でデータベース内部を覗くと、ログイン情報やその他のデータは亡くなってなかったので、その場合についての記述になります。

[配布元]MT Extensions: MT-Medic 1.34
上記より MT-Medic をDL

使用準備

ファイルのUL

mt-medic.cgi を mt.cgi と同じ階層にアップして、実行権限を与えたのちにアクセスする

設定のリセット・やり直し

正常にアクセス出来たら、今回はログインに関しての問題なので、Authors の項目にアクセスする。
すると、DBに残っている投稿者が表示されるので、 Edit から登録情報をやり直す。
パスに関しては、とりあえず別の簡単なものを設定してみて良いかもしれません。(例：0123)
私は以前と異なる簡単なパスをとりあえず入力して試しました。
正常に回復したあとに、再度MTの管理画面でパスの設定を行うようにしましょう。

また、私は管理用と投稿用の2つのアカウントを登録していたのですが、そのどちらとも mt-medic.cgi 上で設定し直しました。

この書き換える段階ではエラーが出なかったので、もしこの段階でエラーが出るようであればその対処については不明です。
エラーメッセージをもとに調査してみましょう。

情報を入力して、正常に出来たことを伝えるメッセージが出たら、きちんと Logout して抜けます。

mt.cgi にアクセス

mt-medic.cgi にアクセスして書き換えた際のパスを用いてログインを試みる。
回復出来ていれば、正常にログイン出来ます。
あとは再度パスの設定を行い、バックアップを取って終了。

以上

今回はログインに関してのリカバリーだったので、Authors の項目のみを触りましたが、他のpluginなどに関して問題が発生した際にも、このMT-Medicは役立ちそうです。

参考記事：
■コメントが、リビルドが、ログインが出来ない？！(MT-Medic.cgi等）　（CROSSBREED クロスブリード！）

2006/10/20 23:07:59：記事書き直し
2007/01/31 22:47:04：記事書き直し