そんなんだから MAMP 2 をインストールしようかと思ったけれど、ちょっと不安定なところもまだあるようなので、MAMP 1.9.6.1 （無料の方）をインストールしてみることにした。

ちなみに無料版との Pro 版との違いは、ドキュメントルートを複数設定できることらしい。でも httpd.conf をいじれば、Pro にしなくても複数サイトの管理ができるみたい。（なんでわたし Pro 版を購入したんだろうなぁ。）

MAMP のインストール

公式から MAMP & MAMP PRO 1.9.6.1 をダウンロード。1.9 にはPHP 5.3 の iconv のバグがあるらしく、1.8.4 を勧めているサイトが多い。とりあえず、1.9.6.1 を使って問題があったら 1.8.4 にバージョンダウンしよう。このダウンロードが実は一番時間がかかった。

ダウンロードした ZIP ファイルを解凍して、イメージディスクをダブルクリック。許諾画面が出てくるので「Agree」をクリック。

今回は試しに PRO 版ではない方をインストールするので、MAMP フォルダを Application フォルダにドラッグアンドドロップ。

インストールが終わりアプリケーションフォルダから MAMP を起動すると次のページが現れて「ブラウザで MAMP へようこそ」というページが開く。

これで MAMP のインストールは成功。

MySQL のデータベースを作成する

WordPress をインストールするために、MySQL にデータベースを作成する。

「phpMyAdmin」タブをクリックして「新規データベース」に適当な名前（例：wp01）を入力。あとはデフォルト設定で「作成」をクリック。

この画面が表示されれば成功。

WordPress のインストール

WordPress 公式サイトからインストールしたい WordPress のバージョンをダウンロード。ダウンロードファイルを解凍した「wordpress」フォルダを「アプリケーションフォルダ」>「htdocs」の中に置く。フォルダの名前はわかりやすいように変更してOK。複数設置する場合は適当な名前のフォルダを「htdocs」に作ってその中に入れる。

ブラウザで「http://localhost:8888/wordpress/」にアクセス。URL の最後の「/」は忘れずに。「wp-config.php ファイルが存在しないようです。スタートするにはこのファイルが必要です。」とエラーメッセージが出るので、「設定ファイルを作成する」をクリックして「wp-config.php」を作成する。

データベースの詳細を入力し「作成する」をクリック。

• データベース名：「MySQL のデータベースを作成する」でつけたデータベース名
• ユーザー名：root
• パスワード：root
• データベースのホスト名：localhost
• テーブル接頭語：そのままでも適当に変えてもよい。

これ以降は WordPress のインストールと同じ。ただ「このサイトが Google や Technorati などの検索エンジンに表示されるのを許可する。」のチェックは外しておく。

「成功しました！」と表示されれば終了。

「http://localhost:8888/wordpress/」でトップページにアクセスできるので、ブックマークするなりすればよい。

これでローカル環境で WordPress がいじれる。

画像ファイルをこのサイトを置いているサーバーにそのまま移して、SQL でリンク先を変更するのが一番楽なのだが、サーバーの負担を減らすためとページの読み込みを早くするために、Picasa ウェブアルバムに画像を置くことにした。

Picasa ウェブアルバムのイメージの URL とサムネイルサイズの指定

昨日一般公開された Google+ に登録すると、長辺が 2048 ピクセルまでの画像は容量無制限で Picasa ウェブアルバムにアップロードすることができる。これを機に公開している写真の画素数を少し大きくすることにした。Blog 初期の画像は 120 × 160 ピクセルとかで今だと携帯でみても小さいから。

画像 URL は Picasa ウェブアルバムで写真を表示したとき、右側に表示されるメニューの「この写真へのリンク」をクリックすると表示される「画像を埋め込み」にある文字列中のURLである。下記の文字列の太文字部分。

<table style="width:auto;"><tr><td><a href="https://picasaweb.google.com/lh/photo/8FJQ_ukVhC07cfrM2BgaAA?feat=embedwebsite"><img src="https://lh5.googleusercontent.com/-AXLiMtqVq1s/TnI0GeZll7I/AAAAAAAAqas/qiwrR7HupwM/s144/20110913_1.jpg" height="108" width="144" /></a></td></tr><tr><td style="font-family:arial,sans-serif; font-size:11px; text-align:right">送信者 <a href="https://picasaweb.google.com/113249731657718795722/Blog_images_picasa?authuser=0&feat=embedwebsite">blog_images_picasa</a></td></tr></table>

【表示例】

送信者 blog_images_picasa

表示される画像の大きさを変更することもできる。Picasa ウェブアルバムはアップロードした時点でサムネイルがいくつか作成されるので、数値を指定してやればリサイズなしでブラウザでレンダリングされる。作成されるサムネイルの長辺サイズは下記。

72/144/200/288/320/400/512/576/640/720/800/912/1024/1152/1280/1440/1600

指定の方法はアルファベット＋サムネイルのサイズ。下記の URL の s144 の部分。

https://lh5.googleusercontent.com/-AXLiMtqVq1s/TnI0GeZll7I/AAAAAAAAqas/qiwrR7HupwM/s144/20110913_1.jpg

指定数値の頭につくアルファベットは3種類あり、「s」が長辺サイズ、「w」が横幅サイズ、「h」が縦幅サイズみたい。s144 の部分を削除すると、アップロードしたオリジナルサイズの画像を表示することができる。

オリジナルサイズを表示する URL
https://lh5.ggpht.com/-AXLiMtqVq1s/TnI0GeZll7I/AAAAAAAAqas/qiwrR7HupwM/20110913_1.jpg

Picasa Express x2 : Picasa の イメージを WordPress に埋め込むプラグイン

Picasa Web にアップした画像を WordPress に貼り付けるプラグインはいくつかあり、Picasa Image Express が有名みたい。でもこれ公開アルバムからしか写真を選択できないみたいなので、非公開アルバムからも写真が選択できる Picasa Express x2 を使うことにした。

しかし問題発生。Picasa Express x2 をインストールして設定を行おうとしてもなぜか「変更を保存」のボタンが出てこない。それで Picasa Express x2 のソースをあたってそれらしきバグ？を見つけたので修正した。picasa-express-2.php の 1394 行目あたり。バージョンは 1.5.2。

【修正前】

$this->make_settings_row(
	__('Large image size', 'pe2'),
	'<label><input type="checkbox" name="pe2_large_limit" value="'.$option.'" '.checked(($option)?1:0,1,false).' /> '.__('Limit ','pe2').'</label> '.
	'<label><input type="radio" name="pe2_large_mode" class="pe2_large_limit" value="w" '.checked($mode[1], 'w', false).' '.disabled(($option)?1:0,0,false).' /> '.__('width','pe2').'</label> '.
	'<label><input type="radio" name="pe2_large_mode" class="pe2_large_limit" value="h" '.checked($mode[1], 'h', false).' '.disabled(($option)?1:0,0,false).' /> '.__('height','pe2').'</label> '.
	'<label><input type="radio" name="pe2_large_mode" class="pe2_large_limit" value="s" '.checked($mode[1], 's', false).' '.disabled(($option)?1:0,0,false).' /> '.__('any','pe2').'</label> '.
	__(' to ','pe2').
	'<input type="text" name="pe2_large_size" class="pe2_large_limit" style="width:60px;" id="pe2_large_size" value="'.$mode[2].'" '.disabled(($option)?1:0,0,false).' />'.
	__(' pixels','pe2'),
	sprintf(__('Value \'/%s\' will be used to limit large image'),"<span id=\"pe2_show-large-size\">$option</span>"),
	'',
	'id="large-limit-message" style="display:'.(($option) ? 'block' : 'none').';"'
);

【修正後】

$this->make_settings_row(
	__('Large image size', 'pe2'),
	'<label><input type="checkbox" name="pe2_large_limit" value="'.$option.'" '.checked(($option)?1:0,1,false).' /> '.__('Limit ','pe2').'</label> '.
	'<label><input type="radio" name="pe2_large_mode" class="pe2_large_limit" value="w" '.checked($mode[1], 'w', false).' '.($option?"":"disabled").' /> '.__('width','pe2').'</label> '.
	'<label><input type="radio" name="pe2_large_mode" class="pe2_large_limit" value="h" '.checked($mode[1], 'h', false).' '.($option?"":"disabled").' /> '.__('height','pe2').'</label> '.
	'<label><input type="radio" name="pe2_large_mode" class="pe2_large_limit" value="s" '.checked($mode[1], 's', false).' '.($option?"":"disabled").' /> '.__('any','pe2').'</label> '.
	__(' to ','pe2').
	'<input type="text" name="pe2_large_size" class="pe2_large_limit" style="width:60px;" id="pe2_large_size" value="'.$mode[2].'" '.($option?"":"disabled").' />'.
	__(' pixels','pe2'),
	sprintf(__('Value \'/%s\' will be used to limit large image'),"<span id=\"pe2_show-large-size\">$option</span>"),
	'',
	'id="large-limit-message" style="display:'.(($option) ? 'block' : 'none').';"'
);

どうも disabled(($option)?1:0,0,false) がうまく動いていなかったようなので、すべて ($option?"":"disabled") としました。画像の最大を設定する項目（Large image size）の箇所でバージョン 1.4 にはないので、1.5 から付け加えられた機能みたい。

ちなみに、Picasa ウェブアルバムの画像 URL のサブドメイン部分に規則性が発見できなかったため、（元ファイルから大きな画像を Pixelmater で再度作成しつつ）画像はすべて手作業で貼り直しだった。サムネイルは以前 120 × 160 ピクセルだったのだけれど、PIcasa で自動的に生成されるサムネイルにそのサイズがなかったので、s200 で指定できる 150 × 200 ピクセルのサムネイルにした。

暇を見つけて、WordPress でアップロードした画像も Picasa ウェブアルバムに移そうかと思っている。WordPress はデータベースにおいて、記事管理と画像管理を同じテーブルにて行っているので、画像を削除すればデータベース自体も少し軽くなるはず。

これまで行った対策は下記。
→Google ウェブマスターツールにて「タイトルタグの重複」がたくさんある
→WordPress でタイトルタグの重複を回避する

今回重複があったのは携帯表示用プラグインとして導入している Ktai Style のコメントや画像の拡大ページが同じタイトルタグでインデックスされてしまっているみたいです。URL の最後に「?view=co_list&img=link」「?view=co_post」とかのパラメータがついているのです。Google アナリティクスが携帯にも対応したからなのでしょうか？

まあ、とりあえずタイトルタグの重複を回避するように試作してみました。

携帯ページをインデックスしてしまっているということは、携帯で表示されるページに「link rel=”canonical”」を入れればいいんじゃないかと邪道な手段に走りました。（本来なら各ページに個別のタイトルを付けるのがベストと思われます。）上にも書いたように使っている携帯用表示プラグインは Ktai Style です。手順は下記の通り。

1. 「link rel=”canonical”」をヘッドタグに挿入するプラグインをインストールする。
   例：Canonical URL’s for WordPress
2. Ktai Style のテーマの「header.php」にヘッドタグ内にいろいろ表示する Ktai Style 独自のタグ「<?php ks_wp_head(KTAI_DO_PC_HEAD); ?>」を <head> タグ内に書く。
   これをしないと「link rel=”canonical”」のタグが Ktai Style で表示されたページには現れない。
3. この状態だと <head> タグにいろいろ追加されすぎるので、Ktai Style のテーマの「functions.php」に下記を記述し、いらないヘッドタグを表示しないようにする。
   remove_action(‘wp_head’, ‘index_rel_link’);
   remove_action(‘wp_head’, ‘parent_post_rel_link’, 10);
   remove_action(‘wp_head’, ’start_post_rel_link’, 10);
   remove_action(‘wp_head’, ‘adjacent_posts_rel_link’, 10);
   remove_action(‘wp_head’, ‘feed_links_extra’,3,0);
   remove_action(‘wp_head’, ‘add_css’);

これで1か月ほど様子をみたところ、タイトルタグの重複が約700件から約500件に減りました。クロールが進むにつれて次第にタイトルタグの重複は解消されていくのではないかと思っています。

サーバー移転は何も考えず、今の環境をそのまま移動させました。幸い PHP も MySQL 移転前後のサーバー共に同じバージョンが使えたから。本当は WordPress のプラグインの整理とかしたほうがいいんだけど。

手順は下記のような感じ。

1. 移転前のサーバーから FTP で全ファイルをダウンロード。
   .htaccess のファイルを忘れずに。
2. 移転前のサーバーから MySQL のデータをエクスポート。手順は以下と同じ。
   →MySQL4 から MySQL5 へ移行（ハッスルサーバーにて）
3. 移転後のサーバーへ FTP にて全てのファイルをアップロード。
4. 同じく MySQL もインポート。
5. wp-config.php のデータベースサーバーの設定を新しいサーバーに変更。
6. ドメインのネームサーバーを変更。

以上の作業をして、DNS が浸透するのをひたすら待つ。

ちなみに移転後のサーバーでサイトがきちんと動作しているか確かめるために、Hoster というソフトを使いました。使っているパソコンでのみドメインを指定したときに参照するIPアドレスを変えられるみたいです。便利です。

ということで、Advanced Permalinks をインストール。管理画面の設定のパーマリンクに上部メニューが追加されて、その Posts というメニューを選択すると、Start ID と End ID とパーマリンクの設定ができるので、今まで使っていたパーマリンクを設定しておいた。そしてデフォルトには、これから使うパーマリンクを設定。

この設定だけだと、カテゴリの表示がうまくいかなかったので、カテゴリベースを設定（空欄だとうまく動作してくれないよう）、Advanced の Author pages と Category pages にもデフォルト値を設定（同じくなぜか空欄だとうまく動作しない）、Start ID に次の記事の番号と End ID に -1 を設定して、新しいパーマリンクを設定、これでやっとうまく動作してくれました。

今までは投稿日時を URL にしていたのだけれど、これからは、「年/月/投稿スラッグ」という形にしました。わたしの投稿頻度だと、日にちまで絞らなくてもそこそこのレスポンスで記事を探し出してくれるかな、と。あと、URL の最後にスラッシュを付けるか付けないか迷ったのだけれど、「クールなURIは変わらない」を参考に最後のスラッシュはなしにした。「クールなURIは変わらない」には件名を URI に含むのは最初はうまくいくけどあとから破綻する的なことが書かれているけど、破綻したらまたその時考えればいいや、と思うことにした。要するにブックマークした記事とかが 404 になるのを避けた方がいいっていうことだから、そのときリダイレクトかけます。

また、Advanced Permalinks には古いパーマリンクを新しいパーマリンクにリダイレクトする機能もついているので、投稿スラッグを英単語化できたら、その際には全記事リダイレクトするかも。ドメインの www も取りたいし。

Advanced Permalinks の導入によって、サーバー内の処理が増えてアクセスが多少遅くなると思うけど、そこらへんは目をつぶることにします。ということで、この記事をテストを兼ねて投稿するのです。

※追記
パーマリンクの設定を間違えると、投稿時に誤ったパーマリンクで twitter と連携しちゃうのね。うーん。手順等を要検討だなぁ。

思い腰を上げたのは twitter との連携アプリの twitter tools が twitter へ投稿しなくなったから。これも OAuth の弊害だね。最新版の 2.4 じゃないとだめみたいで、それの必要条件が WordPress 2.9 以上だったのよ。

ついでにプラグインもアップデート。

そして Ktai Style と WP Super Cache の設定でつまずく。なんだか設定の方法が以前と変わっているよう。
→Yuriko.net：Ktai Style WP Suer Cache と併用する場合

ktai_style/patch-supercache-ktaistyle.php ファイルを WP Super Cache 配下の plugins ディレクトリーに配置します。通常は wp-content/plugins/wp-super-cache/plugins/ というパスです。

「patch-supercache-ktaistyle.php」を wp-super-cache の plugins フォルダに入れろってことなんだけれど、肝心の「patch-supercache-ktaistyle.php」が見つからない。名前から察するところによると、「patches/supercache-plugin-ktaistyle.php」みたい。これを説明どうりに設定したら、無事に携帯から携帯専用サイトが見られるようになりました。

しかし、日々進化しているプラグインやらをきちんとメンテして、少しでも設定が楽になるように工夫している開発者の方々はすごいなぁ、と改めて思った。

とりあえず記録のみ。何か不具合とかありましたら、コメントくださるとありがたいです。

＊追記＊
「supercache-plugin-ktaistyle.php」を使うとWP Super Cache ステータスが強制的に Half On に変更されてしまう。
そこで、下記のサイトを参照して設定し直しました。
→Hinemosu：WP Super CacheとKtai Styleを併用する方法

めんどくさいなぁ、と思って放っておいたのだけれど、時間帯別アクセス数の推移がおかしい。今までの経験上、訪問者のピークは22時から24時くらいの間になるのだけれど、12時以降横ばい。もしかして、サーバーの限界を超えたのか？　とサーバー移転を検討してみたものの、まずは原因の切り分けをしてみよう、というところに落ち着いたのです。

なので、その第一弾といて、データベースサーバーを移転してみることにしました。サーバーが違えば、レスポンスが上がるのではないか、という期待を込めて、同じハッスルサーバーの MySQL5 のデータベースサーバーへデータを移してみました。

以下、その手順と覚え書き。

概要は大ざっぱにいうと下記のよう。

1. phpMyAdmin で MySQL4 のデータをデフォルト設定にてファイルにエクスポート
2. phpMyAdmin で MySQL5 へインポート
3. wp-config.php のデータベースサーバーの設定を変更

文字化けしたり、容量オーバーで読み込まなかったりといろいろ試行錯誤した結果、一番簡単な方法を見つけたのでポイントをメモ。

1) phpMyAdmin の文字コードが（ログインするときに） UTF-8 になっていることを確認。
これを忘れるとハッスルサーバーの場合デフォルトは EUC になってしまうので注意。

2) スキマーの問題。
ログインネームを選んでエクスポートすると、データベース全体がエクスポートさて、ユーザーネーム等のテーブルを管理する情報（スキマー）もエクスポートされ、インポートするときにユーザー名が競合して MySQL5 にインポートできないらしい。なので、データベースを選んでエクスポートするのではなく、すべてのテーブルを全て選択してのエクスポートをおすすめします。そうすると、スキマーはエクスポートされません。

3) エクスポートしたファイルが 2MB 以上だと、ハッスルサーバーではインポートできない。
初めから gzip なんかでエクスポートした方がよい。（圧縮なしファイルを Mac にて zip にしてインポートしようとしたら、「Compressed size is not equal with the value in header information.」というエラーが出ました。Windows だったら多分大丈夫だと思います。）データベース全体をエクスポートしてしまうと、スキマー情報を消すために、テキストエディタでエクスポートした SQL ファイルを開く必要が出てしまうので、2) で紹介した方法をとるのがベスト！

この3つの点に気をつければ、エクスポートしたファイルをそのままインポートして、wp-config.php の設定を変えるだけ。データベース移行も楽々ですね。

参考にしたのは下記サイト。（微妙にやり方が違います。）
→Y&M blog + L：WordPress　2.9アップグレードの為のMySQL5データ移行
→アフィリエイトでお小遣い：ハッスルサーバーでWordPress2.9移行完了

それは、Ping 送信を最適化するプラグインです。

Ping 送信最適化プラグインを入れる理由

WordPress には以前から Ping を送信するのに失敗する確率が高いという特徴があります。また、新規投稿時だけでなく、記事を修正するときにも Ping を送信しています。ブログの本文を1文字変えても、設定された URL へ更新 Ping を飛ばしているのです。考えただけで怖ろしいですね。知らず知らずのうちに Ping スパマーになっているのです。それ故、Yahoo! ブログ検索、および、goo ブログ検索からは確実に嫌われています。送信はできるけれど、インデックスはしてもらえないようです。なので、初めての記事を書く前に、Ping 送信をする前に、WordPress をインストールしたら一番最初に入れるべきプラグインは Ping 送信最適プラグインだと思うのです。Ping 送信を最適化するプラグインとは、記事を修正したときには Ping を飛ばさず、新規投稿時のみ送信してくれるプラグインのことです。

以下は具体的なプラグインを紹介していきます。（MaxBlogPress Ping Optimizer 以外は WordPress 2.9.1 にて正常に動作することをデフォルトテンプレートにて確認いたしました。）

Smart Update Pinger

Ping 送信最適化プラグインの元祖。しかし、予約投稿時には設定した時刻に WordPress 標準の Ping 送信機能が使われるので、ログに残らないのが欠点。（記事の予約投稿の際、記事の投稿を予約した瞬間に Ping を送信してしまうことはないのでご安心を。）予約投稿時にログに残らないことが気にならなければ、このプラグインで充分だと思います。最終バージョン 2.0 (2006.2.18)

Smart Update Pinger 日本語版

Smart Update Pinger を日本語化したプラグイン。機能的には Smart Update Pinger と同じ。日本人にはこちらの方が馴染みやすいかもしれませんね。

Ultimate Plugins Smart Update Pinger

Smart Update Pinger を元につくられたプラグインで予約投稿時のログにも対応（Smart Update Pinger の後継版）。ただしダウンロードにメルアド登録が必要。プラグインを有効化するときにエラーが出ることがあるが、「ultimate-plugins-smart-update-pinger.php」の先頭行の <? を <?php にすると正常に動作する。（WordPress 2.9.1 でも動きました。）最新バージョン 3.1

MaxBlogPress Ping Optimizer

アクティベーションが必要。（なので動作確認を行っていません。）最終バージョン 2.2.5 (2008.11.16)

cbnet Ping Optimizer

MaxBlogPress Ping Optimizer 2.2.5 を元に作られたプラグイン。Ping 送信のログ管理に新に「xxx-cbnetpo_ping_optimizer」というテーブルが作られてしまう。（リリース日が新しいからといって、このプラグインを使ったら、Yahoo! ブログや goo ブログにインデックスされることはないと思われる。なぜなら、Ping のユーザーエイジェントが 「WordPress」であることで弾かれていると推測されるから。）最新バージョン 2.3.1 (2010.2.3)

ちなみに、あさこんは Ultimate Plugins Smart Update Pinger を使用しております。Yahoo! ブログ検索や goo ブログ検索にインデックスさせるため、多少の施策を施しておりますが。詳しくは下記の記事を参考にしてください。
→WordPress から Yahoo! ブログ検索に Ping を送信するプラグインの改造方法
→【まとめ】WordPress を Yahoo! ブログ検索させる方法 その10【追記あり】

恥ずかしながら、わたくし、あさこんは、MySQL のバージョンを4から5に上げるのが面倒で未だ 2.8.4 のままなのです。なので、Ultimate Plugins Smart Update Pinger が正常に動作していないのに気がついていませんでした！　すみません。

ですので、Ultimate Plugins Smart Update Pinger に改造を加えて Yahoo! ブログ検索にインデックスさせるための施策を公開していますが、たぶん正常に動いていないんじゃないかなぁ、というお知らせです。
→WordPress から Yahoo! ブログ検索に Ping を送信するプラグインの改造方法

近いうちに、検証環境を整えますので、それまでご猶予ください。何で動かないかわかるえらい方、どうかお力添えをください！　（確定申告が無事に終わるまでは、とりかかれないと思われます。）

フリーウェアとかを公開なさっている人のありがたさが身にしみた1日です。感謝せねば。

＊追記 2010.2.14＊
Ultimate Plugins Smart Update Pinger を WordPress 2.9.1 にて動かしてみましたが、正常に動作することを確認いたしました。Yahoo! ブログ検索へインデックスさせる施策を施しても正常に動作し、かつ Yahoo! ブログ検索にインデックスされました。
プラグインの有効化の際にエラーが出るという情報もありますが、「ultimate-plugins-smart-update-pinger.php」の先頭行の <? を <?php にすると正常に有効化できるようです。
→WordPress.org：[解決済み] Ultimate Plugins Smart Update Pinger について (3 件の投稿)

そこで、思ったのです。スパム対策として、コメント時にメルアド必須にしているけれど、これは実はコメントしてくれようとしている人を遠ざけているのでは？　と。せっかく blog を書いているのに、コミュニケーションできなかったら意味がないじゃないか、と。

そこでメルアド必須をやめたとして、スパムから守るための方法を探ってみました。

大きく分けて2つ。Captcha という方法で画像の文字列を入力することによって人間であることを確認する方法と、なんらかのアルゴリズムで bot じゃないと判断する方法。結局は前者の Captcha を採用しました。理由は、後者である WP-HashCash というプラグインでは、なんらかのアルゴリズムが JavaScript で書かれており、携帯からアクセスしたときにスパムと判断されてコメントできないからです。（他にも何らかの方法でスパムと判定するプラグインは存在するようです。）
→Cherry＆Lotus™：WP Hashcashが携帯からの書き込みをスパムと認識する件

Captcha のプラグインはたくさんあるみたいだけれど、代表的らしい SI CAPTCHA Anti-Spam を導入することにしました。これで少し様子を見てみます。

ということで、今後コメントいただくときは、多少面倒ですが文字列の入力をご協力お願いいたします。

週一でサーバー内のディレクトリにバックアップを取り、メールに添付ファイルで gzip の SQL ファイルを送信するように設定しました。これでデータが吹っ飛んでも大丈夫。FTP で上げてるファイルは基本的にバックアップがローカルにあるし。ローカルの HDD が壊れたらどうだって話にはなるけれど。

さて、次は WordPress を 2.9.1 にバージョンアップするために、MySQL を4から5へ上げないといけない。現在使用しているハッスルサーバーの MySQL のバージョンは4.0.27。しかし、WordPress 2.9 から MySQL が4.1.2 以上が必要になったのだ。ハッスルサーバーでは、MySQL の4と5の両方を提供してくれている。なので、MySQL の5へデータを移行いなくてはならないのである。作業的には、バックアップを取ったファイルを流し込んで、データベースを指し示す初期設定を変えてやればいいんだろうか？　調査せねば。正直めんどくさい。

結論からいうと、原因はPowerBookG4 を SSD 化するとこれくらい速くなるの投稿記事部分に Flash ビデオ (FLV) を表示するために JavaScript をベタ書きしていたことでした。Feed を全文配信していると、RDF では JavaScript だと解釈されないためにエラーになって白紙で表示されていたようです。

対策としては記事部分にベタ書きしてある JavaScript のコードを HTML のコメントアウトすることで解決しました。具体的には、下記の太字の部分を追加。

<script type="text/javascript" src="http://www.1010uzu.com/js/swfobject.js"></script><br />
<script type="text/javascript">
<!--
var s1 = new SWFObject("http://www.1010uzu.com/swf/jw/player.swf","ply","320","262","9","#FFFFFF");
s1.addParam("allowfullscreen","true");
s1.addParam("allowscriptaccess","always");
s1.addParam("flashvars","file=http://www.1010uzu.com/wp/wp-content/uploads/20091215_2.flv&#038;image=http://www.1010uzu.com/wp/wp-content/uploads/20091215_2.gif");
s1.write("JWplayer2");
//-->
</script>

これは、その昔 Netscape3 などが JavaScript を理解しないために、HTML 内に書くときにはコメントアウトするという技で、それを応用してみました。これから、投稿記事内に JavaScript を書くときは気をつけよう。（HTML 内に JavaScript を直書きするのは非推奨ですけどね……）

試しに Yahoo! ブログ検索で「トイレのうず」で検索してみると、策を施した当初は「スコアでの絞り込み」を「指定なし」にしないと検索されなかったのですが、2009年11月26日現在、「スコアでの絞り込み」を「中」にしても検索結果に表示されるようになりました。これからも質のよい記事を書けば「強」でも検索結果に表示されるようになるかなぁ。

通常問題のないコンテンツならば、1か月程度で「スコアでの絞り込み」が「中」になるようです。
→Kuwata’s Blog くわぶろ：Yahoo!ブログ検索の「スコアでの絞り込み」について

ちなみに Yahoo! ブログ検索にインデックスされるように WordPress に施した策については以下の記事を参照ください。
→【まとめ】WordPress を Yahoo! ブログ検索させる方法 その10
→WordPress から Yahoo! ブログ検索に Ping を送信するプラグインの改造方法

Google さんに聞いてみると同じ現象で困っている人がいました。
→WORDPRESS.OGR：Ktai Style と WP Super Cache の競合？Safari系でエラー

KtaiStyle の作者さんの回答によると、下記サイトを見て下さい、とのことでした。
→Yriko.net：WP-Cache および WP Suer Cache と併用する場合

その中でわたしがやってないこと、それは wp-cache-config.php に下記のコードを $cache_rejected_user_agent 設定の直後に付け加えることでした。（2009年10月2日にリリースされた WP Super Cache 0.9.7 では、45行目あたり。）自分の環境（Mac Firefox）から試してみて、大丈夫そうだったので、抜かしてしまいました。きちんとドキュメントを見ないとダメですね。

if (file_exists(ABSPATH. 'wp-content/plugins/ktai_style/patch-wpcache.php')) {
include ABSPATH. 'wp-content/plugins/ktai_style/patch-wpcache.php';
}

とりあえず、これで様子を見てみます。

もし、今後も表示がおかしいことがありましたら、ブラウザの文字コードを Shift-JIS にして見てください。携帯版ですがサイトを見ることができますので、コメント欄などにてお知らせいただけるとありがたく存じます。そして、これまで、表示がおかしなことがありましたことをお詫び申し上げます。これからも「トイレのうず」をよろしくお願いします。

今までは個別記事の前後記事のリンクだったのですが、日記とかじゃないのであまり意味がないということで、パンくずリストをつけるという結論に至りました。実際、訪問者のあしあとを辿ってみると、同じカテゴリ内の記事を探して、関連記事をクリックして行ったりきたりしている様子がうかがえたので。特に、Yahoo! ブログ検索に WordPress をインデックスさせる記事において。

使ったプラグインは、Breadcrumb Navigation XT の日本語版。コードを single.php に埋め込み、設定して終わり。不満なのは、複数カテゴリを設定いていても、1つのカテゴリのパンくずしか表示できない点だ。WordPress の場合、カテゴリは無限に設定できるのだけれど、その順位をつけられないため、メインカテゴリじゃないカテゴリのパンくずリストが表示されてしまう。

これから、カテゴリはなるべく1つに絞った方がいいんだろうか？

わたしが WordPress を導入しようと思ったときは、携帯系プラグインとキャッシュ系のプラグインがバッティングするとのことで、導入を見送っていたのですが、どうやらいろいろ改善されたようでとてもスムーズに導入することができました。

バッティングする理由は、パソコンから閲覧するのと携帯から閲覧するのでは違うページが表示されるので、どちらか先にアクセスした方の表示形式でキャッシュされてしまう。よって携帯で先にアクセスしたページはパソコンから見ても携帯ページが見えてしまい、またパソコンから先にアクセスしたページは携帯からみるとパソコンページが見えるので文字化けしてしまうのです。だから、キャッシュを見せる前にユーザーエイジェントもしくは IP アドレスで振り分ける必要があるわけです。

今回導入したキャッシュプラグインは WP Super Cache というプラグインです。ついほんの数ヶ月前までは携帯表示プラグイン（Ktai Style 等）と同居させる場合はいろいろと改変しなくてはならなかったみたいです。双方のプラグインが歩み寄り、とても簡単に WP Super Cache と Ktai Style が併用できるようになりました。それに伴い、ちまたに溢れている情報は古くなってしまったようで苦労されている方がいらっしゃいました。記事を読ませていただいて、大変参考になりました。
→Bloody Mary – blog：WP Super Cache に大はまり

以下、WP Super Cache (Version: 0.9.6.1) 導入手順。WordPress 2.8.4 にて。

＊パーマリンク設定をしていることが必須条件となります。
＊また Ktai Style を使用する場合は、先にプラグインを有効化する必要があります。（.htaccess への記述内容が変わってきます。）

1) WP Super Cache をインストール。有効化する。

2) WP Super Cache 設定画面 にて「on」を選択し、「Update Status」をクリック。
　Ktai Style を導入している場合は「Mobile device support.」にチェックをいれない。チェックを入れると、携帯サイトも一時キャッシュ (WP-Cache) してしまうようです。Ktai Style は機種ごとに違う HTML を作成しているので、キャッシュしてしまうと不都合が起きる。また、GA4K を利用している場合、アクセス数が正しく取れなくなる。（PHP のアクセスロジックが動かなくなるため。）

3) 設定画面下の方にある「Mod Rewrite Rules」の項目の「Update Mod_Rewrite Rules >>」をクリック。これで、「.htaccess」ファイルが書き換わります。

4) ログオフしキャッシュをクリアしたブラウザから、表示をチェックし HTML の最後の行あたりに以下の文字列があれば WP Super Cache がきちんと動作しています。
<!– Cached page generated by WP-Super-Cache on 20XX-XX-XX XX:XX:XX –>

5) 携帯からも表示チェックしてみましょう。文字化けしていなければ OK です。

以上、WP Super Cache と Ktai Style の同居も普通のプラグインの有効化と同じくらい簡単になってしまいました。便利でとてもよいことです。

設定関係は同じレンタルサーバーとのことで下記のサイトを参考にさせていただきました。
→日下部理子のブログ：「WP Super Cache」というプラグインを使ってみました

＊追記＊
一部のパソコンのブラウザにて、携帯サイトが文字化けして表示されていました。やはり、ドキュメントにあるように下記コードを wp-cache-config.php の $cache_rejected_user_agent を設定している直後に付け加える必要があるようです。
if (file_exists(ABSPATH. 'wp-content/plugins/ktai_style/patch-wpcache.php')) {
include ABSPATH. 'wp-content/plugins/ktai_style/patch-wpcache.php';
}

また WP Super Cache を無効にして再び有効にすると、wp-content/wp-cache-config.php がデフォルトのものになっていることので、有効無効を繰り返している方、wp-cache-config.php を確認してみてください。

Mobile Eye+ でも機能的には充分なのですが、Mobile Eye+ には脆弱性があるようです。
→ハンターリンク：Mobile Eye+ の脆弱性とか謝辞

これを修正するパッチも出ているようですが、それをするくらいなら、Mobile Eye+ の作者さんが推奨しているように、Ktai Style に乗り換えた方が早いかと。
→Yuriko.net：Mobile Eye+ パッチ

ということで、携帯でも Google Analytics が使える GA4K を設置し直したりして、一通りの作業を終えたのでした。

それで、いろいろ見直してみていたら、なんと、feed/rdf の時刻の表示の仕方がおかしくなってる。

<dc:date>2009-09-14¥JST12:32:01+09:00</dc:date>

おかしい、ってことで、feed-rdf.php を見直して見るも、おかしなところはなし。でも「JST」っていうのは日本標準時ってことだから、「¥T」がエスケープされてないよう。PHP で「T」はタイムゾーンを出力するらしい。たぶん原因は UTF-8 にて「¥」がバックスラッシュで保存されてないためだぁ。

→【PHP】Mac でバックスラッシュがエンマークになってしまう件【U.ico” de】

Yahoo! ブログ検索、goo ブログ検索ともに、RSS の時刻がちゃんとしてないがために「WordPress を 2.8.4 にアップデート」を最後にインデックスされてない。ちゃんと直したらまたインデックスされるかしら。

でも、RSS 2.0 の文字化けは相変わらず直らないなぁ。

いろいろ調べてみると、Twitter Tools の設定画面のユーザー ID を twitter に登録してるメールアドレスにするとうまくいく、という記事を見つけて試してみた。確かに、twitter への通知はうまくいくが新しいサイドバーの表示が更新されなくなった。よってボツ。
→北青山通信 – from aoyama：WordPressの記事投稿でTwitterの自動更新成功

それからまた調べてみて、記事 URL の短縮の設定をしてやると、うまくいく、というような記事を見つけて試してみる。
→ぶっちろぐ：Twitter Tools で短縮 URL を POST

確かにこのサイトの URL は長い。そこでこけてるのかも。そう思いながらこの記事を投稿テスト。

＊追記＊
テストがうまくいったのようなので、設定の手順を以下、追記。短縮 URL が投稿されてませんでした。どうしてだろう。短縮 URL も投稿できました。（でも原因は違うところにあったみたいです。）

1) bit.lyにてアカウントを取得。bit.lyの画面右上の「Sign Up」をクリックし、「Create a Free bit.ly Account」に必要事項（ユーザー名、メルアド、パスワード）を記入して「Sign Up」をクリック。画面右上の「Account」をクリックし、API Key（長い文字列です）をコピー。
2) WordPress 管理画面のプラグインにて、Twitter Tools 付属の「Twitter Tools – Bit.ly URLs」プラグインを有効化。設定の Twitter Tools 画面下部に「Bit.ly for Twitter Tools」の項目が出現する。
3) 「Bit.ly API key」「Bit.ly API key」を入力し、Save Setting をクリック。
新しい記事を投稿するときに、投稿画面下部にある Twitter Tools の項目のラジオボタンを「Yes」にする。

これで twitter への通知もできた。長い道のりでした。PHP を 4 から 5 にバージョンアップしたのも関係してるかも。

調査したところによると、どうやら Twitter Tools の一部の機能は動作条件として PHP 5 が必須のようです。WordPress 更新時の twitter への post、および twitter のログを WordPress へ投稿する機能など。だから PHP 4 を使っていた当サイトでは動作しなかったのですね。

あと、twitter への再投稿したい場合、カスタムフィールドの aktt_tweeted の値を「1」から「0」に変更して更新ボタンを押ばいいようです。テストで何度も記事を書かなくてすみますね。テストが終わったら「1」に戻しておきましょう。

ちょっとアップデートがおっくうだったので、2.7 から実装された自動アップデート機能を使ってみました。でも初めからこのサイトで試すのはちょっと勇気がいったので、まず試験的に動かしている WordPress から行ってみました。2.7 から問題なく 2.8.4 にアップデートできました。拍子抜けするぐらい簡単。Yahoo! ブログ検索にインデックスさせるために行っている改変も再現して Yahoo! ブログ検索にインデックスされることも確認。

で、本日ようやくこのサイトのアップデートを行いました。バックアップ取ってから（これが面倒なんだけれど、記事がなくなったら悲しいので）。更新ボタンを押してみた。あっという間に終了。そして、プラグイン類もアップデート。とりあえず、動いているよう。

そして、Yahoo! ブログ検索と goo ブログ検索にインデックスさせるために行っている改変も改めて行いました。調べたところ RSS ファイルに対して行った改変が全て新しいファイルに置き換わっているよう。wp-includes 内の feed-rdf.php と feed-rss2.php に対して下記の記事を参考にコードを書き換えた。こういうとき自分でまとめてると便利なんですよね。
→【祝！】goo ブログ検索インデックス！ 〜WordPress を Yahoo! ブログ検索させる方法 その8〜
→【解決】goo ブログ検索にインデックスされた日時が9時間遅れている件【RSS2 の時刻修正】

うまくインデックスされるかな？　確認も兼ねてこの記事を投稿。まあインデックスされても、悲しいかな、Yahoo! ブログ検索、goo ブログ検索経由で来る人はいないんだけれどね。