朝から日本震撼のニュースが飛び込んできました（言い過ぎ）が、WordPress の動作環境がバージョン3.2から PHP 5.2 + MySQL 5.0.15 以上となることが公式ブログで発表となりました。

英語の公式ブログをチェックしてなくて、ちゃんと情報が拾えるので助かりますねぇ。

さっそく自環境の状態をチェックしてしてみました。おでさんのところでは公式に案内されているHealth Checkの利用が紹介されています。どうやらこれは、まさにこのWordPress 3.2のバージョンチェックの為に存在するプラグインのようです。また、WordPress Japan コミュニティとしては、LAMP バージョンチェッカーでもいいのではないかということも書かれています。

どっちも入ってません。というかHealth Checkは当たり前ですね。

で、まだ先のWordPress 3.2でしかもこれからレンタルサーバーも乗換えするかもしれないという状況で、それだけのために新しいプラグイン入れるのも、何かなぁです。サーバーにインストールされているPHPとMySQLのバージョンを知りたいだけですもの。もちろんレンタル先で確認すればいいんですが（自鯖なら、それこそスグに確認出来るでしょう）、ウチには幸いWP Security Scanというプラグインが入れてあります。

本来はWordPressのセキュリティがどういう状態になっているのかを確認するためのものですが、その項目の中にサーバーのシステム情報が閲覧出来るようになっているので、それで確認してみました。

どうやらPHPとMySQLは要件を満たしているようです。もっとも、その2つのバージョンが適応しているというだけで他の要素はわかりませんので、きっちりチェックするにはHealth Checkということになるでしょう。

ところで、このサーバーのスペックはどんなもんなんでしょう？というのもあって晒してみました。ウチ程度のアクセス数だと、ほとんどストレスないですが（ハードウェアのスペックや回線なんかもあるでしょうけど）どうすかね？

まだWordPressがPHP 4 + MySQL 4でもまだ動くから、といってもPHP 4自体のサポートも終了していますし、WordPressのプラグインでもPHP 5必須というものも増えていますし、レンサバだと移転に手間とコツが必要ですが、無料お試し期間なんかをうまく使って移転作業を早めにしておいたほうがいいかもしれませんね。

“wp_options”が800行近くある・・・。こんなもんなの？と思いつつ目的の”rewrite_rules”を探しながら眺めてみると、以前使っていたプラグインやテーマファイルの名前がみられます。え～インストールの時はDB作成するのに削除のときは、そのままなのかよぉと無知をさらけ出す。ものによってはデータベースにゴミが残るものがあるようです。

あちこちで仕入れた「このプラグインはよさそう」だとか「このテーマを使ってみよう」というモノをバンバン試しているうちに”wp_options”はとんでもないことになっていたわけです。オプション名に明らかにプラグイン名やテーマ名があるものだとphpMyAdmin上から削除していくことも出来ますが、中には名前を見ただけではどのオプションなのか、はたまた現在も使われいるのものなのかわからないものも多数。

「使ってないオプションを削除してくるようなモノはないのかねぇ？」と検索したところ、さすがWordPressあるんですね。プラグインが！

WordPress › Clean Options « WordPress Plugins

なんでも”wp_options”のオプションで孤立しているものを一覧で出力してくれるようです。

データベースのお掃除プラグイン→Clean Options — 病的溺愛シンドローム

こちらで詳しく解説されています。

インストール後に「CleanOptions」を開くと”Don’t show the Known WordPress Core options for this “Find”“にチェック入っているはずです。コア関連のオプションは見つけても表示しないよということだと思いますが、チェックを外して一覧にコア関連が表示されても削除出来ないようになっているようでした。

出力された一覧から削除したいものを自分で選んで実行します。一括で全部選択することも出来ますが、なかには稼働中のプラグインのオプションも表示される場合もあるので、慎重に選択するのが賢明でしょう。よくわからないものはオプション名の隣にあるリンクをクリックすればGoogleで検索してくれます。

ひたすら検索して確認、そして削除対象にするという作業を繰り返します。検索してもよくわからないものは放置です。結果、300行まで削ることができました。少しは軽量化や軽快さに貢献出来たでしょうか。

ちなみにウチで使っているプラグインで稼働中なのに一覧に表示されたものは

• Head Cleaner
• Woopra
• WordPress Related Post for Japanese
• WP-Amazon 1.x for WordPress 2.5+
• wp-tegaki

といったところでした（わかる範囲で）。

「慎重に選択した方が賢明」といいましたが、コア関連のオプションが出力されないことを考えると、いっそ使っているテーマとプラグインのリストを作って、一旦プラグインを全削除してから「CleanOptions」で一覧に出たものを一括削除、その後せっせとプラグインを入れ直すとかすれば、もっとすっきりさっぱり出来るような気がします。もちろんバックアップをしてからですね。

ボクの場合、テーマファイルも管理画面から色々設定出来るものだったり、プラグインも実際にインストールして試したりなので、どうしてもゴミが多くなってしまいます。ローカル環境にクローンを作成して、そこで色々試すということを考えたほうがいいかもしれません。

どうもGoogleの検索結果への掲載順が下がっていることがアクセス数の減少の直接の原因のようです。そこでGoogleウェブマスターツールを覗いてみることにします。

なんと、400エラーと404エラーが山のようにあります・・・。その多くに見られるのが、

• 400エラーの場合→/wp-content/plugins/ktai-style/inc/redir.php?_wpnonce=
• 404エラーの場合→/wp-content/plugins/ktai_style/login.php?redirect_to=

プラグインの仕組みとかはまったく理解していないので、どういうことなのかまったくわかりません・・・。とりあえず404エラーの方に「redirect」の文字があるので、パーマリンクの変更に使っている「Permalink Redirect」との関係かなと思ってみる。

Ktai StyleとPermalink Redirectどっちか停止してみることにします。検索エンジンではもう新しいパーマリンクで拾われていますが、元々リンクを頂いているページからのことを考えるとここはKtai Styleのほうを停止する方が無難です。

Ktai Styleを停止して1週間ほど様子をみていましたが、やはりクロールエラーが激減し、アクセス数が戻ってきました。その間Twitterでクロールエラーのことをのたまっていたら、Ktai Styleの作者であるゆりこさんから返信をもらいました。

それたぶん外部サイトへの中継ページがエラーになっています。一定時間が経過すると外部サイトへの中継リンクが無効になるため 400 エラーとかになります。Ktai Style 2.0.0-beta3 を使うか、今後出るKtai Style 1.82 で直ります

なるほど2.0.0-beta3をとりあえず使っておけばいいのね！すでに2.0.0-beta3を使ってました・・・。

2.0.0-beta3をリリースされたときのブログのコメントに

Yuriko.Net » Ktai Style 2.0.0-beta3 配布

もしかしてと思い、インストールしていた「Permalink Redirect」を無効にすると、
無事表示されました！

というものがありました。ウチの状況と同じではありませんでしたが、どうやらリダイレクトとの絡みがあるようです。ちなみに2.0.0-rc1にアップデートされた時にプラグインを有効にしてみましたが、やはりクロールエラーが増加してしまいました。現在の最新版はrc2になっています。

ロリポ→チカッパ！→hetemlと順当に（？）パペポサービスをアップグレードしていますw
今回の乗り換えの目的は、やっぱり最近重いと感じていたので速度アップを期待してのものでした。実際には驚くほど速くなったわけではない感じがします。まだお試し期間なので、月額費用がアップした分のメリットが感じられないと思ったら、チカッパ！に戻ることも可能ですが、そこそこ安定してそうなので、しばらく使ってみようと思っています。

ボクの場合、ドメインを複数管理している（させられてる）のでマルチドメインが利用可能で複数のデータベースが利用できるところがコストパフォーマンスが高くなります。

レンタルサーバを乗り換えると当然、WordPressの移転作業をしなければなりません。そんなときには、やっぱりお世話になるのが、

WordPressサーバ移転まとめ – Odysseygate.com

コチラ。とても丁寧に説明してくれているので、かなりスムーズに移転することができます。

マルチドメインで一つのサーバに複数のWordPressをインストールするので、ドメインごとのディレクトリを作成したりする都合もあって、いきなりDNSを切り替えて独自ドメイン用のセットアップを敢行しました。

まずはこのブログとは別に運営しているWordPressの移転から行いました。それは、WordPressのインストール先と表示先のアドレスが一緒のすごくスタンダードなインストールを行っているので、きっとすんなり出来るだろうと・・・。

1. データベースのエクスポート
2. 旧サーバからWordPressをFTPでダウンロード
3. 新サーバへのWordPressのインストール
4. データベースのインポート（ウチでは最初からドメイン設定してある状態でインストールするので、「wp_options」のURLの変更は不要）
5. プラグイン、アップロードフォルダを新サーバにFTPでアップロード
6. サイトがうまく表示されないようならキャッシュを削除してみる。テーマをこれまでのものにきちんと変更する等など

この時に、ちょっと試してようと思って入れてあったプラグインやらテーマやらをごっそり整理するのもいいかもしれませんね。無事にサイトが表示されることを確認したら、新サーバでWordPressを楽しみます。

さて、次はいよいよ、このブログです。こちらはインストール先と表示先がことなるので、もう一手間必要です。と言っても既に動いているWordPressがあるわけですから、その構造をそっくり移すようにすればいいわけです。

1. データベースのエクスポート
2. 旧サーバからWordPressをFTPでダウンロード
   ※WordPressフォルダと同じ階層にある「index.php」「.htaccess」もダウンロードしておく
3. 新サーバへのWordPressのインストール
4. データベースのインポート（ウチでは最初からドメイン設定してある状態でインストールするので、「wp_options」のURLの変更は不要）
   ※ここでひとまず管理画面にアクセスできるか確認しておく
5. ダウンロードしておいた「index.php」「.htaccess」をウチの場合はドメインルートにアップロード
6. プラグイン、アップロードフォルダを新サーバにFTPでアップロード
7. サイトがうまく表示されないようならキャッシュを削除してみる。テーマをこれまでのものにきちんと変更する等など

プラグインやテーマをアップロードしたあたりでデータベースの整理をしておいてもいいかもしれませんね。次に移転するときにデータベースが1回でエクスポート出来なくなってるかもしれませんねぇ。

ダッシュボードからほぼリアルタイムのアクセス状況を確認出きるので便利だったんですけど、何せデータベースを使うので、ウチで借りてるレンタルサーバーではどうにも重くて仕方ないので、とりあえずアクセス解析はGoogle Analyticsにお任せすることにします。ただ、Google Analyticsはサイトにアクセスする手間があるし（ボクはこれは平気ですけど）、日毎の統計ということと、ちょっと高機能すぎてボクには宝の持ち腐れ感が強かったので、さっと確認できるStatsを利用することにした経緯があるので、今後、別のものを探すことになるかもしれません。

別のものを探すといって、データベースを利用するもの（しないものがあるのか知らない）だと結局、今と同じ状況に陥るので、データベースの使用量を制限できる機能があるとか、過去何ヶ月分のデータしか残さないといった設定ができるものじゃないと意味がないなぁと。

実は、サイトの表示が遅いのはPCのせいだとばかり思っていたんですよ。ところがPCが新しくなっても一向に表示速度が改善されなくて、データベースの肥大化が原因だったんですねぇ。やっぱりサーバー移転考えるべきかなぁ。

他にデータベースで容量を使うプラグインは関連投稿表示に使っているWordPress Related Post for Japaneseがあるけど、これははずしたくないなぁ。使用中のプラグイン24個ってのも多いような気がする。

wp.Vicunaに戻ったのは、やっぱりなんといっても国産ものというのが大きいかな？ユーザーも多いので情報も手に入りやすい。また、海外産を利用すると、フォントの指定など細かいところにも手を入れる必要があったりと手間も多いもので・・・。

また、スキンファイルでCSSのみのカスタマイズで、コアファイルに手を加えないことによって、テーマそのもののバージョンアップがあっても、カスタマイズをやり直すことがないのも便利です。

以前、自動アップデートでフォントサイズやらカラム幅を調整していたものを、何度も飛ばしているので。

ということで国産のフレームワークとして使い勝手のよいVicunaはおすすめです。

• wp.Vicuna
  本家テーマ
• ma38su.org – Projects
  ダッシュボードから各種設定が行えるwp.Vicuna Extを配布
• the Fang of Sky – wp.Vicuna Ext. Custom
  wp.Vicuna Ext. Customを配布。Extを改良したもので今回使用

意外とニーズに答えてくれるブログエディターを見つけられず、それほど便利とは言えない、ブログツールのテキストエリアを使っている。 そんなUbuntuユーザでかつブロガーの人は多いはず。 そんな皆様におすすめなのが、Bilbo Bloggerだ。

確かにUbuntuを使っていると、なかなかよいブログエディターがなくてWordPressの投稿画面からの投稿という方法を使っていました。もっとも、大概のブログエディターでも、WordPressのtagに対応していなかったりするので結局は投稿画面からということにもなりますが、このBilbo Bloggerだとtagに対応しているとのこと。

参照元で挙げられている特徴としては

• WYSIWYGエディタはもちろん、プレーンHTMLエディター内臓
• 自分のブログのデザイン情報を取得して、プレビュー
• Blogger、MovableType、WordPressなど多くのブログに対応
• 記事の作成はもちろん、削除や編集
• 下書き機能、予約反映
• 画像や動画などメディアのアップロード(APIがサポートしていれば)
• WordPressのURL編集機能やタグ機能もサポート、もちろんカテゴリも自分のブログから自動取得
• Excerpt(要約文)も編集
• 最新記事一覧を取得
• ローカル環境で下書きを保存
• 編集中の文を自動保存

プレビューはちょっとウチで使っているテーマのせいなのかうまく表示できませんでした。カテゴリの自動取得は出来るが新規作成は出来ないみたいです。tagはサポートされていますが、タグ一覧を取得してくれるわけではないので、自分で入力することになります。ボクのようにタギングのルールが曖昧でタグの数が多い場合には大文字、小文字で同じタグをつけてしまいそうです・・・。

画像の挿入はきっちりサイズを直してからの方がよさそうです。というかボクがいつも投稿画面から適当に挿入しているから面倒に感じるだけだと思うけど・・・。それとテキストの画像への回り込みなんかの指定のUIからどうやるのかわかりませんでした。

ツールバーも一長一短。アンドゥ、リドゥのボタンがありません。そのかわりといっては変だけど、WordPressではデフォルトではサポートされていないフォントサイズの変更が可能でもちろんフォントの色付けが出来ます。

もう少し触ってみないと、なんとも言えないというのが実感です。それにまだ今年の4月に公開されたということなのでこれからに期待してアップデートを追いかけてみようと思います。

WP-Amazon の WordPress 2.5 以降に対応したバージョンが登場 | Tips Community

こちらで新バージョンが登場したことを発見。

海外製のものかと思いきや、WordPress Plugins/JSeriesにあるではないですか。投稿者はHead Cleaner (最適化＆高速化)でもお世話になってるをかもとさんでした。

WP-Amazon : dogmap.jp
WordPress Plugins/JSeries » wp-amazon (Amazonリンク生成)

導入は例によって展開→ディレクトリごとアップロード→有効化という手順ですが、AmazonのAPIが変わったとかで、これまでのようにトラッキングIDを設定すればいいというわけにはいかないとのこと。

サブスクリプションID、秘密鍵という２つも設定が必要になると。

Product Advertising API アカウント作成

こちらにアカウント作成手順がのっていると紹介されています。ボクの場合には以前何かの都合でサブスクリプションIDが必要になって取得したはずなのでとりあえず、

Amazon Web Services

こちらにアクセス。
ページ上部の右側にある「Your Account」のプルダウンから「Access Identifiers」を選択。

「Access Identifiers」のページからサブスクリプションID、秘密鍵をコピーしてwp-amazonに設定。無事完了のはず。ちなみにwp-amazonの設定画面にデフォルトの地域を設定する項目があるのですが、ウチの場合はなぜかプルダウンしても何も表示されず、そのまま設定しました。

投稿画面でwp-amazonを起動して地域選択するという感じなってます。それ程手間になることでもないので、特に気になりません。

では、wp-amazonによる投稿テスト。

↑画像（中）　↓画像（大）

今週末に最終章が公開される「２０世紀少年」の第２章「最後の希望」を載せてみました。

2つ利用しているWordPressのどちらも、すんなりとアップグレードが完了し、これは便利だなぁと感心していましたが、もしかしたら運がよかっただけかもしれません。

• WordPress › フォーラム » 2.8に自動アップグレードしたら関係ないファイルが削除されました
• WordPress › フォーラム » 2.8 アップグレードのトラブルシューティング
• WordPress | 日本語 » 2.8への自動アップグレードを行う際の注意事項

最大の問題は、自動アップグレード時にWordPress以外のディレクトリやファイルが削除されてしまうということでしょう。プラグインの干渉やテーマの崩れなんかは、ボクもこれまで遭遇していて、大抵の場合は、きちんとした手順を踏まないことによるものでした。全プラグインを停止しておくとか、テーマをデフォルトに戻しておくとか・・・

今回のファイルが削除されるというのは、後でどうにもならないので、非常にやっかいだと思います。ウチの場合は、レンタルサーバーにWordPressしか置いていなくて、アップグレード時にエラーも出なかったので影響がなく、アップグレード後に上記の記事をみて、焦りました。

ということで、これからアップグレードする方は、バグ解消版がリリースされるのを待つか、手動アップグレードで対応するようにしないといけないようです。

ウチでもまだ使い込んでいないので、どこかに不都合があるかもしれません。まぁ、そういったことはバージョンアップ時には付き物くらいに思っていますけど。

ちなみに、WordPress.com Statsプラグインは、ダッシュボードの表示の３カラム以上に対応していないようです。

検索エンジンで、どのくらい現在のパーマリンクに対応してくれてるのか調べてみました。とりあえず、Googleのサイト内検索で使われる「site:」を元に「site:www.igune.com」で検索してみました。この検索方法でいいのは謎ですが、とりあえずウチのブログで検索結果にURLが表示されて入るのでよしとします。

検索してみたのは、Google、Goo、Infoseek、Yahoo! JAPANの４ヶ所。

• Googleで「site:www.igune.com」
  さすがというべきか、新しいパーマリンクになってます。パーマリンク変更後3日くらいから徐々に新しいものに変わっていったようで、やはり早い。
• gooで「site:www.igune.com」
  意外だったと言えば、失礼ですね。こちらも新しいパーマリンクに変わっていました。
• Infoseekで「site:www.igune.com」
  こちらはまだ、古いパーマリンクのままです。
• Yahoo! JAPANで「site:www.igune.com」
  まだ古いパーマリンクが多いようですが、徐々に新しいものに変わってきているようです。サイトエクスプローラも使っていますが、そちらはまだ古いパーマリンクのままでした。ちゃんと4月に入ってからもクロールされているのに。

pingの送信だとか、サイトマップを登録してあるかでも状況が変わってくるとは思いますが、Yahoo!の対応が遅いなぁと感じる結果となりました。単純にドメインの検索ではなくて、「site:www.igune.com」のあとに何かしらキーワードを入れた場合の検索でも対応状況が変わるようです。そのなかでもやはりGoogleとgooは優秀でした。

ちょくちょく各検索エンジンでチェックしてみようと思います。どのくらいの期間で現在のパーマリンクになるでしょう。

今回、各検索エンジンでパーマリンクを確認するにときフィードも確認してみたら、ブログ上のフィードURLをクリックしたときと、アドレスバーのフィードアイコンをクリックしたときに、「エラー:データベースに接続できません」という不吉なメッセージが表示されてしまいました。

しかも、なぜかこの記事を書いているFirefoxだけ。別のUbuntu+Firefoxだとちゃんとフィードが表示されます。XPで試してみても表示されます。ちょっとわかりません。