WordPress

■ GumblarウイルスとFFFTP

GumblarウイルスによりFTP接続時のパスワードが抜き取られ、サイトが改竄されるという事例が多発しています。
当サイトも小さいながら見に来ていただいている方がおられますので、何らかの対策をしなければいけないと思っていました。

まずは、私の使用しているパソコンがGumblarウイルス自体に感染しないよう気をつけなければいけません。
パソコンにはもちろんウィルス対策ソフトは入れてありますが、使用者が怪しいファイルなどを積極的に開いてしまったりしては効果半減です。

そして、先日から話しの出ているFTPクライアントソフトの『FFFTP』をどうしようか考えていました。

 link >>  Sota’s Web Page　（FFFTP作者様ページ
 link >>  Sota’s Web Page (GumblarによるFFFTPへの攻撃について)

当サイト立ち上げ時から愛用させていただいた素晴らしいソフトです。
ですが、作者様のウイルス対策情報にもありますが、オープンソースであったりSSL等に対応していないなどの弱点もあったりします。

そういった理由などもあり、作者様自らSSL対応のFTPソフトへの切り替えを薦められています。
せっかく使い慣れた素晴らしいソフトだったのですが、万一当サイトに問題があると見に来て下さる方にご迷惑をかけてしまうことになりますので、FTPクライアントソフトの変更をすることにしました。

当然、変更するにはSSLなど通信の暗号化に対応したものを選びたいところです。
これが探してみると意外と少ないようで、これはいかに多くの方がFFFTPを使っていたかの裏返しではないでしょうか。

■ NextFTP4を選ぶ。

フリーソフトのFTPクライアントソフトもありましたが、私は『NextFTP4』を選ぶことにしました。
無償試用期間が90日ほどありますが、その後の使用は有償になります。

 link >>  Toxsoft Home Page　（NextFTP4公式ページ

選んだ理由としては、こちらもFFFTPと同じく結構古くからある定番ソフトであり信頼性も高いのではないかと思いました。
また、Gumblarウイルス対策かと思いますが、先月さくらインターネットのレンタルサーバでFTPS(FTP over SSL)機能の提供が始まり、その際にNextFTP4を取り上げていたことなどが決め手になりました。

 link >>  レンタルサーバ系サービス FTPS機能対応のお知らせ　（さくらインターネット公式ページ
 link >>  SAKURA Internet // サポート – オンラインマニュアル – ファイル転送ソフトの設定　：　Next FTP4

 link >>  NextFTPオンラインマニュアル　（NextFTP4公式ページ

一例として取り上げているのはそれだけ信頼性があるということではないでしょうか。
私もあまり詳しくないので、設定方法などが詳しく解説されているのはありがたいですね。

上記のページを見て設定したところ、特に問題も無く接続しファイルのアップロードなども出来ました。
ただ、SSLの設定をしたところ、暗号化しているためか接続に少し時間がかかるようになりました。

フォルダを開いたりするのにちょっと間が空くのですが、今まですぐ開いていたのでちょっと違和感があります。
慣れればあまり気にならなくなるかもしれませんが、最初は気になりますね。

FFFTPと比べてずいぶん設定項目も多いようで、多機能さを感じます。
jpgファイルなどのプレビュー機能は、なかなか便利だと思いました。

まだ細かい設定などは見ていませんが、オンラインマニュアルもとても充実していますので、参考にしながら設定してみたいと思います。

■ パーミッションは？

今回FTPクライアントソフトを変更するにあたって、Wordpressのパーミッション情報もあらためて調べてみました。

 link >>  wp-config.phpのパーミッションは何にしておくのがベストでしょうか？　（Wordpressフォーラム
 link >>  ファイルパーミッションの変更　（WordPress Codex 日本語版

さすがにパーミッション777にはしていませんが、各所のパーミッションの設定はいつも悩んでいます。
user、group、otherというのもイマイチよくわからないのでこの機会に少し調べてみようと思います。

■ 今までありがとう！　FFFTP！！

と、いうわけで長らく愛用させていただいたFFFTPの使用をやめることにしました。

上記の作者様のページでは、アンインストール方法なども丁寧に説明されています。
コントロールパネルの「プログラムの追加と削除」からアンインストールし、念のためにレジストリ消去ツールも使ってみました。

FFFTPのレジストリ消去ツールなどもわざわざ作られているのは、作者様の大いなる善意を感じますね。
これで完全に削除され、私のパソコンから無くなりました。

当サイトで利用する前にも多々使わせていただいたとても素晴らしいソフトでした。
もし、今後VerUPなどで十分な機能を備えたならぜひ再度利用させていただきたいですね。

---

ブログなどで記事の下に『関連記事』というサイト内の関連した記事のリンクが貼られているのを見かけます。
以前からやってみたいと思っていたのですが、自分で全部探して貼るのはちょっと面倒だなと思っていました。

そんなことを思いつつ何気なく検索していると、実はプラグインで表示させられることがわかりました。
これは、ぜひやってみたいと思い、久々にサイトを少しいじってみました。

今回は、そんな『各記事の下に関連記事を表示する』というのをやってみました。

使ったプラグインは、『Similar Posts』というプラグインです。
以下のサイト様の記事を参考にさせていただきました。

 link >>  WordPress: Similar Posts の紹介と設定例 – 関連記事[投稿|エントリ]を表示するプラグイン　（Yukun’s Blog 様
 link >>  WordPressに関連記事の表示を追加するプラグイン Similar Posts　（sprouthead blog 様

■ プラグインのダウンロード

プラグインは、以下になります。

 link >>  All Things Seen and Unseen » Post-Plugin Library
 link >>  All Things Seen and Unseen » Similar Posts

このプラグインは、2つから成り立っているようで、それぞれをダウンロードしてプラグインフォルダにアップロードします。
そして、Post-Plugin Library → Similar Postsの順に使用出来るようにします。

使用出来るようになるまで少し時間がかかりましたが、おそらくデータベース操作などをしていたためだと思います。
プラグインをインストールすると、データベースにwp_similar_postsというテーブルが出来ました。

現在使用しているのは、WordPress2.9.1になりますが、特に不具合もなく準備は出来ました。

■ 設定

設定は、上記のサイト様の記事を参考に設定してみました。
項目は、以下のような感じです。

• General
  
  • Match the current post’s category? → No
  • Match the current post’s tags? → No
• Filter
  
  • Categories to exclude/include: → 関連記事から除外/対象
• Placement
  
  • Output after post: → Yes
• Other
  
  • Relative importance of: → content: 70%, title: 20%, tags: 10%
• Manage the Index
  
  • Handle extended characters? → Yes
  • Treat as Chinese, Korean, or Japanese? → Yes

● Generalタブの２つは、ちょっとよくわかりませんでしたので、とりあえずNoにしておきました。

● Filterタブは、関連記事から除外するカテゴリをいくつか設定しておきました。
以前書いていた『更新履歴』とか出てきても仕方無いですからねぇ。

excludeが除外、includeが対象です。
ここを分けておくとずいぶん精度が変わりました。

● PlacementタブのOutput after post:をYesにするとSingle記事の下に表示が出るようになりました。
このままで十分ですが、『!is_single()』とすると一覧記事の下に、『空欄』にすると両方に表示されるようです。

とりあえず、Single記事の下だけ表示にしました。

● OtherタブのRelative importance of:は、『記事内容』、『タイトル』、『タグ』をどれくらいの割合で参考にするかの設定です。
私は、タイトルの付け方が上手くないので記事内容の比率を多めにしました。

タグも結構イイ加減なので、少なめにしてあります。

● Manage the Indexの2つは、日本語サイトなので両方ともYesにしました。

その他の設定は特にいじりませんでした。
さらにカスタマイズしたい場合は、sprouthead blog様の記事に詳しい解説があります。

■ 感想

残念ながら日本語化パッチなど見つかりませんでしたので全部英語のままですが、こんな感じで設定しました。
更に細かく設定されたい場合は、上記サイト様を参考にしていただくのが良いと思います。

大した設定はしていないのですが、早速さらっと各記事を見てみたところ、なかなか的確に表示されていました。
例えば、オーキッドシード　シャイニング・ウィンド 椎名夏音を開くと、同じシャイニング・ウィンドのエルウィンやクレハ、マオなどが出てきます。

Filterである程度記事を除外したのですが、昔のちょっとテキトーな記事などが出てきてしまったりするのもあったりするのが難ですね。
まぁ、これはプラグインのせいではありませんが、、、

この機会に昔の記事を少し整理しようかなと思いました。
こういうのをやって、昔のテキトーな記事が出てくるとちょっと恥ずかしいですね。

とはいえ、自動で記事を選別してくれる処理はとても正確だと思います。
正直、これが全部自動で表示されているというのは、かなり驚きました。

今回設定した以外にも色々設定出来る高機能なプラグインですので、もう少し色々いじってみたいと思います。
あとは、関連記事に表示出来るような記事をたくさん書くだけですね！

---

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

月別のアーカイブ表示というのは、例えば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行目あたり

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

【修正前】

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

【修正後】

<?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);　と追記しました。

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

注意） 今回のプラグインは、使用前に必ずデータベースのバックアップをとっておきましょう。


WordPressで記事を書いていると、下書きを保存するたびに『投稿リビジョン』というのが増えて行きます。
この機能は、WordPressのVer.2.6あたりから付いた機能だそうです。

WordPress上で記事を書いていると、万一何かに失敗した際に戻せるという利点があります。
ですが、記事が完成してしまえば、ほとんどの場合、不要になるものではないでしょうか。

私の場合、レビュー記事などは、秀丸エディタで書いてからWordPressに貼り付けています。
簡単な記事はWordPress上で書いてしまいますが。

簡単な記事とはいえ、ある程度書くたびに保存してますので、この『投稿リビジョン』というのが結構出来てきます。

そこで、この不要になった『投稿リビジョン』を削除しようと思いました。
不要とはいえ、WordPress2.8.4上からは消せるようなところが見当たらないのでプラグインを探してみました。

 link >>  WordPress プラグイン　Delete-Revision

やはり、ありますね。
消したいと思っている人はいるようです。

使い方は、普通のプラグインと同じで、上記URLからファイルをダウンロードし、解凍したものをpluginフォルダに入れて、WordPress上で使用するように設定します。
すると、設定の中にDelete-Revisionが出てきます。

英語ですが、大してボタンはありません。

そうしょっちゅう使うプラグインではありませんが、テキトーに増えて来た頃に削除しようかと思います。
この自動保存の機能を無効にするようなプラグインもあるようですが、とりあえず自動保存されて困ることも無いので削除のプラグインだけ入れてみました。

ちなみに、削除しただけではデータベースの容量は変わりません。
削除後に最適化をする必要があります。

その機能もあるようなのですが、うちの環境ではなぜかちゃんと動きませんでした。
最適化して容量を減らさないと意味が無いので、さくらインターネットのコントロールパネルからphpMyAdminに入って最適化をしてみました。

すると、、、wp_postsのサイズが86.0MiB → 5.6MiBに減りました。

記事数が993件ほどで、削除したリビジョンが8000件でしたので、何か減りすぎな気もしましたが、、、orz
ザーッと確認したところでは、記事が無くなっている感じはしませんでしたので、たぶん大丈夫だと思います。

それにしても、8000件もあったとは、、、
下書きには、IDも勝手に割り振られてしまいますので、うちの記事のurlの番号は、飛び飛びになってます。

ちなみに、『データベース』の削除なので、ディスク容量は変わりません。


使用に際しては、データベースからデータを削除するプラグインなので、使用前には必ずバックアップをとりましょう。

去年末頃にデータベースの操作を間違えて記事をいくつか消してしまいましたので、、、(ノ_＜。)　
その時は、検索サイトのキャッシュから回収できましたが。

SQL文を使ってデータベースを操作して削除も出来るようですが、プラグインの方が安全な感じがしたのでこっちにしました。

不要な下書き記事を削除することでだいぶサイズが小さくなりました。
なんとなくサイトの表示が早くなったような気がしなくもないです(/ω＼)

■ 参考HP

 link >>  投稿リビジョンを削除する – Delete-Revision　（病的溺愛シンドローム様