dannna_o Blog

なんとか画像を含む投稿はできるようになったがまだ挙動が安定せず完全に解決したとはいえない状況。

一番最初にはまったのはおそらく単純にアップロードしようとしていたディレクトリへのフルパスを間違えていたこと。普段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 にであれば問題なくアップロードできる状態。

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

今後の移行作業Todo　。

• 読み込みテキストの区切りのエントリが欠損しているので順次手作業で追加
• 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

寝ながらいろいろ考えた結果（ほんとは寝付く前とか目覚めの頃に考えた事は言うまでもあるまい）ようやっとWordpressのパーマリンク形式にpost_idが推奨されていない理由が理解できた。Wordpressではデフォルトでエントリの自動保存という機能が設定されていて、これが自動保存された記事のリビジョン毎に新規にpost_idを振っていくらしい。挙動を確認していないので頭で考えた事だけど、例えば編集を破棄してあるいは中途の状態まで戻って更に編集してそれを保存したりすると、実際に出力に使用されるデータのpost_idは必ずしも不変ではないのではないかと。となれば、パーマリンクのパスにはpost_idではなくpost_nameを使った方が無難ということになる。それも、少なくとも同じ yy/mm/dd 以下では一意に特定のpost_idと対照できるpost_nameである必要があるだろう。 つまり仕様というかポリシーとしてpost_idをPermalinkに含める事に開発側は積極的ではなさそうだ。なれば、おそらくVer2.8以降も0paddingには対応しないようにも思う。

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

改めて更に調べたら現状でWordpressのパーマリンク構造の記述に使えるタグでは post_id のパディングに対応していないっぽい。そうするとMTからのエクスポートtextに post_id と Permalink の両方が記述されていた場合にどちらが生きるんだろう。不安。
まぁ試してみるか。（謎）　@2009年4月23日木曜日 16:35:36

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

いくつか問題が出た。まず一つ目。MT3からエクスポートしたtxtファイルの内容のパーマリンクのパスが実際に今まで公開されていたものと違う。これはしばらくはまったけれども、結論から言えば、公開されているcgiの改造方法は MTEntryPermalinkの値をPERMALINK:以下に書き出すというものな訳だけど、トラブルの発端の（厳密には発端じゃないが）MT4との混在でMT3がぶっ壊れた時に、パーマリンクの対象は Individual Archive に設定していたんだけど、その個別エントリのURLがMT3の時に指定していたゼロパディングありのpost_idであったはずのものが、どうやらMT4との衝突でエントリーにタイトルがある場合は エントリータイトルの概略.html みたいなものに置き換えられてしまっていたらしい。
バックアップテキストを書き出す時にはその時点でのアーカイブ設定が有効になるから、トラブルが起こって以後の書き出したテキストではタイトルのあるエントリーについては連番ではなくタイトルを反映したパスに書き出されたためにその分で連番の数が少なくなり、結果パーマリンクがすでに公開されている分とあわなくなっていたということだった。
ちょっと文章としてこなれていないのですまないが記録のために今ここに書いておく。

対処した事は。トラブル後に書き戻した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

昨晩は久方ぶりにkawolさんのライブに行ってきた。「爆音」だというので。（謎）
それについてはあとで書くつもり。で。

戻ってきて一眠りしてから昨日書いた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以降を重点に任意に抜き出して確認）

アピアランスの調整は今後必要だけれどもとりあえず読めるというレベルまでは持ってきた。＞Wordpress

今とりあえず最新から今年２月の分まで過去ログをインポートした状態で各モジュールの動作やリンク状態をチェックしているところ。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

検索結果の表示画面でも、パーマリンクへのリンクが（変な言葉）タイトル要素に与えられるテンプレートになっているために検索結果の概要からパーマリンクに飛ぶことができない。
同じ問題はMTの時にも起こった。どうもweblogツールの基本的な考えとして「エントリーにはタイトルあるべし」ということらしい。んーむ。

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

旧weblogに定義した独自クラスを新しいWPのテーマの参照するスタイルシートに書き加える事。

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

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

あと

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

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

ダウンロードしてインストールした状態で plainscape theme では アーカイブ表示で「概要」を表示する仕様になっているために、タイトルなしの写真ポストなどでは肝心の要素が表示されない。

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

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


の部分を

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


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

以上覚え書きとして。

俺の癖として戯れ言の類いを書く時にはタイトルを書かずに「タイトルなし」のままでpostする事が多いのだけれども（チラ裏にタイトルなんかつけないだろう）そうするとそこにコメントが付いた時にWordpressのテーマで使えるタグのレベルではそれを表示できないっぽい。いろいろ調べているのだけれども。

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

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

自分も現在つまずきながら試行中なので、現時点までにわかったポイントをいくつか下に書いておく。

改行はLF（unix形式）に

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

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

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