一番最初にはまったのはおそらく単純にアップロードしようとしていたディレクトリへのフルパスを間違えていたこと。普段FTPでサーバにアクセスするときのショートカットとしてユーザディレクトリへのパスとして /public_html 以下をブックマークしてあるのでなんとなくパスとして /public_html/hogehoge/my_site/blog/imgs 的なことを書いてしまったのだけれども、正しくはこのディレクトリへのパスとしては /home/username/public_html/hogehoge/my_site/blog/imgs っぽく書くべき。たぶん発端の問題はこれだけでただ / がユーザの書き込み権限のないところなのでアップロード用のディレクトリが作れずにエラーになっていたと。それだけだったはず。
しかしここで 粘着質で   まじめで根気のある性格でかつ 短気な   行動の早い俺はそこら中のパーミッションを変更してみたりphpファイルをわかりもしないのに開いてみたりして何やらよからぬ事をしてしまい。
しばらくいじったあとで先の間違いに気付いてアップロード先のパスを指定しなおしたらなんとかファイルの「アップロード」自体はできるようになったのだけど、一発目は大丈夫なのだけど二発目以降がうまく行かない。さばくってみたところ、例えば一発目が01.jpgであったとすると、二発目のファイルが例えば02.jpgであるとするとそれをアップローダで選択した時点での表示は正常に02.jpgになるのだけど、記事に埋め込むボタンをクリックしてアップロードを実行すると、記事のタグの中でそのファイルを指すパスの末尾のファイル番号が11.jpgと、変わってしまう。？？となってFTPでアップロード先のディレクトリを見るがファイルはない。で三発目をアップロードすると今度は21.jpgに。バカにしとんのか。
WPの「メディア」タブから見るとその化けてしまったファイル名のものがライブラリにあるから、おそらくDBのレコードが何かスプラッタなことになっているらしい。非常に心細い状況だが、とりあえず頭もウニだし、たぶんこっちのiMacさんや向こうさんのサーバーの頭もウニになっているはずなので、とりあえずiMacさんのキャッシュを全消去してOnyxさんのお世話になり、もうしばらくして向こうさんのサーバも正気を取り戻した頃を見計らってもう一度試してみる。現状は、defaultの wp-content/uploads にであれば問題なくアップロードできる状態。

便利さを追求してこそのコンピュータである。（謎）

• 読み込みテキストの区切りのエントリが欠損しているので順次手作業で追加
• 2009/1 のエントリの重複が整理できていないのでこれも適宜消去
• index.html を index.php にリダイレクト（たぶん不要）
• 旧フィードへの要求をリダイレクト
• スタイルシート変更（font-size/ line-height/ body.width/ ほか）
• 写真ほかのメディア投稿のテスト
• うざいサイドバーをアーカイブでは別のシンプルな表示に入れ替える

まぁそのくらいか。

以前MTをセットアップした頃は誰にも知られていないURLでロボット除けも施してのんびり半年くらいかけてやっていたんだけど今回はそうもいかないのでしばらく見苦しい状態が続くと思いますがどうぞご容赦ください。あと、これはお願いモードなのですが。表示の不具合とかあるいはインポートしたつもりで抜けているエントリーとか、過去のコメントが消えてしまっているのとかに気がついた方がいらっしゃったら（そんなヒトいないと思いますが）コメント欄などでツッコミをいれてくだされば順次修正していきます。なにぶんまだメールフォームもつけていないヘナチョコな体制なので。どうぞよろしく。

休み明けに島に行くことになるらしい。といっても愛知県は渥美半島と知多半島の間の海に浮かぶ海のニキビみたいな島でGoogleマップでさまよってみた範囲でいえばどうやら保養地としてそれなりに有名なところらしい。伊勢湾の島というと大学の頃に高校の友人と一緒にやっていた「朕思うに麻呂はおじゃる隊」（通称おじゃる隊）でキャンプにいった先の、たしか鳥羽あたりからフェリーで渡る神島という島が印象に残っているが（記憶に間違いがなければ澪つくしの舞台になった島だと思う）おおむねその島の４倍くらいの島であるように見える。伊豆大島の1/5くらいかな。それなりに大きい。

Wordpressに読み込ませたエントリーを一旦全消去（一旦というがもう５回目くらい）して半年単位で読み込ませてみたが。要は終端だけでエラーが起きるのならば読み込ませるブロックを大きくして数を少なくすればこぼれる数が減って最後の手作業での修正が少なくなって楽かと思ってやりなおしたのだけれどもとりあえず最初の半年分のブロックについて読み込み元のtxtファイル内の TITLE: という文字列のカウント数が422であるのに対して読み込まれたエントリーの数は405である。つまり5%ほど取りこぼしている。（だめじゃん）
読み込まれたものをざっとブラウズしてみると全部タイトルがあるものだなという印象がある。タイトルがないエントリのハンドリングが悪いのかなとも思うのだけれどもあくまでも印象レベル。ただ、MTもそうだけど、どうもweblogツールというやつは「タイトル」を持つエントリを扱う事を前提にしているみたいだ。そこはtwitterやtumblrとは違うなと感じる。
あくまでも感じるというレベルだが。所詮俺なんか印象レベルの妄言を５年かけて９MBも垂れ流すくらいのクォリティの人格でしかない。自虐。
だが不屈。　@2009年4月26日日曜日 6:56:49

http://www.optimagraphics.org/dannna_o/blog/archives/123456.html　という今使っている形式は個別の記事を指すパスとして意味と形がよく揃っているような気がして俺的には気に入っているのだけど。

とりあえず設定ファイルをいじって自動保存は無効にした。だから一旦読み込ませたもののidが変わるという怪奇現象はもう起こらないはず。ただ、読み込ませたあと出力先のディレクトリをいまのこの　http://www.optimagraphics.org/dannna_o/blog　に変更したとしてもパーマリンクは引き継げない。でもまぁ、ある意味でむかしの記事とバッティングはしない訳だからそれでいいのかも知らんなとか．．いろいろ考えている。

http://www.optimagraphics.org/dannna_o/blog/000002.html
http://www.optimagraphics.org/dannna_o/blog/2.html

になる訳だから。
たぶん連休明けというか5月くらいからそちらにアクセスできるようにするだろう。関さんちの真似じゃないけど毎年ディレクトリを変えるとかそういうカンジにするかもしれない。
@2009年4月24日金曜日 15:09:21

パーマリンクの書き出し形式まで間違えていたというどうしようもないていたらくだが。とりあえずわかった事もいくつかあり。重要なのはWordpressのPermalinkの設定が0パディングに対応できていないという事か。（たぶんこれはデムパではないと思う）読み込もうとしているエントリーの最後がid9500番台で、これを読み込ませて以前と同じパスで表示させるためにはWordpressのPermalinkを /archives/00%post_id%.html と設定してやればよさそう。ただしidが3桁以下の場合は読み込ませる前か改めて書き出してあとに手作業で00…で埋めてやらなきゃならない。そして10000を超えて以後はWordpressの機能で0パディングがサポートされるまで定期的に同じ作業を繰り返すと。まぁテキストエディタのマクロをもう少し勉強すればできない事じゃないと思うがあまりにもバカっぽい。

あきらめてパーマリンクが変わる事を受忍してもういっそ別のディレクトリで公開してしまう事にするのが一番賢い生き方なんだけどな。そういう事に向いていない。性格が。（謎）
別に企業サイトや公益サイトじゃないからパーマリンクにこだわる意味もないんだけど、桁糞悪い。　@2009年4月23日木曜日　18:55:00

追記：
wpの側のwp-admin/import/mt.php を読むと
「PERMALINK: を含む行を見つけたら先頭の PERMALINK: という文字列を切り捨てた内容をテンポラリにキャッシュして次ぎにいけ」テキな事が書いてあるように空目できるので楽観視する事に決める。（謎）

対処した事は。トラブル後に書き戻したmt3のコンソールからは個別アーカイブのパスは　%y/%m/entry_basename.html　として設定（defaultか？）になっていたんだけどこの entry_basename の部分が問題なので、タグリファレンス http://www.sixapart.jp/movabletype/manual/3.3/e_archive_file_path_specifiers/ を参考に　%y/%m/%e.html　と書き換えて設定を保存。その後で新たにエクスポートを実行し、現状で、パーマリンクが正確に反映されたmt3からのバックアップテキストは取得できた。

ただもう一つ問題があって、Wordpressの方で新たに読み込んだインポートに対して以前のpost-idが生きてしまっているようだ。これはまぁ最悪でもデータベースの初期化かあるいはまったく別のweblogとして設定してしまえば問題は無くなると思うが、少しいじってみる。
コンピュータ厭きたよ。　@2009年4月23日木曜日 16:00:25

戻ってきて一眠りしてから昨日書いたMTからの移行のためのスクリプトの改造に着手しようとしてエディタで開いてみたんだけど特にWordpress側の方が書いてある行数とかがだいぶ違う。これバージョンが違うな．．（当たり前）と思い、内容を読んでどこに相当するのか判断する事を試みたけど、やっているうちに「まて。スクリプト書けないのに当て推量でそんな事して大丈夫か＞俺」テキな問題に思い至り。MTからWPの移行というテーマはジャイロキャノピーのディスクブレーキ化とかインジェクション化．．とかと比べれば遥かにポピュラーな問題なのできっと先駆者が何かツールや方法を紹介しているだろうという事で、改めて先にあげたリンク先のタイトルの「WordPressへのURL込みの移行方法」という文字列に2.6とか2.7とかを加えて検索をしてみたところ、更に修正された情報のいくつかを見つけることができた。
中でもテキストエディタを使う事を前提にしているという点で自分的には http://blog.dacelo.info/wordpress/entry-283.html にある方法が取っ付きやすく何か問題が出た場合にも自分で対処できそうだという事で、これからもう少し調べた上で（謎）実行してみようと思っている。とりあえずMT側のスクリプトは問題ないだろうという事で書き換えた。あとはこのページにある記述のWPのバージョンが2.6であるから、俺がインストールしたVer2.7との間で修正すべき点がないか調べてみる事ぐらいだろう。（WP2.6のパッケージも落としたものがあるのでそちらで移行してからバージョンアップすればよさそうなものだがそこで横着をするためにウロウロするのはかえって自体をややこしくしそうな気がしている）
@2009年4月23日木曜日 12:05:41

パーマリンクの形式だけを直してインポートすると「wpにインポートされた順番」に従ってpost_idが振られてしまうようだ。これはMTのデータが持っているpost_idを継承しないとパーマリンクが変わってしまう。

もういちど先にあげたリンクの内容をよく読んで理解しなければならないようだ。
便利さを追求してこそのコンピュータライフのはずなのになんと面倒なことよ。
不屈。粘着。@2009年4月22日水曜日 16:15:18

• 現状のwpの記事をバックアップ（wp形式？）
• MTにあるデータ以前の日付のエントリを削除してもう一度別名でwpをバックアップ（wp形式？）
• スクリプトを改造してMTのpost-idを継承できるようにする。
• MT3から「現状」のデータをtextで吐き出す。＞ロック
• 編集用のファイルとしてそこからrtfフォーマットに別名で保存
• 画像パスを修正
• もう一度textフォーマットで別名保存（元の書き出したログは上書きしない）
• Wordpressのディレクトリ以下にpublishするのではなくルート（というか上位）ディレクトリに吐くテスト
• パスを修正した編集済みRTFファイルから一ヶ月ずつ（あるいは三ヶ月くらい？）小分けのtextファイルに書き出し別名保存。（このとき改行はCRではなくLFに）
• ４月以降の手書きいれたデータやMT4でのデータを入れ込む
• パーマリンクの照合（複数の方法で更新していた4/16以降を重点に任意に抜き出して確認）

今とりあえず最新から今年２月の分まで過去ログをインポートした状態で各モジュールの動作やリンク状態をチェックしているところ。Movabletypeからのインポート時にPermalinkが変わってしまうという件 [Link] を検索で見つけて気にしていたのだけれども、MovabletypeやWordpressのスクリプトを書き換えるという部分の操作については最新のWP2.7.1においてはインポートの機能が改善されているようで特に書き換える必要もなくMT3.3.4からエクスポートしたデータをフツーに読み込んで、単にパーマリンク構造を設定画面から書き換えるだけでよかった。
ここで公開していたMTのweblogではパーマリンク構造をデフォルトではなくarchives/%post-id%.htmlの形式に書き換えていたのでwordpressでもその形式で出力されるように書き換えた。その際最後に「.
html」を書き加える必要がある事が理解できずしばらくはまった事を書いておく。（恥）リンク先にも書いてあるように.htmlを書き加えても別に静的なhtmlとして出力される訳ではなく単にurlの一部の文字列として扱われるだけだけど。

MTの時は画像データなどのコンテントを blogpath/archive 以下のディレクトリにおいていたけどこれだとツールの乗り換えのためのテストの時にいちいちエントリの中のパスの部分を書き換えなければならなくなり面倒なのでこの機会に上の階層に移動させて、エクスポートしたエントリの中のパスをそれにあわせてテキストエディタで一括置換してやってから月毎に分割してそれをwpに読み込ませている。
なにぶんまったく無知だった頃に勢いだけでMTをインストールして、今回また何もわからないのにいきなりWPでphpとやらと格闘しているので不細工な部分が多いが、まぁ詳しい方はワハワハ笑いながら読んでください。たぶんテキストエディタでの正規表現検索とかマクロとかがもっとちゃんと書けたりperlとやらが少しでも理解できればいまやっている作業は自動化できそうな気がするが、まぁ、すこしづつ調べながらスクリプト云々以外のどういう構造にしておくべきかとかその辺りの事柄を考えつつやっていくのが俺のレベルにはあっている。
初めてニフティ（笑）のディレクトリで「ホームページ」（死語）を作ろうとしていきなりDreamweaver/ Fireworks Studio Suits　を買ったという話をした時にNanae師匠が「百年早いんじゃぁ！タグも理解できないうちにそんなもん使ってたら一生htmlなんか書けないよ。この腐れ○○○」とマジギレしていたけど。たぶんあそこでいきなりオーサリングソフトなんか使っていたら今こんな事とてもできなかっただろうなぁ．．．と思って彼女にはほんとに感謝している。Dreamweaver Studio Suits Ver.3 & Ver4 はどちらも未開封のままうちで記念碑になっている。（合わせて10万円以上したのに．．．）
@2009年4月22日水曜日 12:43:00

現状では2009/2月までのインポートを済ませて様子を見ているのだけれども。どうもテンプレートのphpの部分をいじってタイトルのないエントリーに関しては何か便宜的なキャラクタを（例えば*とか）出力してそれをリンクhrefのアンカーにするしかなさそう。あるいはエントリーIDを使うか。

いま思い出す限りでは次のクラスや要素

• table関連（モニターチャートで使用）
• class: mincho
• class: quote
• class=”quote”が設定されていないblockquote要素についてはborderを表示しないように変更する

あと

• line-heightをもう少し拡げる
• 標準フォントを丸ゴシック系に
• いらない要素を削除

などの措置を行ない可読性を高めるべし。

この問題を解決するためには配布パッケージ plainscape/archivephp の36-38行目の

<div class="entry">
<?php the_excerpt(); ?>
</div>


の部分を

<div class="entry">
<?php the_content(); ?>
</div>


と書き換えて保存してやればいいようだ。（まぁそのようにした結果改善されている）

以上覚え書きとして。

記事アーカイブのリスト表示の場合はタイトルなしだと「記事ID」が表示されるようになっている事までは調べられたのだが（というか挙動をみればそれはわかる）、ちゅーことは、同様の場合にコメントIDを取得してそれを記事タイトルのかわりに渡すモジュールを書けということになるんだろうか。それぞれ。

コメントAuthorは表示されているから、それに並記する形でコメントIDなり登校時間なりが表示されるようにタグうちで解決できるレベルならいいのだけれども。（PHPでそれを呼ぶことはないだろうから表示さえできればいい）

改行はLF（unix形式）に

わかってしまえば当たり前なんだけど、wordpressのCGIに喰わせるテキストは改行がLFになっていないともとのデータテーブルの区切りを正しくCGIが判定することができないので一個のエントリデータとしてインポートされてしまう。

インポートするデータはひと月毎に別ける。

移行前のMovabletypeでのweblog運営がある程度長い期間に渡った場合にはエクスポートされたテキストがwordpressのインポート機能がサポートしている8MBのサイズ上限を超えてしまうことがある。その場合にはエクスポートされたテキストを分割しなければならないが、その際「月毎」ないしは「数ヶ月毎」できちんと別けておくとインポートしてからの編集が楽。なぜならエントリの編集のページで「月毎」のフィルタリング機能が標準であるから、万が一インポートに失敗して重複データができてしまった場合などに削除がやりやすいと思う。（まぁ気分的なものではある）
特に最初にインポートする時にはまず直近の一ヶ月ないしはにヶ月分をインポートしてみて表示を確認し、問題があればテンプレートを編集して公開ページの昨日を修正してみてから本格的に残りのデータをインポートした方がよいと思う。その方がすぐに消すことができるから気が楽だ。