ビジュアルエディタとは

ビジュアルエディタとは、ホームページビルダーやDreamweaverのようなサイト作成用のソフト的な感覚で日記が書けるJavaScriptを利用したWordPressの新規投稿用のページのことで、タグを知らなくても裏で自動でタグを作成してくれるモードです。
タグの入力に関しては、他のブログでもボタンをクリックすれば自動で入力してくれたりするのもありますが、このWordPressのビジュアルエディタの特徴は、入力した状態ですでにタグが反映されているんですね。
つまり、たとえば、文字を太くする<strong>というタグがありますが、ビジュアルエディタでは実際に太い状態でちゃんと表示されるんですよね～。

それ以外にも、画像も<img src="～" />みたいなタグが表示されるんじゃなくて、実際に画像が表示されるんです。
なので、タグだと、あれ？どんな画像だったっけ？なんてこともなくなるし、こんな感じのページが投稿されるんだな。って、書いている状態でわかるから書きやすいんですよね。

明朝体

ただ、私のようなある程度タグを手書き入力出来る程度の知識がある人であれば、タグ自体を直接入力したいって時がありますよね。
そんな場合は、HTMLモードもWordPressは用意してあるです。
HTMLモードとビジュアルエディタは、入力欄の右上にあるボタンをクリックするだけですぐに変更できます。
HTMLモードで入力したタグは、ビジュアルエディタモードにすると即座に反映されて表示されます。

ただ、問題がないわけでもなくて、問題っていうかビジュアルエディタは、入力する文字が明朝体でなおかつちょっとちっちゃいんですよね。
昔、HPを始めて作ったころ（1998年ごろ）は、明朝体はおしゃれ。なんて思っていたんですけれど、今は単に見にくいだけでしかありませんね。

さて、この明朝体を修正する方法を紹介します。

まず、

/wp-includes/js/tinymce/themes/advanced/skins/wp_theme/content.css

CSSファイルを開きます。

body.mceContentBody {
/* font: 13px/19px Georgia, Arial, Helvetica, sans-serif; */
font: 14px/19px "MS UI Gothic";
padding: 0.6em;
margin: 0;
}

赤い文字の部分を半角の/*と*/で囲ってください。
もしくは消しちゃってもOK。
で、文字を大きくしたいのであれば、font: 14px/19pxとしてみたり、"MS UI Gothic"なんて書いてやるとゴシックで表示してくれるようになります。

なお、この設定はWordPressをアップグレードしたりすると、また明朝体に戻されちゃうんで、そのたびに修正してやる必要があります。

このように、ビジュアルエディタでもゴシック体で表示されるようになりました。

.htaccessで認証

WordPressの管理画面(ダッシュボード)には、認証が必要ですが、ブログ自体に認証をつける最も簡単な方法は、.htaccessでBasic認証をする方法です。
たとえば、特定の人にしかブログを見られたくない。とか、誰にも見られたくない。なんて場合は、この認証が簡単です。
ただし、このやり方は Windows Live Writer のようなアプリを使ってブログを更新している場合は、投稿ができなくなるので注意が必要です。

その場合は、プラグインによる認証がお勧めです。

WordPressでは、ディレクトリ上に「.htaccess」というURLを打ち込んでも見えない設定ファイルが作られます。
FTPなどでディレクトリを参照してやると見つかるはずです。
このファイルの最初の方に、以下を付け加えます。

AuthUserFile  /home/xxxx/xxxxx/xxxx/.htpasswd
AuthName  “Input Your Name And Password”
AuthType  Basic
order deny,allow
deny from all
allow from .jp
require valid-user

/home/xxxx/xxxxx/xxxx/.htpasswd は、暗号化されたパスワードが記述されているファイルへのフルパスで、慣用的に「.htpasswd」というファイル名が使われます(この名前でなくてもかまいません)。
大事なことは、ファイル名の一番最初の文字が「.(ドット)」であることで、こうすることによって外部からは中身が見えなくなります。(暗号化されているので、見られてもよほどのことがない限り、パスワードはわからないと思いますが。実際には .ht で始まるファイル名だと、外部から見えなくなる)
また、ファイルへのパスは、フルパスになります。
レンタルサーバーを変えた場合にフルパスが変更になった場合、必ず変更しておいてください。

AuthName  “Input Your Name And Password” は、パスワード認証時に左の画像の、■色で囲った部分に表示される文章です。
スペースを空ける場合は「 “ 」で囲みます。
日本語でも可能ですが、文字化けする場合もあるので半角英数字で。

AuthType  Basic は、左のような画像のダイアログが表示される認証方式で、基本的には認証というとBasicになります。
もう一つ、セキュリティーがアップした「 Digest 」もあるんですけれど、サーバーが対応していない場合があるので、Basicでいいと思います。

order deny,allow
deny from all
allow from .jp
これは、アクセス制限です。
日本からのアクセス(ホスト名がjpでおわるもの）のみ、許可させる。という場合の設定です。
外国からのアクセスは、意外とクラッキング攻撃を受ける可能性があるので、認証が必要な場合は、日本からのみアクセスを許可させた方がいいかもしれません。
この部分は、認証とは関係ありません。

require valid-user 意外とハマったのがこれ。
これを記述しないとどうもうまく認証してくれない。

この意味は、暗号化されたパスワードファイル(.htpasswd)は、

ユーザー1 : 暗号化されたパスワード1
ユーザー2 : 暗号化されたパスワード2

のように、ユーザー名と暗号化されたパスワードが1行に記述され(ユーザー名との間は、: (ダブルコロン)で区切られる)、複数のユーザーがいる場合は、1行1行別けて記述されるんですけれど、ユーザー名とパスワードの組み合わせが正しければ、記述されているユーザーすべてがログインできる場合は、「 valid-user 」を指定します。
これに対して、記述されたユーザーのうち、特定のユーザーしかログインさせない場合は、「 require user ユーザー名 」のように記入。

基本的には、この一文はなくても認証が動作するんですけれど、なぜか私の環境ではこの1行の記述がないと認証画面になってくれない(すべて許可してしまう)・・・。

なので、どうしても認証がうまくできない。というのであれば、この行を追加してください。

.htaccessファイルの作成の仕方

さて、さっそく.htaccessファイルを作りたいとこですが、Windowsでは、ファイル名が「. (ドット)」で始まるファイルは、メモ帳では作れません。
なので、上記の内容を記したファイルをメモ帳で作成し、「 aaa.txt 」で保存します。

続いて、FTPでサーバーにアップロードします。
アップロード先は、一番上のディレクトリでかまいませんが、一番上に配置すると、その下のディレクトリすべてが対象になってしまいます。
なので、もし、特定のディレクトリだけに該当させた場合は、該当ディレクトリにアップロードします。

アップロードが完了したら、FTP上で「 aaa.txt 」を右クリックし、左の画像のように「名前の変更」を選択します。
そして、

.htaccess

というファイル名に変更してください。

注意点

WordPressでは、最初からサーバー上に.htaccessが作成されています。
なので、実際にはFTPで.htaccessファイルを右クリックし、表示されたメニューの「表示/編集」を選択して、認証用の命令を追加してください。

誤ってすでにある.htaccessを上書きしてしまうと、アクセスできなくなる場合もあるので注意してください。

httpd.confで認証

自宅サーバーや、専用サーバーで運営している人は、httpd.confをいじれる人もいるかもしれません。
その場合は、http.confで設定した方が混乱しないかも(サイトを複数もっている場合、どれに認証をかけたかわからなくなったり・・・など)。
httpd.confで認証をする場合も、.htaccessと変わりありませんが、以下はファイル単位で認証をかける場合の例。

<Files ~ “example.php”>
AuthType Basic
AuthUserFile  /home/xxxx/xxxxx/xxxx/.htpasswd
require valid-user
</Files>

<Files ~ “example.php”></Files> は、○○というファイルだったら、以下を実行する。の意味で、例では「 example.php 」というファイル名のファイルにアクセスがあったら、Basic認証を行う。ということになります。

プラグインによる認証

上の左の画像のように、WordPressのブログにアクセスしようとすると認証画面が表示されるようにするには、プラグインを使用します。
プラグインによる認証方法も簡単に実装することができます。
なおかつ、パスワードをクッキーで記憶させたり、パスワードを忘れた場合でも対応できたりと、 なかなかクールな認証方法を提供したい場合は、この手法がベストです。

右の画面は、パスワードを忘れた場合。
登録してあるメールアドレスにパスワードをリセットするためのページへ行くURLが記載されている。

プラグインの入手

さて、こんなすばらしいプラグインですが、WordPress Plugins/JSeriesのサイトで入手できます。

ちょっと日付は古いですが、WordPress3.1でも動作しました。
上のリンクをクリックし、「WordpressPassword-Japanese ver0.1 最新版」をクリックします。

WordPressPassword-ja-0.1.zipというファイルがダウンロードできるので、適当な場所にダウンロードします。

続いて、ダウンロードした「WordpressPassword-ja-0.1.zip」を右クリックし、「エクスプローラ」を選択。
すると、左のような2つファイルが入っています。
このうちの WordPressPassword-ja.mo という方が必要になってきます。

続いて、FTPで「wp-content」の中の「plugins」の中に

wp-password

というディレクトリを作成し、先ほどの「 WordPressPassword-ja.mo 」をその中にアップロードします。

アップロードが完了したら、さっそくアクセスしてみましょう。
左のようにダッシュボードにログインする時と同じログイン画面になるはずです。
パスワードは、ダッシュボードログイン用のものと同じになります。

このプラグインによる認証は、ユーザー名とパスワードを教えてしまうと、ダッシュボードにもログインできてしまうのが弱点といえば弱点。
ただ、誰にも見られたくない日記や、私の場合はメモ書きなんかにWordPressを使っているので、認証機能は非常に便利。
会社にいても家にいても、そしてスマートフォンからもユーザー名とパスワードさえわかっていれば、参照、編集が可能なので、ブログ＝日記 ではなく、最近はやりのクラウド的な使い方としてもWordPressは本領を発揮すると思います。

記事自体にパスワードをつける

最後に紹介する方法は、記事自体に認証をつける方法。
WordPress3では、記事自体にパスワードをつけることが出来るようになりました。あ記事の投稿画面の公開設定（右上の部分）にある、「公開状態」をクリックすると、「一般公開」「パスワード保護」「非公開」の3つから公開状態を選べるようになりました。

「パスワード保護」を選択すると、パスワード入力欄が表示されるので、パスワードを入力します。
この状態で公開すると、他の記事は他人に見せることが出来ても、パスワードを設定した記事は、閲覧するのにパスワードが必要になってきます。

他の記事は見せたいけれど、見せたくない記事もいくつか投稿したい場合なんかは、このやり方が一番スマートかもしれません。

同じタイプのブログシステムに、Movbable Typeがあるんですけれど、こちらはファイルとして保存することが出来るので、万が一データベースが壊れても、今まで投稿したファイルはそのまま保たれます。
よって、Movable Typeはレンタルサーバーを変える場合でも、割と移転が楽です。

レンタルサーバーは、いくらお金を払っているとはいえ、どの会社もデータの保証はしていないため、自らバックアップする必要があります。
でも、結構この作業がめんどくさくて、あとでデータが飛んでしまって後悔する羽目に・・・。
意外とデータが飛んでしまった。って経験をしている人は多いみたいです。

WP-DBManager

データをバックアップするプラグイン

WordPressのすばらしい点は、色々な機能をプラグインという組み込みシステムでプラスすることが出来る点です。
で、もしかしたら、データをバックアップするプラグインがあるんじゃないか・・・と思ったら、ありました。
それが「WP-DBManager」です。

インストール

インストールは簡単。
まず、WordPressの管理画面にログインし、「プラグイン」の「新規追加」をクリックします。
キーワードに「WP-DBManager」と入力します。

このように検索結果に表示されるので、「インストール」をクリックします。

今すぐインストールをクリックします。

「プラグインを有効化」をクリック。

日本語化

次にWP-DBManagerを日本語化してみます。

日本語化用のファイルは、Technolog.jpさんのWordPress – WP-DBManager 日本語化ファイルで配布されています。
「日本語化 – WP-DBManager V2.5.0」をクリックします。
日本語化はWP-DBManagerのバージョンとあわせるようにします。

ダウンロードしたファイルを右クリックし「エクスプローラ」を選ぶと、解凍できます。

中にある二つのファイルを「WP-DBManager」のフォルダにアップロードします。
具体的には「 …/wp-content/wp-dbmanager/ 」の中にアップロードします。

WordPressの管理画面の左サイドの一番下に「データベース」という項目が表示され、中身も日本語になりました。

バックアップする

WP-DBManagerをインストールすると、「 …/wp-content/ 」フォルダの中に「 backup-db 」というフォルダが出来ているはずです。

WordPressの管理画面の「データベース」の「バックアップ」をクリックします。

ページの下に「バックアップ」というボタンが表示されるので、クリックします。

成功すると、以下のように表示されます。
 

先ほど作成された「 backup-db 」というフォルダの中にバックアップファイルが作成されています。
  

セキュリティー

このファイルは、インターネット上で誰でもアクセスできてしまうので、「 .htaccess 」というファイルを「 backup-db 」のフォルダに置いておきます。
中身は、以下のように記述します。

<Files ~ "sql$">
deny from all
</Files>

これでブラウザでアクセスすると、以下のように表示されます。

バックアップファイルを保存する

バックアップしたファイルを保存するには、WordPressの管理画面の「データベース」にある「バックアップDB管理」をクリックし、保存するデータベースにチェックを入れ、「ダウンロード」をクリックするか、「E-mail」をクリックします。

この時「リストア」をクリックすると、その時のデータベースの状態に戻ります。

定期的にバックアップする場合は、「データベース」の「DBオプション」をクリック。
定期的にバックアップしたい期間を入力し、「変更の保存」をクリック。

 
携帯用に表示を整えるKtai Styleを紹介しましたが、携帯で見ると上のように文字化けしてしまうことがあります。
これは、PHPのデフォルトの文字コードの出力がUTF-8になっているためで、これを修正するには、サイトのトップディレクトリの「.htaccess」に以下を追加します。

<IfModule mod_php5.c>
php_flag  mbstring.encoding_translation Off
php_value mbstring.http_output pass
</IfModule>

<IfModule mod_php4.c>
php_flag  mbstring.encoding_translation Off
php_value mbstring.http_output pass
</IfModule>

さらに、WP Super Cacheを使用している場合は、Ktai Styleを使用し始めてから携帯でアクセスすると、携帯用に表示したキャッシュがパソコン用にも使われてしまいます。
そこで、

「Mobile device support using WordPress Mobile Edition.」にチェックを入れ、「ステータスを更新」をクリックします。

これで文字化けが改善されたと思います。

カテゴリーページのエラー

Category Order could not understand your category HTML. Please do the following:

• Disable all plugins except for category order to see if some other plugin is causing the problem. If the problem goes away, re-enable each plugin until you find the incompatible one.
• Try switching to a different theme, like the WordPress default theme.

Once you have tried the above steps, email david@coppit.org with the results of these debugging steps. Also include the following information:

Ktai Styleを使用して、カテゴリーページへアクセスすると、上記のようなエラーが出てくる場合があります。簡単に訳すと、「Category Order」というプラグインによってカテゴリーのHTMLが正しく表示できませんでした。的な感じ。
カテゴリーに関するプラグインの仕様をやめてチェックしてみてくださいと。

これは、カテゴリーページへのリンクの順番を変えることが出来る「Category Order」を使用していると、このようなエラーが出るようです。

かわりに「My Category Order」というプラグインでカテゴリーを並べ替えることが出来るので、Ktai Styleを使う場合は、こちらをインストールして使ってください。
ただ、Ktai Styleは、こうしたプラグインを使用してカテゴリーの順番を並べ替えても順番の変更が無効になってしまうので注意してください。

また、「プラグイン」の「インストール済み」をクリックし、「Category Order」の「停止する」をクリックします。

これで正しく表示されました。

携帯からのアクセスが

このWordPress設定入門を作成した数日後、WordPressを使って別のブログを作成しました。
先日、この二つのブログのアクセスログを検証していると、その後から作成した方のブログには、携帯経由のアクセスが多いことに気がつきました。

だいたい、検索サイトからの訪問の半分ぐらいが携帯からのアクセスのようで、特にAUの訪問が多いみたいです。

携帯からのアクセスが増えたわけ

ところが、先に作成していたこのブログは、ほとんど携帯からのアクセスがありません。
なぜ、あとから作成したブログの方は、携帯からの訪問が多いのかな。と、考えてみたんですけれど、ひとつ思い当たる点がありました。
そのとあるサイトは、実験として携帯用に表示させるKtai Styleというプラグインを導入していたのでした。

実は、Googleなどの検索サイトのクローラーは、携帯からのアクセスを装ってアクセスしてくることがあります。
※ 以下がその時のアクセスログ

rate-limited-proxy-209-85-238-201.google.com – - [24/Mar/2010:02:55:31 +0900] "GET / HTTP/1.1" 200 4725 "-" "DoCoMo/2.0 N905i(c100;TB;W24H16) (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html)"

詳細はわかりませんが、このクローラーによってクローリングされたページは、携帯で検索したときに、モバイルサイトとして表示されるようなのです。

Ktai Styleとは

Ktai Styleの特徴

そして、その携帯用に表示してくれるプラグインが、Ktai Styleというプラグインなのです。
このKtai Styleのすばらしいところは、

• 記事中の画像を携帯用に縮小して出力してくれる
• 携帯は携帯。パソコンはパソコン用に表示
• トップページは、記事のタイトルとそのページのリンクのシンプルな表示にしてくれる
• カテゴリーリンクなどのサイト用のリンクも適切に表示
• 携帯用の絵文字にも対応
• テンキーでのアクセスも可能

とかゆいとこに手が届く機能がたくさん。

画像は、このように縮小されて表示します。

今までパソコン用のサイトはいくつもつくってきたんですけれど、どうも携帯用のサイトは作り方がよくわからず、いつも途中で放棄してしまっていたんですけれど、これは結構すごいプラグインかも。

Ktai Styleのインストール

まず、WordPressの管理画面にログインし、「プラグイン」の「新規追加」をクリック。
「検索」であることを確認し、キーワードに「Ktai Style」を入力して、「プラグインの検索」をクリックします。

（おそらく）一番上にKtai Styleが表示されるので、「インストール」をクリックします。

「今すぐインストール」をクリック。

 
「プラグインを有効化」をクリック。

  このように左サイドに「携帯表示」という項目が追加されています。

「テーマ」をクリックして、デザインを設定します。

パソコン用のテーマに比べれば、派手なものはありませんが、シンプルで見やすいデザインがいくつか揃っています。

Ktai Styleは、携帯でアクセスしないと動作しないので、携帯からアクセスしてみてください。

WordPressの初期状態のカテゴリーの順番は、新しく作成したカテゴリーほど上に並びます。
ただ、これだと見栄えが悪かったり、サイトのメインのカテゴリーがどれかわかりづらかったりするので、カテゴリーを思い通りに並べ替えるプラグインは必須だと思います。

ダウンロード

My Category Orderは、リンク先からダウンロードできます。

ページ右上部の「Download」をクリックします。

適当な場所に保存します。

日本語化

インストール

 
WordPressの管理画面にログインし、「プラグイン」の「新規追加」をクリック。
「アップロード」タブをクリックし、「ファイルを選択」で先ほど保存したファイルを指定します。
「今すぐインストール」をクリック。

 
「プラグインを有効化」をクリック。

 
もし「Category Order」を使っている場合、「停止」をクリックします。

 
つづいて、「外観」の「ウィジェット」をクリックします。
ウィジェットの一覧が表示されます。その中に「My Category Order」があるので

このように、ドラッグ&ドロップします。

「投稿」の中に「My Category Order」という項目が出来ているので、クリックします。

最後に「Click to Order Categorys」をクリック。

上が、My Category Orderで並べ替えたもの。
下が、Category Orderで並べ替えたもの。
My Category Orderは、記事の件数が表示されていません。

記事の件数を表示させる

それぞれのカテゴリーの記事の件数を表示させたい場合は、以下のようにします。

「外観」の「ウィジェット」をクリック。

先ほどドラッグ&ドロップした「My Category Order」の▼の部分をクリック。
表示された項目の下の方の「Show Count」にチェックを入れ、「保存」をクリック。
これでカテゴリーの記事の件数が表示されるようになります。

不思議なのが、コメントを投稿した人のIPアドレスがバラバラということ。
おそらくプロクシを通しているんでしょうけれど。

それと、こうしたスパムコメントには決まって意味不明な文字列（たとえば、9MP13gとか）が記載されていて、URLも記載されているんですけれど、そのURLがやっぱり適当なURLだったり・・・。
SEOのためのコメントスパムかと思ってたけれど、単なる嫌がらせ？？

コメントスパムを防ぐプラグイン Akismetを使う

WordPressに初期からインストールされているコメントスパム用のプラグインAkismetを使用してみました。

WordPressの管理画面にログインし、「プラグイン」の「インストール済み」をクリックします。

プラグインの一覧の上の方に「Akismet」があるので、「使用する」をクリックします。

WordPress.com API キーを取得

このままだとAkismetは使えません。
WordPress.com APIキーが必要です。
http://akismet.com/get/へ行き、メールアドレスを入力します。

「Choose a username」に名前（半角英数字）を入力。
「I have read and agree to the Akismet terms of service.」にチェックを入れ「Next」をクリックします。

登録が完了しました。
登録したメールアドレスに、確認のメールが届いているはずです。

メールに記載されているURLをクリックすると、API Keyが表示されます。

APIキーを入力します。
「設定を更新」をクリック。

このように表示されれば有効になった証拠です。

スパムコメントを確認する

ダッシュボードに「Akismet統計」が追加されているので、クリックすると、スパムとして削除したコメントをグラフで表示させることが出来ます。

さっそくスパムコメントが引っかかりました。
このAkismetを有効にしておくと、コメント通知が飛んできません。
また、自動的にコメントスパムへ振り分けてくれます。

[ 追記 ]
1日経過した結果です。
この通り100%スパムコメントをとらえてスパムフォルダに振り分けています。

私の場合、Apacheのログから自分で作成したプログラムで、アクセスを解析しているんですけれど、まぁ、今回、完全にGoogle Analytics任せにしてしまってもいいかなぁ。と。
私が作ったプログラムでは、どんな検索サイトからなんというキーワードでアクセスしてきたかを1件1件丸1日分表示してくれるので、単純明快でわかりやすいっていう特徴があるんですけれど。

そっちの方はやろうと思えばすぐにでも導入できるんで、いつでもいいかな。と。
あと、レンタルサーバーを借りることになったら、そういったプログラムを動作させられなくかもしれないし。

Google Analyticsをプラグインで導入

Google Analyticsは、プラグインで導入出来るみたいです。

インストール

WordPressの管理画面の「プラグイン」をクリックし「新規追加」をクリック。
検索キーワードを「Google Analytics」として「プラグインの検索」をクリックします。

色々ヒットしましたね。
とりあえず、一番上のGoogle Analyticsを選択してみました。「インストール」をクリック。

「今すぐインストール」をクリック。

 
インストールが完了しました。
「プラグインを有効化」をクリック。

Google Analyticsでの設定

つづいて、Google Analyticsへログインします。

管理しているアカウントをクリックすると、右上に「新しいプロファイルを追加」というリンクが表示されるので、クリック。

ドメインを入力し、「Finish」をクリック。

「ウェブプロパティーID」がトラッキングコードとなります。
このトラッキングコードをコピーします。

「Google Analytics UID」へ貼り付けます。

「Google Analytics logging is」を「Enabled」にします。

「Admin tracking disable method」を「Use “admin” variable」にします。
一番下の「Save Chenges」をクリックします。

Google Analyticsで確認

 
WordPressのブログのどのページでもいいので、一回アクセスします。
※ これによってGoogle側でトラッキングコードを確認します
上のように「！」が表示されていると、まだトラッキングコードの確認がGoogle側で出来ていません。
キャッシュを使って高速化させている場合は、一度キャッシュを削除するか無効にしてください。

このように時計表示であれば、Google側で認識できたことになります。
正式に稼働するには、24時間ほどかかるのでこのまま待ちます。

先ほど設定した「Admin tracking disable method」を「Remove」にして保存します。
こうすることで、ブログ投稿者のアクセスは記録されません。
※ ただし、キャッシュを使って高速化させている場合は、記録されてしまう可能性があります。

実際のアクセス解析

 
設置して半日ぐらいで、アクセスを記録しはじめたようです。

さて、この「関連する記事」のリストアップしてくれるプラグインを今回紹介します。
うまく動作しているか・・・は、まだページ数が少ないんで何とも言えないんですけれど、採用しているブログさん達を見ていると、うまくいってそうな気がするので、参考にしてみてください。

YARPP

関連する記事のリストをピックアップしてくれるプラグインは、割と多いらしいんですけれど、その中でも人気があって、なおかつ、割とまとも（？）に動作するのが「YARPP」というプラグインです。

インストール

プラグインの検索とインストールが超簡単なのがWordPressの最大の特徴。
さっそくYARPPを検索、インストールしてみましょう。

管理画面へログインし、「プラグイン」の「新規追加」をクリックします。
「検索」タブであることを確認し、キーワードの部分に「YARPP」と入力します。
「プラグインの検索」をクリック。

いくつか適合するプラグインが表示されます。
「Yet Another Related Posts Plugin」が「YARPP」に当たります。
画面左側の「インストール」をクリックします。

「今すぐインストール」をクリックします。

「プラグインを有効化」をクリックすれば、インストールが完了です。

準備

 
管理画面の「設定」の中に「関連記事（YARPP）」という項目が追加されるようになりました。
クリックします。

他のプラグインと違って、実はこれだけでは動かないんです。
上のように警告が表示されます。
そこでインストールした「YARPP」のファイルの

wp-content/plugins/yet-another-reloted-posts-plugin/yarpp-templates/

に保存されているファイルを、テーマが保存されているフォルダにコピーします。
テーマは、

/wp-content/themes/XXXXXX
※「XXXXXX」はテーマによって違う

になります。

コピー元のファイル達です。この5つのファイルを・・・

私の場合は「JS-O4w」というテーマを使用しているので「js-o4w」というフォルダにコピーします。

 
先ほどの警告が表示されなくなりました。

なにも設定しなくても動作しますが、変えておいた方がいい部分をざっとピックアップしておきます。
「関連記事囲むタグ」の部分に「この記事に関連する記事」と入力すると、わかりやすくなります。
また、関連する記事が無いときに表示されるメッセージも「関連する記事はありません」みたいな事を書いておくと、わかりやすくなります。

こんな感じ。
正直、ほんとに関連しているかどうかは、？？ですけれど、いちいちピックアップして自分で記入したり、タグで分けたりするのもめんどくさいので、自動でピックアップしてくれるYARPPは、便利かもしれません。

さらに調べると、WP Super Cacheというに多様な機能を提供してくれるプラグインがあることがわかりました。
参考にしたのは、「WP Super Cache」というプラグインを使ってみました

WP Super Cacheをインストールする

 
WordPressの管理画面の「プラグイン」の「新規追加」を開きます。
「WP Super Cache」でプラグインを検索します。

 
一番上に表示された「WP Super Cache」の「インストール」をクリックします。

「今すぐインストール」をクリック。

「プラグインを有効化」をクリック。

「設定」をクリックします。

設定項目は非常に多いんですけれど、とりあえず一番上にある「オン WP Cache とSuper Cacheを使用する」にチェックを入れて動作させてみました。
「ステータスを更新」をクリックします。

試してみる

設定を有効にさせた直後です。
まだキャッシュされたページはありません。

試しにアーカイブのひとつをブラウザでアクセスしてみました。
その後、ステータスを更新してみると・・・
上のようにキャッシュページ数が1になっていました。

その時の様子をビデオで撮影してみました。

効果はてきめん！

威力はてきめんでした。
アーカイブページを表示させたところ、キャッシュされる前は約3秒ほどかかりました。
WP Super Cacheは、一度アクセスするとキャッシュが作成され、次回以降そのキャッシュを利用して出力されるため、非常に表示が速くなります。
よって2回目は、一瞬で表示されています。

トップページは特に劇的な変化で、キャッシュ前は11秒程かかりました。
ところがキャッシュ後は、一瞬で表示されるようになりました。

キャッシュの状態

ある程度時間が経過したものは、削除されるようです。
この時の時間も変更可能です。

とにかくものすごい効果なので、もしWordPressを使っているのであれば、是非とも使いたいプラグインのひとつです。
最新のバージョンでは日本語表示に対応しているようです。

注意

ひとつ気がついた点があります。
まず、新しい記事を投稿すると、トップページのキャッシュは削除されるみたいです。
上の画像は、新しい記事を投稿した後のキャッシュの状況で、トップページ（wordpres.f-tools.net/のところ）の経過時間が「158」になっています。
wordpress.f-tools.net/setting/178.html/ が、投稿した記事のURLで、「125」になっています。

ところが、新しい記事が所属するカテゴリーのページ wordpress.f-tools.net/category/setting が「1385」でキャッシュが更新されていません。
このページに何度アクセスしても、表示されるのは記事を投稿する前の状態のままです。

WP Super Cacheは、WP CacheとSuper Cacheの2つのモードがあって、

• WP Cache・・・ファイルが更新されるとそちらを表示
• Super Cache・・・ファイルが更新されてもキャッシュを表示

Super Cache

その後、先ほどの wordpress.f-tools.net/category/setting が、「古いSuper Cache」に移動されています。

ところがこの状態で wordpress.f-tools.net/category/setting にアクセスしても新しく投稿した記事へのリンクは表示されていませんでした。

どうやら「 Super Cache 」モードだと、キャッシュファイルがある限りキャッシュの方を表示させるようです。

投稿した記事を修正してみると

さて、今度は先ほど投稿した記事を修正してみました。
すると、上の画像のようなステータスになりました。
トップページと、 worpress.f-tools.net/setting/178.html/.needs-rebulid というファイルが更新されたみたいです。

実際にトップページにアクセスしてみると、きちんと修正した内容が反映されていました。
ところが、カテゴリーページは記事の投稿前のままでした。
どうやら、Super Cacheモードだと、古い状態が表示されてしまう可能性が高いようです。
その分高速ですが。
もし、更新をあまりしなくなったブログで、アクセス数が多ければこのSuper Cacheモードの方が向いているかもしれません。

WP Cache

つづいて「ハーフオン」モードにしてみました。

このハーフオンモードだと、記事を投稿・修正すると、関連するページがすべて更新されるみたいです。
たとえば、記事ページ、トップページ、カテゴリーページどれも更新され、2回目以降のアクセスはキャッシュを使うようです。
再び記事を修正すると、キャッシュが無効になります。