アップグレートして、テンプレートの初期化も行わず利用してるのですが、同じテンプレートが別名で作られており、かつ編集不能のテンプレートが出来てます。
正確には、編集は出来るけど編集結果が反映されないテンプレートが利用されてしまう、という症状。
]]> おかしなシステムテンプレート
上の画像はシステムテンプレートの状態。
名前は別名(意味は同じ)なのですが、以下のそれぞれが同じものとなってます。
例えば「Comment Preview Template」を開いて、保存しようとすると「ブログに同名のテンプレートが存在します。」とのエラーが発生して保存する事が出来ません。
「Comment Preview Template」を開いたはずなのに、開いたもののテンプレート・タイトル名が「コメントプレビュー」に変化までしちゃってます。
ただ、この点は再構築マーク(緑のマーク)がついてるテンプレートを保存する場合には発生しないのでなんとかヨシって感じです。
問題は、改変不可なテンプレートとして「Uploaded Image Popup Template = ポップアップ画像」がある事です。
新機能である「アイテム管理」を使ってみようと思い、画像をひとつアップしてみました。
ポップアップさせると、例えばこの場合、アップした画像ファイルを表示させるためのHTML(PHP)ファイルが発生するのですが、このテンプレートが、
「保存出来ない Uploaded Image Popup Template の内容が適用されてしまう」
という点です。
先にコメントプレビューで例を出しましたが、こういった感じです。
つまり、ポップアップ用のテンプレートも、改変して保存する事は可能なのですが、それが本来適用される場面になると、保存する事が不可能なテンプレートの方が適用されて出力されてしまってる、って事です。
ずばり、今のところ判りません(´・ω・)ゞ⇒解決しました。
データベースの中で、ふたつのテンプレートの何らかのデータを入れ換えてあげたら出来るのかもしれませんが。。。今のところそこまで試そうかな?とは思わないので保留中。
何らかの方法が判ったら、その時にでもやってみようと思います。
基本的にはファイルアップしてのイメージポップアップを使う事はないので、今のところ問題ではないのですが、改変して使う事が出来ないって点が引っ掛かってます。
あと、ひょっとしたらと思い、これもMT4の新機能であるブログコピーを使えば、ひょっとしてテンプレートの関連付けなんかがリセットされて直るかな?と思い試してみたのですが、ダメでした。
Sixapartさんに尋ねてみようかな。。。?
phpmyadminを使って、Database内をテンプレート名で検索して、開いてるテンプレートIDを元にしてテンプレートを特定し、template_text 内を書き換えたら反映されました。
触っていて思ったんですが、Database内のデータを直に書き換えても良いとは思いながらも、やっぱりアップグレードした後は、一度テンプレートは「初期化」を行った方が良いと思いますー。
]]>
以前に起こった出来事はこちら。
■お疲れさまでした - ブログシボウ発生
で、何が悪かったのかというと、
「MTFilterCategories で指定しているカテゴリー表記が悪かった」
のですね。
FilterCategoriesについては割愛しますが、簡単にいうとエントリーの表示をカテゴリー単位で指定・抑制出来るもの、です。
そして、カテゴリーの並び替えに話を移します。
カテゴリーの並び替えに関してはいろんな方法があるのですが、そのうちのひとつであるとある方法も試した事があります。
この時変更した MTFilterCategories で指定しているカテゴリー表記をそのままにしていたために起きているエラーでした。
で、MTFilterCategories で指定して表示させているエントリーの内容は全部、他のプラグインを用いてる内容でして、そのため、フィルター指定も間違っててその中身で動作するはずのプラグインくんが「カテゴリー見つからないよ!」と言って動作を止めちゃってるのでした。
なので、表記をきちんと現状に則したものに変更したらエラーは出なくなりましたとさ。。。
同様の症状が発生してお困りの場合は、テンプレート内に記述の カテゴリー表記 なんかを再チェックしてみると良いかもです。
もちろん、保証はないしそれで確実ってわけではないですけど。
良く良く眺めて気付いたことがあったので、それについてもちょっと紹介。
MTには「DebugMode」なるものがあって、これは mt-config.cgi に下記の1行を追記すると有効になります。
「DebugMode 1」
これを有効にすると、管理画面の下の方にMT動作についての情報が出るようになります。全部じゃないです。少し。
それで、私はいつもこれを有効にして動作確認の一助として利用しているのですが、良く良く眺めてみると「あるプラグインの動作がおかしいよ!」と言ってくれてる気がしないでもない事があとから判りました。。。
もっと落ち着いてしっかり分析すればヨカタよ(泣
確かに解決したのは良かった。うん嬉しい。
しかし、これの解決に気付いたのは「新しく既存サイトをコピーコピーで作り終えた瞬間」でした。
PHP化してるので、モジュール単位に区分けしてあるパーツ部分を再構築してると新しく作ったのに同じエラーが!!
こ、これは・・・!?
で、そのパーツ内のMTタグやカテゴリー表記をチェックして気付いてしまった・・・というワケなので、非常になんというか・・・ね。
・・・・・(つω-`)
ま、せっかく構築したからまた何かの時に利用しよと思います。
解決出来たエラーですが、これのおかしい点がひとつあるのです。
それは、同じ表記ミスをXREAに上げてる本番サイトでも行ってるのに、こちらではエラーが発生しない点。
なんなのでしょ。エラーは実は発生していたけど、ちゃんとサーバーの方で問題を切り分けてその部分だけ動作しないようになってた、とかなのかな?判んないけど。
とりあえずそんな風に思っておこ( ´ω`)
そんな感じで解決出来たには出来たのですが、結局はきっと、新しいコピーサイトでそのミスのあるテンプレートを再構築させるまでは気付かなかったんだろうなーって感じです。
とても良い経験になりました。
エントリー内の本文部分のみ、スタティックにして、他のアーカイブで読み込めば、プラグインの改行設定でも大丈夫ですよ。
でもうまくいかなかったのですが、代りにMTの動作が”とても”早くなるという思わぬ収穫があったので、それも併せてメモです。
PHP化を施して、アーカイブに共通のエントリー内容を表示させてる場合はやってみると良いかもです。
私のサイトの場合はちょっと違うので、ここではエントリー・アーカイブとカテゴリー・アーカイブを例に用いてみます。
カテゴリー・アーカイブの場合は、エントリーの「<$MTEntryBody$>を表示させて、エントリー・アーカイブには「<$MTEntryBody$>+<$MTEntryMore$>」という形が少なくないのではないでしょうか。つまり、
は共通なワケです。そして、貰ったアドバイスと併せて考えると、
「<$MTEntryBody$>を(スタティック)ファイルとして作って、それを両アーカイブで読み込ませると良いかも」
となるのです。これならダイナミック・パブリッシングでも大丈夫かもしれない!?だってPHPのReadfile関数は動いてるから!!やったー!
上記を実現する為に、スタティックなアーカイブファイルを出力させて、読み込ませるようにしてみます。
「テンプレート→アーカイブ→テンプレートを新規作成」
次に「設定→公開→アーカイブ・マッピング」と進みます。「マッピングを新規作成」。
上記で生成されるファイルの出力フォーマットはそれぞれだとは思いますが、ここではエントリー・アーカイブと同階層に生成されるように設定してみます。そして、別ファイルになるように名前を変えてあげます。
これで、<$MTEntryBody$>の内容はエントリー・アーカイブと同階層に、異なるファイル名で生成される事になります。よって、個別アーカイブとカテゴリー・アーカイブで表示させている「<$MTEntryBody$>」は、このファイルを共通して利用する事が出来ます。
<$MTEntryBody$>をそれぞれのアーカイブで読み込ませるようにします。今まで<$MTEntryBody$>を書いていたのを削除して、以下のように変更します。アーカイブ用のディレクトリを使用してるので、ArchiveURLを書いてますが、これを利用してない場合は適宜置き換えてから。
●エントリー・アーカイブ,カテゴリー・アーカイブに以下を記述
ここでちょっと注意するのは、マッピングで書いた書式と、Date formatを用いての書式が多少異なる点です。
2桁表示の際に、ゼロをつけるかつけないかとか、時間は24時間表記なのかといった点で変ってくると思うので、その辺りを確認しつつやって行きましょう。
上記は「年・月・日時分秒」として出力してる例です。
これで、どこのアーカイブでもスタティックとして生成している「<$MTEntryBody$>ファイル」を使う事が出来ます。
XSASの場合ではちょっとだけ書式が変ってくるのですが、基本的には同じなので省略。
再構築して、エントリー・アーカイブでもカテゴリー・アーカイブでも、同様の<$MTEntryBody$>が表示されます。
ここまでが「動作が早くなる収穫」です。月別やカテゴリー・アーカイブでも<$MTEntryBody$>を記述して再構築したりしてみたのですが、上記までの方法を用いると、結局<$MTEntryBody$>は1回の構築で済んでしまうので、それぞれのアーカイブに<$MTEntryBody$>をそのまま記述するよりさっぱり早いです。
ここが肝心のところなのですが、出来ないでいます。
ダイナミック状態のページでは、MTArchiveDate formatがきちんと作用しないみたいで、そのため、ファイルの読み込みまでのパス指定がうまく行かず。。。さてどうしたものか。
ダイナミックの知識を増やして、そのうち改めて挑戦ですね。
あとちょっと・・・というのが現状かな。もうひとひねりで出来そうな感じがしないでもないんですけど。スタティックな時と同じ状態まで持っていけるのは、まだまだ先みたいです。他にも問題は溜ってるし。
で、ようやくアーカイブ・マッピングについて役割というか、動作の意味合いが判って来た感じです。これを利用する事で、何か面白い事は出来ないかな?出来たら良いけど
・・・(・ω・)フゥ
それを踏まえた上で、恐らく解決するであろうその時までのために、状況を記しておこうと思います。
先日動作テストを行ったMovableType Background Rebuilder Pluginについてはこちら。
■再構築をバックグラウンドで行ってくれるプラグイン
■Junnama Online: MovableType Background Rebuilder Plugin(2).
新しくなって、動作結果等を出力してくれる仕様になってます。
こちらをDLして、前回同様ディレクトリごと MTルート/plugins の中に入れます。
基本的に、先ずはローカルサーバーで動くもののみをXREAの方に上げてるんですが、今回はちょっとだけそっちにも上げてテスト。
ブラウザは下記にて。
プラグイン自体は、MTの方でちゃんと認識してます。設定も行えるし”動いてる”ように見えます。
<再構築実験>
再構築ボタンは押せるのですが、前回は出ていた「再構築プロセスを開始しました」の表示が出ず。しばらくそのままにしておいたのですが、配布先の解説にあるような「完了結果」表示は出ませんでした。
これは何かおかしい?(・ω・)と思い、ファイルの更新状況を確認。
ここで、MTの私のローカルサーバー上でのファイル更新についてちょっと記述。ここでは、「再構築」と「保存」について書いてみます。
それには、
■「最近のエントリー」を記事の「更新日」順に並べるようにする
を例に出してみると私も説明し易いので、これをもとに動作の違いを書いてみる事にします。このサイトで用いてる「Recent Update」の仕様はこうです。以下は、そこに表示されてるエントリーの、更新を掛けた時の動作。
<保存(エントリー編集画面にある保存ボタン)>
<エントリー一覧画面にある「再構築」ボタン>・・・チェックを入れて使用するボタン
つまり、今回の実験の検証確認は「ファイルの更新日」をもとにしてます。すると、行ったバックグラウンドにより書き換えられるはずのファイル日時がそのままでした。一応、上記も踏まえてエントリーを再構築してみたのですが、その作業ではちゃんと「更新日」が変ってます。ということは、バックグラウンド・リビルドが動作していない可能性が高い、って事に気付きました。
ちなみに、「全てを再構築」に関しては、「通常の全てを再構築」を行うと、ファイルは更新されてました。(アーカイブ以下)
私の場合、過去にcgiファイルのperlパス内に「-w」が付いてるか付いてないかでも動作が変った事がありますので、そこも書き換えてみたりしたのですが、結果は同じでした。
あまりにも気になったので、今回はXREAにもちょっとだけ上げてみました。
すると、動作はXSASの時と変りませんでした。FTPソフトにFFFTPを用いてるので、このソフトを通じて見える「ファイルの日時」に関しては、
(恐らく「更新日」が表示されてるとは思うのですが、「作成日」なのかはっきりとは知らないです)
変化が「ありません」でした。
私の環境は色々と不備が多いと思うので、フィードバックとしてはきっと不適切。なので、もうしばらくテストしてみたりして、様子を見ようと思います。プラグインの作者さんの環境では動いてるんですよね。だから恐らく、何らかのこっちの悪い環境要素が働いてるんだと思います。ちなみに作者さんの環境は、
とのコト。FF1.5で試したいけどどうしようかな・・・(´・ω・)
他の利用者の方のアナウンスとか、作者さんよりの続報を待つ事にしました。
[参考記事]
■Junnama Online: MovableType Background Rebuilder Plugin(2).
上記は利点ばっかりですが、今のとこ何も悪い点が浮かばないのでしょうがありません。
・・・テンプレート内でPHP関数であるreadfileやincludeが使えないとか?
・・・判んないから実行あるのみ。
ローカルサーバーはいつものXSASです。
MTサイトはリネーム+丸々コピー。DBもリネームコピー。
MTのconfigファイルを開いて、DBの指定とサイトのパスを書き換えます。
新しいサイトにログインしたら、サイトの公開設定からURLパスやアーカイブパスを書き換えて、全て一旦再構築します。
前回導入した「バックグラウンドリビルド」が早くも大活躍です。静かで安心して作業出来ます。
私の場合はWidget内にreadfileを用いてテンプレートを読み込ませているので一苦労。。。だって全て書き換えないと(。。|||)
ここで注意するのは、WidgetManagerを用いてテンプレートを管理している場合、このWidgetを「一旦保存」する必要があることです。
これを行わないと、WidgetManagerで管理しているテンプレート部分はいつまで経っても前の状態のまま、になってしまいます。
ここまで済んで、新しいテストサイトが用意出来たらいよいよDynamic Publishingに挑戦です。
※htaccessファイルを置いてる場合は、バックアップ取って一旦削除しておいて下さい。(後述)
■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のテンプレートを作成しました。
それぞれの設定を行います。
私は全て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 Plugin.ja JP - Ogawa Code [Ogawa Code]
を導入すると、使用出来るコンテナタグにMTRelatedEntriesコンテナタグが追加されます。
上記は使用する際の一基準として。
]]>そのエラーの解決法です。
]]> 解決策 ■MT Extensions: MTTagInvoke version=1.0上記よりMTTagInvokeプラグインをDLして、
MTルート/plugins/MTTagInvoke/中身
という風にアップします。
MTルート/plugins/MTTagInvoke.plが入ってる場合は、削除します。
以上
]]>
XREA | <$MTBlogURL$>parts/header.php |
XSAS | w:/www/サイトのディレクトリ名/parts/header.php |
※大雑把なので、詳細は PHP+上記構文 で検索を。
今回は「readfile」を用いる事にしました。
- | XREA | XSAS |
<$MTBlogURL$>parts/header.php | ○ | × |
---|---|---|
(絶対パス)parts/header.php | × | × | (相対パス)../parts/header.php | ○ | ○ |
ここで一番不都合を感じたのは1番目。なぜならば、MTタグを用いれば ローカル→XREAサーバー へテンプレートをそのままコピペ出来るから。
2番目はトップディレクトリのみに使えます。ディレクトリの階層が変わってしまうテンプレートには使えません。
3番目の相対パスを用いれば、ほどなく解決しそうなのですが、これはカテゴリーテンプレートに使えないのです。なぜならば、サブカテゴリがメインの下層にディレクトリを作成する場合、カテゴリーアーカイブに記述出来るのは1種類の相対パスなので、メインカテゴリに併せた相対パス記述を行っていると、メインの下層に出来るサブカテゴリディレクトリではファイルが読み込めなくなるからです。
この辺りは正規表現プラグインや、カテゴリ判定の機能を用いて振り分ける事は出来ますが、それもぼちぼちじれったいので止め。
日付アーカイブや年別アーカイブだと、作成されるディレクトリは固定(アーカイブ・マッピングの設定で固定させておけば)されているので、階層に併せて記述すればそれで解決ではあるのですけど。
あとはカテゴリー・アーカイブに関しては、サブディレクトリを作らないようにするとか、つまりサブカテゴリを用いないようにすれば解決だったり、先に述べたように振り分け判定を用いるとか、諦めてカテゴリーだけはMTInclude使うとか、そういったようにすると良いのですが、個人的にやっぱり追求したくなって先を探りました。
そして、冒頭の▼結論を見つけました。
ローカル→サーバーに写す際に、このルート指定部分を書き直す必要はありますが、それでも、双方をほぼ同様の状態に保てるので助かります。
MTBlogURLタグが使えるようになるのが、本当は一番良いのですけどね・・・。
2006/11/03 09:57:43:記事書き直し
]]>
[配布元]mt-keywords2tags.ja JP - Ogawa Code [Ogawa Code]
上記よりDLさせて貰い、mt.cgiと同階層に入れてアクセスして実行。
※mt-cats2tags - Ogawa Code を使ったらどうなるんだろう?と思って試してみたら、上記にて行ったタグを、カテゴリー名で全て上書きされちゃいました。
※変換後の状況
先ずは試しに表示させてみようと思い、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
を修正します。
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:記事書き直し
MT3.32を削除します。
私の場合は以前と異なるディレクトリにインストールしていたので、削除してしまえばそれで良いですね。
以前と同一のディレクトリに入れてる場合は、削除してリネーム保管していたもとのMT3.2を戻しましょう。
それから、「mt-static」ディレクトリも元に戻す事を忘れないように。
3.3と3.2では中身全然異なります。これが残ったままだと大変な目に遭います。遭いました。これについては別エントリーにて。
バックアップしていたもとのデータベースを戻します。
<phpmyadminの起動>
特に意味はないかもしれませんが、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
mt-medic.cgi を mt.cgi と同じ階層にアップして、実行権限を与えたのちにアクセスする
正常にアクセス出来たら、今回はログインに関しての問題なので、Authors の項目にアクセスする。
すると、DBに残っている投稿者が表示されるので、 Edit から登録情報をやり直す。
パスに関しては、とりあえず別の簡単なものを設定してみて良いかもしれません。(例:0123)
私は以前と異なる簡単なパスをとりあえず入力して試しました。
正常に回復したあとに、再度MTの管理画面でパスの設定を行うようにしましょう。
また、私は管理用と投稿用の2つのアカウントを登録していたのですが、そのどちらとも mt-medic.cgi 上で設定し直しました。
この書き換える段階ではエラーが出なかったので、もしこの段階でエラーが出るようであればその対処については不明です。
エラーメッセージをもとに調査してみましょう。
情報を入力して、正常に出来たことを伝えるメッセージが出たら、きちんと Logout して抜けます。
mt-medic.cgi にアクセスして書き換えた際のパスを用いてログインを試みる。
回復出来ていれば、正常にログイン出来ます。
あとは再度パスの設定を行い、バックアップを取って終了。
以上
今回はログインに関してのリカバリーだったので、Authors の項目のみを触りましたが、他のpluginなどに関して問題が発生した際にも、このMT-Medicは役立ちそうです。
参考記事:
■コメントが、リビルドが、ログインが出来ない?!(MT-Medic.cgi等) (CROSSBREED クロスブリード!)
2006/10/20 23:07:59:記事書き直し
2007/01/31 22:47:04:記事書き直し