WordPress

以前は表示していなかったのですが、月別のアーカイブ表示をしてみることにしました。

月別のアーカイブ表示というのは、例えば2009年の1月2月3月・・・という感じに月ごとのリンクを張ることです。
ブログなどではお馴染みの表示だと思います。

以前にも表示したことはあるのですが、あまり必要無いかと思いすぐに削除してしまいました。
ですが、当サイトも3年目突入ということでだいぶ記事が増えて来ましたので、アクセスの利便性を考えて表示してみることにしました。

ところが、WordPress標準のアーカイブ表示や当サイトで使用しているテーマのwp.Vicuna Ext. Customの表示では縦にズラズラッと並んでしまい非常に場所を取ってしまうのです。
そこで何か良いプラグインは無いかと探してみました。

 link >>  WordPressプラグイン　monthchunks　（英語HP

探してみるとありました。
設定画面などなく表示を変えるだけのシンプルなプラグインです。

ただ、当サイトで現在使用しているWordPress2.9.1＋wp.Vicuna Ext. Customの場合、残念ながら普通にPluginフォルダにアップロードするだけでは機能しないようです。
情報を探したところ、下記のサイト様にて方法が紹介されていました。

 link >>  月別アーカイブリストを簡潔に変える monthchunks プラグインを WP2.8で使用する – Net MOUNT

貴重な情報をありがとうございます。

どうやら、WordPressの wp-includes/default-widgets.php を修正する必要があるようです。
WordPress2.8でのお話ですが、2.9.1でも同じように出来ました。

ただ、当サイトの場合、default-widgets.phpの修正だけでは機能しなかったので、以下のようにVicunaの変更もしました。

1. 外観→Vicuna設定からアーカイブを使用しないにチェック。
2. 外観→ウィジェットからアーカイブを設定。（Vicunaの記述のないアーカイブを使用。
3. プラグインをアップロード。
4. wp-includes/default-widgets.phpの修正。

WordPress2.9.1　wp-includes/default-widgets.phpの239行目あたり

※修正する前に、元のファイルはバックアップしておきましょう。

【修正前】

clr_br('

<?php wp_get_archives(apply_filters('widget_archives_args', array('type' => 'monthly', 'show_post_count' => $c))); ?>

')

【修正後】

clr_br('

<?php

if(function_exists('monthchunks')) {

    monthchunks("descending", "numeric");

} else {

    wp_get_archives(apply_filters('widget_archives_args', array('type' => 'monthly', 'show_post_count' => $c)));

}

?>

')

今回やってみたのは、wp.Vicuna Ext. Customの最新版（2010/01/10現在）でのやり方です。
昨年末に公開された修正版の前のVerでは、アーカイブ設定の項目は無かったかもしれません。

また、プラグインのファイルを修正して、月の『12345・・・』という表示を『010203・・・』や『1月2月3月・・・』という感じに変更しても良さそうです。
この辺は、『monthchunks』で検索すると情報が出てくるので参考にすると良いと思います。

当サイトで使用しているWordPressがVer2.9になりました。
そこで、いつものようにサクッとVerUPしようと思ったところ、今回は思わぬ苦戦を強いられることとなりました。

※今回は、事の顛末を書いておきたいと思いますが、実行は各自の責任において行って下さい。

■ MySQLの要件変更。

 link >>  WordPress | 日本語 » WordPress 2.9 日本語版リリースのお知らせ

WordPress2.9からMySQLのシステム要件が変更され、4.1.2 以上が必要になりました。
当サイトで使っているさくらインターネットのレンタルサーバーは、先日MySQL5に対応したのですが、それまでMySQL4だったのものが勝手に5になるわけではありませんでした。

WordPressの自動VerUPを行ったところ、MySQLのバージョンが低いということでVerUP出来ませんでした。
仕方無いので、MySQLのVerUPから始めることにしました。

■ MySQLの移行。

※MySQLの移行にはデータベース削除という計り知れない危険を伴う作業が必要になります。
詳しいやり方は、以下のサイト様を参考にさせてもらいました。

 link >>  MySQLを4から5へ　（HashiMのたわごと(？) 様

最初は、Tera Termを使ってやる予定でしたが、ログイン出来たもののそこから先に進めなかったので、phpMyAdminからやってみました。
作業は、簡単に言うと、、、

1. データベースのバックアップを取る。
2. MySQL4のデータベース削除。
3. MySQL5のデータベース作成。
4. バックアップを元に戻す。
5. WordPressのwp-config.phpのデータベースアクセス情報を修正。

と、こんな感じになるでしょうか。
バックアップ時は、以下のように設定しました。

• 『構造』の『DROP TABLEを追加』と『IF NOT EXISTSを追加』にチェックを入れる。
• 『ファイルに保存する』にチェックを入れ、圧縮は『なし』と圧縮有り『gzip』『bzip』で各バックアップ取得。

ただし、MySQL5では『gzip』形式はインポートできませんでした。

■ MySQLの移行で手間取った３つのこと。

やってみると、それほど大変な作業ではないのですが、いくつか手間取ったことがありました。

1. バックアップのインポートエラー。
2. テーブルの照合順序。
3. テーブルのバックアップ漏れ。

１）データベースを削除した後でしたので冷や汗ものでした。
個人的な予想ですが、phpMyAdminログイン直後のサーバー情報の画面でエクスポートしてしまったためではないかと思います。

この画面でエクスポートすると左側のエクスポートのところにデータベース名が出ます。
この状態でバックアップを取ると、バックアップを戻す時にすでにそのデータベース名があるのでエラーになったのではないかと思います。

しかし、phpMyAdminログイン後にデータベースを選択してからエクスポートすると、左側のエクスポートのところにテーブル名がズラズラッと出ます。
この状態でバックアップし直したものを戻したところエラーが出ずに処理出来ました。

２）MySQL5にしてからバックアップを元に戻したところ、『～』が『？』になったり、ウィジェットが全部表示されなかったりしました。
『～』に関しては、各テーブルの照合順序の設定によるもののようでしたので、『ujis_japanese_ci』を『utf8_general_ci』へ変更してみました。

照合順序を変更したところ、『～』もウィジェットも正常に表示されました。
変更は、テーブルを全部削除して、『データベース』→『操作』から照合順序を変更して、再度バックアップをインポートしました。

３）プラグインで使っていた2つのテーブルをバックアップし忘れてしまいました。
バックアップはいくつか取っておきました。

• phpMyAdmin上でサーバ名でバックアップ。
• WordPress上でWordPress Database Backupプラグインを使いバックアップ。

サーバ名でのバックアップは、結局MySQL5のインポート時にエラーで使えなくなりました。
そこでWordPress上でのバックアップを使ったのですが、プラグインのデータベースバックアップは含めていなかったのです。

失ったのは、Contact Form 7とTwitter Toolsの２つでした。
Contact Form 7は設定し直すとして、Twitter Toolsはそれきりちゃんと動かなくなってしまいました。

仕方無いので、とりあえず別なTwitter用ツールを付けました。
他にも何か無いか探してみるつもりです。

■ WordPressのwp-config.phpの変更。

MySQLを変更する際に、パスワードとサーバー名が変更になります。
パスワードは、今までと同じものでしたらwp-config.phpの変更はありませんが、せっかくなので変更した方が良いかもしれません。

サーバー名はおそらく変更になると思われますので、wp-config.phpの『define(‘DB_HOST’, ‘[サーバー名]’);』の部分を書き換えました。

■ WordPress 2.9での不具合。

そんなこんなで何とかMySQL4から5へ移行し、WordPressも2.9へとVerUPしました。
概ね正常にVerUP出来たかと思うのですが、一部動作がおかしいところがありました。

当サイトでは、フィギュアレビューの目次などに『ページ』を使っているのですが、なぜか管理画面で編集しようとすると真っ白な画面が出てきてしまいます。
サイト上では表示されているのでWordPressの編集画面で正常に読み込めていないだけのような気がします。

ひとまず、ヘタに編集してデータが無くなるのも恐いので様子見しておきます。

また、プラグインではSimple TagsがWordPress2.9に対応していないようでした。
わりと頻繁に更新している作者様のようなので、こちらは少し待つこととしました。

久しぶりにWordPressに機能を追加してみました。
今回追加したのは、『WP Super Cache』というプラグインです。

よく使われているプラグインのようですが、当サイトでは使用しておりませんでした。
使おうと思ったのは、Googleのウェブマスターツールというサイトでサイトのパフォーマンスを確認したところ、表示が遅いらしいということがわかったためです。

 link >>  Google　ウェブマスターツール

サイト内のページの平均読み込み時間は 4.9 秒です（更新: 2009/12/10）。
全体の 73% にあたるサイトと比較して遅い読み込み時間です。

平均読み込み時間は 6 秒を越えると遅いと感じるらしいので、まだ少し余裕がありそうですが、TOPページなどに色々増えてきたので少しサイトの軽量化をしようかと思いました。

具体的には、フィギュアレビュー以外の普段掲載している写真の圧縮率を上げたり、なるべくTOPページに余計なモノを置かないなどですね。
先日ご紹介した『Delete-Revision』を使って不要なリビジョンページを削除してデータベースを軽くするのも良さそうです。

そして、今回、サイトのデータをキャッシュして読み込みを早くするプラグインを導入してみました。

 link >>  WP Super Cache　（WordPress.org
 link >>  WP Super Cache 用日本語リソース　（わーどぷれすっ！様

日本語のリソースを作成されておられる方がいらっしゃいましたので、ありがたく拝借致しました。
英語が苦手な身としては、本当にありがたいことです。

具体的な使い方や設定などは、以下のサイト様を参考にさせてもらいました。

 link >>  ☆「WP Super Cache」というプラグインを使ってみました　（日下部理子のブログ様
 link >>  WordPress 2.8 が重いと感じたらチェックすべき項目　（Nire.Com様

■ 設定

設定は、とりあえず上記のような感じにしてみました。
これら以外は、デフォルトのままです。

オン（WP Super Cache）とハーフオン（WP Cache）の違いは、ハーフオンでは、MySQL と「キャッシュ」を比較してから新しいものが MySQL にあれば、それを MySQL に読みにいくので少し遅くなるようです。
オンの場合は、確認せずに「キャッシュ」から読み込むのでハーフオンより早いようです。

一部気になったのは、サイト上にあるTwitterのコメントが更新されないということがありました。
おそらくキャッシュから読んでいるのでそうなっているのかと思うのですが、他のサイト様でWP Super Cacheはページしかキャッシュしないという情報もあったりして少々謎なところです。

まぁ、あまりブログ上でTwitterを読んでいる方はおられないと思いますので、さほどの問題は無さそうですが。
他にもアクセス解析やカウンタも少し気になりますが、サイト上で集計しているわけではないので、確証はありませんが、たぶん大丈夫かと思います。

デフォルトでは、キャッシュの有効時間が3600秒（60分）になっているところを600秒（10分）に変更してみました。
アクセス数の微妙なうちのサイトでここまで短くすると効果が落ちそうな気もしますが、少しこのまま様子を見てみようかと思います。

さらに上記の設定＋WordPressのオブジェクトキャッシュも有効にしてみました。
wp-config.phpファイルに　define(‘ENABLE_CACHE’,true);　と追記しました。

特に写真の多いレビューページで効果が出てくれるとありがたいですね。