2010.05.06

復元に関するよくある質問:著者からの追記 『Movable Typeデザインカスタマイズブック 』

Movable Typeデザインカスタマイズブック MT4.2対応

書籍に関するお問い合わせが、出版社を経由していくつか入ってきています。うまく動いた、というご連絡も頂いていますが、全く進まないという方もいらっしゃるようです。

うまくいかないという方からのご連絡は、最初の段階で「バックアップデータとして配布しているサンプルテンプレートを復元する際にエラーが出てしまうケースがある」とのことでした。

確かに、Movable Type(MT)の操作に慣れていない人にとっては、復元はややハードルの高い作業です。特に、サイトパス、サイトURLといった概念をしっかり理解していないと、ミスしやすい要素がいくつもあります。

それでも、大量にある画像ファイルを手動でFTPしたり、テンプレートを1つずつコピペするよりは、ずっと手数が少ないですから、なんとかうまく復元を成功させて欲しい、と心から願っています。

そこで、ここでは復元作業において、勘違いしたり、間違えたりしやすい部分について、確認の意味もこめて解説させていただこうと思います。

MTをインストールされて、既に構造を理解し利用されている方には、かえってまどろっこしい内容かと思いますし、基本的には各自の動作環境に依存するものですから、ご契約されているサーバーにお問い合わせされるほうが独自の情報に辿り着くのには早いとも思いますが、カバー出来ない情報であるということを前提に、アドバイスとしてのキーワードとして、再度ご確認して頂きたいと思う項目をあげることにしました。

これが、読者の皆さんの新しいブログ作成の力になりますように。

以下の説明は、書籍に掲載した手順を参照にした上で、うまくいかない場合にミスが起こりがちなところ、注意したほうがいいところ、手間が増えても確実にやっておくべき方法、などのTIPSをまとめたものです。ご参照ください。

■初歩的なMTの設定の問題

復元時にエラーになる理由は、初歩的な問題を見落とした為に起こる場合が殆どです。
そこで、想定される状況をいくつか抜き出してみましたので、ご確認ください。

●<契約されているレンタル・サーバーの動作環境>

そもそも、MTを利用できないサーバーも、レンタル・サーバーの中には存在します。
「必要インストール環境、動作環境」はシックスアパートから随時発表されています。

http://www.movabletype.jp/documentation/system_requirements.html

MT利用可能というレンタル・サーバーでも、Perlバージョンで、最新バージョンのMTを利用可能としていない制限が、ある場合もありえます。

MTの仕様の問題で、4.21のバックアップデータを、それ以前のMTでは、受け入れることも出来ません。まずは、ご利用のサービスを確認しましょう。

●<契約されているレンタル・サーバーのデータベース環境>

次に、利用可能DBの数の問題を、確認してみてください。
レンタル・サーバーの契約されたサービスを確認して、MySQL/Postgresqlの利用可能数の確認をしてください。

月額利用料1,000円以下の多くのレンタル・サーバーでは、DB利用可能数が制限されているハズです。つまり「契約内容でDBが3つ」とある場合、Word PressやXoops Cubeやb2evolutionなどほかのソフトで既にDB数を使い切ってしまっている場合には、新たにMTをインストールして利用することは、不可能です。速やかに、他のソフトを削除するか、他のレンタル・サーバーへの追加、もしくは移行といった対応をしてみてください。

●<MT導入時に気をつけるべき事柄>

MTインストール時に、発生しやすい問題点もあります。
「MTの構成ファイルを保存出来ていない」という種類のエラーが現れた場合には、サーバーに「書き込み権限のないユーザー」として認識されている状態であることが考えられます。
この場合は、シックスアパートの指定する対処を行ってください。

http://www.movabletype.jp/faq/movable-type-1.html

MTのアップグレードが、うまく行えていない場合もあります。
この場合は、様々な理由が考えられますから、対処を限定できません。
シックスアパートのアップグレードガイドやサポートをご利用ください。

http://www.movabletype.jp/faq/movable-type.html

●<MT導入時のディレクトリ構造についての理解>

Chapter1 03 サンプルテンプレートの導入方法 p14で書いています。
MTインストール時に「 mt-static 」「 mt-static/plugins 」「 plugins 」「 import 」というディレクトリをマークしました。

これは、多くの場合、この階層でこのまま動くものですが、

まれにレンタル・サーバーの仕様によって、各自で設定を必要とする場合もあれば、

http://www.movabletype.jp/faq/movable-type-1.html

管理者権限を持っていないことで動いていないこともあれば、
そもそもPerlモジュールが古い可能性もあれば、

http://www.movabletype.jp/faq/mt-static.html

MT本体の処理能力として、多数のファイルを1度に復元する際に、エラーが発生することもありえます。

http://www.movabletype.jp/faq/request-uri-too-large.html

たまに、MT本体のバグもありますが…(大泣)
現状では、本書では、MT4.22に対応しているバックアップデータを配布していますので、とりあえずは、契約されているレンタル・サーバーの個人的な情報や設定内容を確認しなおしてみてから、その指定に合わせて作業を始めてください。

ここまでは、MTの設置の問題ですね。

申し訳ないと思うのは、私たちの書籍では、そもそも根本的なMTの利用方法に関しては、触れていないということです。ほぼ同時期に、同じ出版社から先行して、『Movable Type 4 新しいWebサイトの黄金則-MTで実現するCMSサイト構築のすべて-』という書籍が発売されています。

http://www.sbcr.jp/books/products/detail.asp?sku=4797346305
http://www.amazon.co.jp/dp/4797346302

こちらも、特化されたプロフェッショナルが担当していましたから、本書では、この書籍の範疇と区別して制作しました。こちらは初心者がMTを理解して操作するまでの一般的な知識を紹介しています。本書は、この書籍の想定するステップの次、応用編のポジションにありますので、もし、お時間があるようでしたら、是非こちらのほうもご参照くださいませ。

基本的なMTの設置や初歩的な操作についてのコンテンツは、こちらのほうが理解は進むと思いますし、気持ちとして、納得しやすい解決策になるようにも感じています。これはこれで、なかなか面白いものがありますよ。

他に、PC環境に問題がある場合もありえます。PCにウィルスが入り込んでいるという場合です。こうなるとそもそもPCにおける初歩的な基本というか、ソフト動作の根本的な問題なので、あまり自信を持って答えられる範疇ではないのですけれど…。実際、そういうこともありえます。

この状態になっていると、症状としては、「MTが勝手に終了してしまう」というエラーが頻発します。原因は判然としません。諦めて、個人のPCをクリーナップして、合わせて、サーバーの中身も空っぽにしてみましょう。案外気持ちのいいものですよ。(面倒ですけどね(泣))

■初歩的なブログの復元に関しての確認事項

ここからは、ブログの復元に関しての確認事項について、話します。

●<復元データを、UTF-8で編集していない>

Chapter1 03 サンプルテンプレートの導入方法 p16で書いています。

復元データの「xmlファイル」「manifestファイル」の編集は、必ず、テキストエディターの、文字コード「UTF-8」改行コード「LF」で行ってください。

Chapter4 08 Ajax検索を用いたサイト内検索機能を導入する p21で書いていますので、詳しくは端折りますが、MT内部の文字コードはUTF-8で処理するよう設定されています。

これに対応していないと、症状としては「復元時にデータを読み込まない」「読み込んでも文字化けなどでひどい画面が現れる」など、レンタル・サーバーの環境によって様々な展開があるようです。

バックアップファイルは、直接サーバー(DB)と会話するファイルです。UTF-8で編集してない場合、外国人に日本語で話している状況ですので、通じるはずはありません。

ということを想像していただいて、「お約束を守らないと、分かりあう前の段階で近寄ってもくれないのがMT」と認識してみてください。

どんなに設定が合っていようと、通じていない状況であれば、エラーしか現れません。

よくある失敗で言えば、3つ可能性があると思います。

1つは、使用しているテキストエディターや、FTPクライアントの設定の問題です。

これは、ソフトによって違うので一概に言えませんが、「notepad」や「秀丸」、「テキストエディット」や「mi」などのテキストエディターであれば「名前を付けて保存」から「UTF-8で保存」するだけで済む筈です。

が、例えば、「TeraPad」や「Wor」や、サイト作成用のホームページエディターであれば、ソフトごとに保存の仕方が変わる場合もあります。こういった場合には、ご利用になっているエディターの利用方法を確認してください。

ソフトによっては、FTPクライアントも同様に、文字コードの設定が手動で必要になる場合もあるかもしれませんので、操作方法を確認してください。

2つめは、アーカイバーの問題です。

「文字コードがshift-jisⅡに変換されている理由」としては、アーカイバーの利用時におきている現象だと断定できます。

例えば、Macで利用される「stufflt standard」の利用注意にも、

「圧縮・解凍を行うファイル名に2バイト文字(漢字やひらがな、カタカナなど)を使用し、別プラットフォームで解凍を行うと、ファイル名が文字化けする場合があります。」

と明記されています。例え他の原因としても、症状としてのshift-jisⅡに変換は、よくあることす。

ご使用中のアーカイバーの仕様に沿って、適切にダウンロードと解凍を行ってください。

もう1つは、サーバー上でのディレクトリを作成する際に弾かれる、2バイト文字の問題です。
ディレクトリを日本語で表記している、もしくは全角アルファベットで表記している場合などに、エラーが多いように思います。これは必ず、半角英数で表記しているか、確認してください。

特に怪しいのは「 / (スラッシュ)」やスペースです。無意識にスペースが入り込んでいる場合もあるかもしれません。

悲しいことに、そういった場合には、MTから必ず「不正な要求です。文字コードUTF-8に含まれない文字データを送信しています。」とお叱りを受けることになりますので、気をつけてみてください。

MTにUTF-8じゃないと叱られる場合にはやはり、結果として、UTF-8で保存が出来ていない状況なのです。1つ直しても、まだ残っているかも、と、探してみる根気が必要です。

また、MTの問題として、エラーが発生する場合もあるようです。

セキュリティアップデートを行った「結果」としての不具合であるとのことで、このエラーが現れるということもありそうです。

その他の可能性については、シックスアパートから随時発表されています。

あわせてご確認ください。

http://www.movabletype.jp/faq/utf-8.html

●<「 import 」ディレクトリを適切な場所に作成していない>

Chapter1 03 サンプルテンプレートの導入方法 p16で書いています。

「 import 」というディレクトリを適切な場所に作成していない、もしくはバックアップファイルのアップロードが出来ていない場合などには、「ファイルは復元できませんでした」というMTのエラーが現れます。

まれに、レンタル・サーバーの書き込み制限がある場合もあるようですが、アイテムのアップロードの指定方法1つに関しても、サーバーの仕様によって様々なルールが業者やサービスや、コースの組み合わせ次第で様々ありえますので、一概には言えません。

が、お問い合わせがあった件に関しましては、基本的な設定として「 import 」の階層が間違っていることが多いように思います。基本の対応としては、サーバー内の、ご自分の管理者領域の中に、ソフトとしてのMTディレクトリを置き、その中に「 import 」というディレクトリが置いてあるか、改めて確認してみてください。

また、レンタル・サーバーによっては、セキュリティとして意図的に、そのディレクトリを変更している場合もありますので、ここはしっかりと確認のうえ、ご契約内容に沿った適切な場所に設置してくから、バックアップファイルをアップロードするしかありません。

ちなみに、本著の書籍内容に該当するサポートとしては、ここまでが限界です。

一般的な答以上の、特に契約IDに関する情報等、これ以降に提示するTIPSに関しましては、速やかに、ご利用されているレンタル・サーバーなど、適切な窓口に、直接問い合わせください。

■初歩的なブログの復元に関しての確認事項

以降は、サポートやフォローとしての責任からは外れてしまいますが、アドバイスとして、復元に関する変更点のポイント、注意すべきところをお知らせします。

ここを確認していただくことで動作が完了することが、ベストです。

が、仮にこれでも、まだよく分からない、という場合には、個人的な情報を、適切な窓口に、直接問い合わせする為のキーワードとして、初歩的な確認事項の足がかりにしてください。

●<アプリケーションディレクトリとブログディレクトリの違い>

Chapter1 03 サンプルテンプレートの導入方法 p19で書いています。

サーバーの指定記述が間違っていて、「サイトパスとサイトURLが合っていないこと」を原因に、エラーが起こっているという状態のお問い合わせが数件来ました。

つまり、指定したパスが違っているので、MTがブログの存在を認識出来ていない状態です。

「指定パスと出力先指定のエラー」を理由に、「そのディレクトリないですよ~」とMTが何度も教えてくれている状況にハマってしまっているようです。

配布時の初期設定と異なる場所にブログディレクトリを設置する場合には、必ず、ご自分用に変更をしないと、見向きもせず動きもしないのがMTというものなのです。

この問題は、アプリケーションディレクトリとブログディレクトリの違いを理解することから始まります。

MTを初めてインストールした人の場合、この違いが頭の中でゴチャゴチャになりがちです。

MTの本体をインストールしたディレクトリと、ブログを出力するディレクトリは、まったく別のモノです。

ハナシを分かりやすくするために、MT本体をインストールしたディレクトリを「アプリケーションディレクトリ」、ブログを出力するディレクトリを「ブログディレクトリ」と呼ぶことにします。ここからは、実際の変更点を説明していきます。

例えば、
アプリケーションディレクトリでは

http://www.sample-site.jp/mt/

という、MTを設置したディレクトリを指定し、
MT本体にアクセスするときには

http://www.sample-site.jp/mt/mt.cgi

という、MTの管理画面を表すディレクトリを指定します。

(「 www.sample-site.jp 」は架空のドメインとして読み取ってください。実際には、MTをインストールするサーバーに設定したドメインを入力してください。)

また、ブログディレクトリ

http://www.sample-site.jp/blogname/

というように設定するものだと考えてください。

(「 blogname 」は架空のディレクトリとして読み取ってください。実際には、ブラウザーでアクセスするURLを入力してください。)

復元作業で入力が必要とされるディレクトリ情報は、「アプリケーションディレクトリ」ではなく、「ブログディレクトリ」だけです。

間違えて「アプリケーションディレクトリ」の情報を、復元作業中に現れるウィンドウに入力しても、エラーが出るはずです。

アプリケーションディレクトリの中に、ブログディレクトリを作成するやり方も、出来るといえば出来ますが、あまり健全なディレクトリ構造とはいえません。アプリケーションと、その成果物であるブログの出力先は、しっかりディレクトリを分けるべきです。

まずは、「ブログディレクトリ」を入力しないといけないところに、間違えて「アプリケーションディレクトリ」を入力してしまっていないかを、確認してみましょう。

●<サイトパス(Site Path)を確認してください>

ディレクトリ情報でもう1つ、初心者泣かせなのは「サイトパス(Site Path)」の情報です。

MTを自分でサーバーにインストールしたり、MTでブログを立ち上げたことのある人ならば、問題なくクリアできるかもしれませんが、調べるのは結構面倒な作業ですよね。

改めて補足します。

パスとは、「path 経路」という意味で、「pass 通過」と、日本語では混同されてやすいように感じることがあります。コンピューター用語としては、「path」を利用します。

これは、ファイルやフォルダの所在を示す文字列の意味で、使用しています。「 / (スラッシュ)」で区切ることで、ディレクトリの階層を表しています。

ここで使用する「サイトパス」とは、ユーザーがレンタルしたディスク領域が、サーバー上のどの位置にあるかを示すパスの表記方法のことです。

面倒なワケは、MTをインストールするレンタル・サーバーによって、その書き方がバラバラ、ということが当たり前の状況であるからです。これは、書籍で言い切ることが出来ない種類のものであり、このレンタル・サーバーを使用してください、と強制することも出来ない種類のハナシでもあります。

レンタル・サーバーの構成は、サーバーOSやウェブ・サーバーの種類、DB、Perl モジュールなどの組み合わせによって異なるので、指定法は様々に存在しています。

レンタル・サーバーの指定するパス記述は、「home」「www」「virtual」などで始まる表記で、必ず個人の環境ごとに1つしかない情報なのです。

まずはこれに合わせて、各自の設定で対応することが、MT利用における準備の1つなのです。

書籍のバックアップデータには、デフォルトで、仮の「サイトパス(Site Path)」を入力しています。「 /home/user/www/mt_sites/a1 」(サンプルテンプレートAの場合)

この「 /home/user/www/ 」の部分の書式が、サーバーの設定によって、様々な形で存在しているので、個別の対応が必要とされるところなのです。

ここの書式がキモなので、まずは、各自の設定をしっかり調べて、準備しておきましょう。

例として、よく使われているレンタル・サーバーの設定を抜き出してみました。

ロリポップの場合、設定マニュアルページによると

http://lolipop.jp/?mode=manual&state=blog&state2=mt_2
「 /home/sites/lolipop.jp/users/chu.jp-hoge/web/ 」
(「chu.jp-hoge」はユーザーID)。

チカッパの場合ならば、設定マニュアルページによると

https://user.chicappa.jp/?mode=support&state=manual&state2=mt_04
「 /home/sites/chicappa.jp/users/chicappa.jp-hoge/web/ 」
(「chicappa.jp-hoge」はユーザーID)。

さくらインターネットの場合、設定マニュアルページによると

http://support.sakura.ad.jp/support/manual/rs/mt_man.shtml
「 /home/exapmle/www/ 」
(「exapmle」はユーザーID)。

上記の書式の後ろに、ブログを設置したディレクトリが続くことになるのです。

ブログを設置したいディレクトリが、WWWサーバーのルートから

「 /mt_sites/a1 」

ならば、上記の例のロリポップの場合、

「 /home/sites/lolipop.jp/users/chu.jp-hoge/web/mt_sites/a1 」
(「chu.jp-hoge」はユーザーID)、となるワケです。

確かにこれは、お世辞にも分かりやすいとは言えませんね。

また、レンタル・サーバーの設置マニュアルなどでも、「サイトパス(Site Path)」が、別のウィザードでは「公開パス」と呼ばれていたり、ブログの公開設定画面と復元ウィザードでの説明画面で「サイトパス」と「サイトURL」の上下関係が逆になっていたり、日本語表記になったり、英語表記になったりと、インターフェイス的にも、間違いを起こしやすい構造になっているように思います。

実際シックスアパートというソフト業者から発行されるMTは、やはりオープン・ソースとしての特色として、バグフィックスの出荷スパーンが短いことも、バージョンによってインターフェイスが異なることが多いことも事実ですし、レンタル・サーバー側が、不安定要素のある最新バージョンを推奨しない場合も多いので、それに準じたバージョンの説明が展開されることも多々ありますから、ここには、利用者であり契約者である個人の、独自の理解が必要となるのです。

特に「サイトパス(Site Path)」は、事前によく調べて、しっかり確認してインストールしてみましょう。

ロリポップ、チカッパ、さくらインターネットでの設定に関しては、ここを変更しただけで、動作するようになったという方もいましたので、希望を持って、挑戦してみてください。

●<デフォルトのブログディレクトリに復元する場合>

Chapter1 03 サンプルテンプレートの導入方法 p16で書いています。

復元作業をする前に、ブログの出力先ディレクトリを、正しく作成しておく必要があるのです。
サーバーによっては、MTによるディレクトリの自動生成が可能な設定のものもありますが、先に手作業でブログディレクトリを作っておいたほうが、より確実です。

例えば、書籍に載っているサンプルテンプレートAを復元する場合で、説明してみます。

配布しているサンプルテンプレートAは、デフォルトで「 /mt_sites/a1/ 」というディレクトリにブログが出力されるように、あらかじめデータが書き込んである状態で配布されています。(後の入力画面で自由なディレクトリに変更することも可能です。)

デフォルトのままでサンプルテンプレートのバックアップデータを復元すると、

ドメインが「 http://www.sample-site.jp/ 」ならば、
「 http://www.sample-site.jp/mt_sites/a1/ 」に、

自動的に出力されるというワケです。

この場合には、復元作業に入る前に、FTPクライアントで「 /mt_sites/ 」というディレクトリを作成しておく必要がある、ということを理解してください。

大抵の場合はこれで、MTがうまく、ブログディレクトリ内にサブディレクトリを作成して、復元作業は完了します。

しかし、これでうまくいかない場合には、「 /mt_sites/ 」だけでなく、「 /mt_sites/a1/ 」まで事前にディレクトリを作成してみると、うまくいくと思います。

この場合、合わせて、ディレクトリのスペリング(綴り)が間違っていないかどうかも、しっかり確認しましょう。

私も、「 /mt_sites/ 」とするべきところを「 /mt_site/ 」(最後に「s」が抜けてる)のに、なぜか全く気が付かなくて、何日もロスした経験があります。

こういう場合、まずはヒューマンエラーを疑うべきです。長い綴りの場合は、なるべくコピペを使うのが、ミスを減らす方法ですよ。

それでもうまくいかない場合には、FTPクライアントで作成した「 /mt_sites/ 」や「 /a1/ 」のディレクトリに対しての権限(パーミッション)を変更してみるのもテです。

多くのサーバーでは、新規にディレクトリを作成した場合、権限は「755」になります。

パーミッションの設定としては「755」を強くお勧めしたいのですが、サーバーによっては、「700」「701」「757」を指定している場合もありますし、シックスアパートでは、バックアップデータの復元に「777」を指定しています。
http://www.movabletype.jp/documentation/linux.html

これも、独自の環境に合わせてパーミッションを変更してみてください。

ただし、パーミッションを変更して、例えば「777」などにするということは、セキュリティを下げることにも繋がる行為であることを、認識しておいてください。

シックスアパートもレンタル・サーバーも、データの保守の責任を負ってはくれません。その責任を担保する利用料は、正しい比例で相場を形成しています。

セキュリティに関しては自己責任となりますから、その危険性と安全性を保つ方法をしっかりと下調べた上で、パーミッションの変更を行ってください。

ここまで設定が済めば、復元作業中に、サイトパス(Site Path)とサイトURL(Site URL)を確認する画面が現れます。

もし、ブログディレクトリが「 /mt_sites/a1/ 」のままでよくて、前もって当該ディレクトリを作成しているのならば、ディレクトリの部分の情報は変更する必要はありません。

ただサイトURLに関しては、架空の想定データとしてドメインを既に、「 http://www.sample-site.jp/mt_sites/a1/ 」と指定している状態で、データを配布していますので、ここは必ず、ご自分のドメインに変更してください。

あわてていると、このドメイン名の変更を見落としてしまいがちですが、データの指定が違ったままでも、MTは自動的に、「 www.sample-site.jp 」のまま、復元しようとしてしまいます。当然の流れとして、ドメインが「 www.sample-site.jp 」のままでは、ブラウザーに表示される筈もなく、エラーが現れてしまいます。

●<任意のブログディレクトリに復元したい場合>

引き続き、サンプルテンプレートAを復元する前提で説明をします。

もし、デフォルトで設定されている「 /mt_sites/a1/ 」以外の、自分で作ったブログディレクトリに復元したい場合には、各自の環境に合わせて、適切な指定をしなくてはいけません。

というか、ほとんどの方が、「 /mt_sites/a1/ 」でなんて、出力したい筈がないですよね。こういった場合にはまず、FTPクライアントから、手動でディレクトリを作ることから始まります。

例えば、「 http://www.sample-site.jp/blogname/01/ 」というディレクトリにブログを作りたい場合、FTPクライアントでWWWサーバーのルートに、「blogname」というディレクトリを作るところから始まります。

(この場合の「ルート」rootは「根源」という意味でもありますが、コンピューター用語では、特にLinux系で使われる「管理者領域」という限定した意味で使っています。Roote「根付いた」でも、route「経路」でもないので、誤解で思い込まないように、注意しましょう。ルートとパスの意味が混ざってしまうと、大変なことになりますから。)

心配ならば「blogname」というディレクトリの中に、「01」というディレクトリも作っておきましょう。

手順は、デフォルトのディレクトリに復元するのと同じです。違うのは、復元ウィザードの途中で「サイトパス(Site Path)」と「サイトURL(Site URL)」の確認画面が出たときに、それぞれのパス情報を変更するところだけです。

サンプルテンプレートの場合、デフォルトのデータでは、

「サイトパス(Site Path)」には
「 /home/user/www/mt_sites/a1 」と、
「サイトURL(Site URL)」には
「 http://www.sample-site.jp/mt_sites/a1/ 」と

書き込まれています。

これを入れ替える形で、「サイトパス(Site Path)」は、事前に調べておいた独自のパス、各自の環境に沿った書式の後ろに、ブログを復元したいディレクトリのパスを、続けて書きましょう。

上記のロリポップの設定を例に取るならば、

「 /home/sites/lolipop.jp/users/chu.jp-hoge/web/ 」
(「 chu.jp-hoge 」はユーザーID)の後ろに、「 blogname/01 」を続けて、
「 /home/sites/lolipop.jp/users/chu.jp-hoge/web/blogname/01 」と入力します。

「サイトURL(Site URL)」は、「 www.sample-site.jp/ 」のドメイン部分を、自分が使うドメインに変更して、その後ろにブログを復元したいディレクトリパスを続けて書きます。
仮に「 www.sbcr.jp 」というドメインを使うのならば、表記は、

「 http://www.sbcr.jp/blogname/01/ 」となるワケです。

「サイトパス(Site Path)」と「サイトURL(Site URL)」を正しく入力すれば、復元作業は何事もなく完了するはずです。

「サイトパス(Site Path)」と「サイトURL(Site URL)」は、表記方法が違うだけで、実際には同じ場所を示していることを、よく覚えておいてください。

レンタル・サーバーによってエラーの表示は変わりますが、サイトパスが間違っている場合には、MTに必ず「Invalid name in entity(存在しない名前ですよ)」「Permission denied(許可出来ませんから)」などと、お叱りを受けることになります。

そこまでやっても、まだ動かないのならば、配布しているデフォルトのブログディレクトリに復元する場合と同じく、新規に作成したブログディレクトリに対して、パーミッションを変更して試してください。

●<何度も復元作業を試す場合はアイテムを削除>

復元がうまくいかず失敗した場合には、ブログ記事やテンプレートなどの「中途半端なデータだけが復元されたブログ」が、出来上がってしまいます。

失敗データは必ずキレイに掃除してから、問題点を整理して、次のチャレンジをしてください。

削除の方法は、「システムメニュー」の「ブログ一覧」から、「ブログ」ごと削除すれば、ブログごとまとめて削除されます。しかし、ブログ記事やテンプレートなどのデータは、キレイに一括して削除されるのですが、アイテム(画像)情報や、タグ情報は、MTのDBから削除されません。

アイテムやタグは、他のブログでも使い回す可能性があるので、直接ブログと紐付けされず、独立されてMT内に保持されているのです。ここには、1MT≠1BLOGでない奥深さがあるのですね。

長い話は省きますね。DBの仕様によって、クリアに削除されることもあれば、ゆるい反応で終わってしまう場合もあるらしいのです。MTの仕様も関係あるかもしれませんね。

ではありますが、結果だけで言うと、何度も同じテンプレートを復元しようとして失敗すると、同じアイテム情報が大量にMTの中に保持されることになります。

アイテム(画像)の復元がうまくいかなかった場合、画像ファイルそのものは、ブログディレクトリにコピーされず、アイテム情報だけが、MTに残ってしまっている場合もありえます。後でワケが分からなくなる可能性がありますので、復元に失敗した場合には、ブログの管理画面の「一覧」メニューから、「アイテム」を選んで全てのアイテムを削除しましょう。

また、同じくブログ管理画面の「一覧」メニューから「タグ」を選んで全てのタグを削除しましょう。さらに、一覧メニューから「カテゴリー」「ブログ記事」「ウェブページ」「コメント」「トラックバック」なども全て消してしまいましょう。
その後、システムメニューに移動して、「一覧」メニューから「ブログ」を選んで、ブログを削除しましょう。

まとめると、復元に失敗して再度同じサンプルテンプレートの復元に挑戦する場合は、まずブログ管理画面から「アイテム」「タグ」「カテゴリー」「ブログ記事」「ウェブページ」「コメント」「トラックバック」などを全て削除します。その後、システムメニューからブログを削除してください。まず中身をキレイにしてから箱を処分する、というイメージです。

この作業を行わないで同じサンプルテンプレートの復元作業を繰り返すと、カテゴリーの情報がうまくMTのDBに取り込まれず、カテゴリ情報が壊れてしまうことがあります。必ず再挑戦の準備は万端に行ってください。

●<ブログ設定時の編集>

Chapter1 03 サンプルテンプレートの導入方法 p21-23で書いています。

再構築がうまくいかない場合は、原因はかなり限定することが出来ます。それは、各自の設定が必要な、編集作業(ブログIDや、ユーザー情報)で、なんらかの間違いを起こしている場合に起こる症状だからです。関連付けされていなければ、再構築はできないということなのです。

Chapter4 02 複数のブログをまとめるポータルブログを作る p245で書いています。

ブログIDの場合であれば、バックアップを繰り返すたびに、MTがそれぞれに、独自のブログIDを発行します。
もし仮に、7つのテンプレートを復元して、それを繰り返した場合であれば、その度にブログIDがズレていきますから、対応していなければ、実際の指定が違っていて、MTには認識出来ないということが起こります。

Chapter5 01 MT4.2の新機能 コミュニティソリューションの基本 p184で書いています。
ユーザーの追加を正しく行わなければ、掲示板の情報は、そもそも構築するものがない状態になってしまいます。これには、書籍に書いた以上の対処はありません。適切に、毎回、編集作業を行ってください。

●<復元作業時の強制エスケープ問題>

復元するサンプルテンプレートのバックアップデータには、多くのHTMLタグを始めとしたエスケープ対象となるコードが入っています。テンプレートや通常のブログ記事内に入っているHTMLタグは、そのままMTのデータベースに読み込まれます。

しかし、ごくまれにカスタムフィールドなどの特別な場所に入っているHTMLタグが、エスケープ処理されてしまうことがあります。

Chapter2 12 ボーダーと背景画像で画像の見た目を整える p73のコラムにも書いてありますが、エスケープ処理とはHTMLタグを文字としてブラウザー上で表示させるための表記方法です。エスケープが行われると、HTMLタグやPHPコードなどの働きを停止させるため、システムのセキュリティを高めるためにも用いられます。

どのような条件で復元時の強制エスケープが行われるのかは、シックスパートからもアナウンスはなく、現状では原因は不明ですが、もしうまくHTMLタグが機能せず、ブラウザーにコードが表示されてしまうような状態になった場合は、強制エスケープの可能性を疑ってみるべきです。

このエラーで、起こる人と起こらない人の特定は出来ていませんが、個人的にはもしかしたら、サーバーのDBやPealモジュールの組み合わせによって、起こる症状ではないかとも思っています。
が、やはり推測の域を出ない話ですね。そのうちMTからFAQに掲載があるかもしれませんし、手堅い対処法だけ、お伝えします。
もし意図しないエスケープが行われていた場合は、手作業でコードを入れ直してください。

●<セットアップの順序>

Chapter1 03 サンプルテンプレートの導入方法 p21-p24で書いています。

これらも、書籍で書いた以上の情報はないのです。1つだけ改めて伝えたいのは、本書に掲載しているこの順番で作業を行い、必ず、最後の最後で再構築を行ってください。

うまく復元できない場合の多くの理由は、「サイトパス(Site Path)」や「サイトURL(Site URL)」が間違っていたり、ブログディレクトリの権限に問題があるときのように思いますが、それに伴って勘違いしたり、間違えたりしやすい部分を、同時に2つ3つ重ねているようにも感じます。

PCにソフトをインストールするよりも、サーバーにソフトをインストールして、そこから設定を繰り返していくことのほうが、やはり難しいものなのです。

難しいことと覚悟した上で、まずは落ち着いて、慎重に準備を整えてから、対処にとりかかってみてください。

それから、困ったときには、Webを頼りにするというテもあります。これは、王道です。

シックスアパートのMovable Type FAQや、
http://www.movabletype.jp/faq/
Movable Type 4 ドキュメントなどを確認することはモトより、
http://www.movabletype.jp/documentation/

レンタル・サーバーのマニュアルやサポートや助け合い掲示板、検索エンジンで「MT エラー表示」を調べてみることもオススメします。

1つのエラーから、独自の環境を絞り込むことは、誰にとっても酷な状態だと思いますが、似た環境、似た状況を、1つづつ検証していくことは可能なはずです。

そして、意外なことに思うかもしれませんが、この方法が案外、1番早く正解に辿り着くのではないかと、私は思っています。

頑張ってください。

うまく動いたときには、きっと、とっても嬉しい気持ちになるはずです。