WordPressで自動関連記事表示プラグインとRelated Posts for WordPressを組み合わせて利用する方法

前回紹介しました関連記事を手動で選択表示できるプラグインRelated Posts for WordPressの応用版になります。

手動で関連記事を設定するRelated Posts for WordPressと自動で関連記事を表示させるWordPress Related Posts等を一緒に利用して、手動関連記事を設定していない記事にも関連記事を自動で表示できるようにする方法を公開します。

主な対象としましては

・既に沢山の記事を投稿していて、過去記事にさかのぼって関連記事を手動設定するのが大変な方
・毎回関連記事を手動設定するのは面倒な方

だと思います。

今回Related Posts for WordPressと一緒に導入するプラグインはWordPress Related Posts、またはYet Another Related Posts Pluginになります。

自動で記事を表示されないようにする

各プラグイン設定画面で、関連記事表示チェックボックスをOFFにします。

・Related Posts for WordPressの場合

・WordPress Related Postsの場合

・Yet Another Related Posts Pluginの場合

関連記事を表示したい場所に、下記を記載

wp-content/themes/テーマ名/single.phpの関連記事を表示したい場所に、下記を記載します。
概ね、the_content()以下だと思います。

Related Posts for WordPressとWordPress Related Postsを併用する場合

<?php
$related_posts = MRP_get_related_posts( $post->ID, true );
if($related_posts) :
MRP_show_related_posts();
else :
wp_related_posts();
endif ;
?>

Related Posts for WordPressとYet Another Related Posts Pluginを併用する場合

<?php
$related_posts = MRP_get_related_posts( $post->ID, true );
if($related_posts) :
MRP_show_related_posts();
else :
related_posts();
endif ;
?>

以上になります。

今回はプラグインのコアハックはしてませんので、プラグインの仕様が大幅に変わらない限りアップデートにも対応出来ると思います。

現場の声に対応する

今回この記事を書いた経緯として、鈴木謙一さんの下記のつぶやきがキッカケです。
「Related Posts for WordPressを利用しようと思ったが、既に2000記事以上あるので、過去記事にさかのぼって関連記事を手動設定するのは難しいという」意見です。

長年運用しているブログでは起こりえる事ですし、実際、困っている方も多いのでは無いかと思いました。

そして現場の声を聞き、それに対応する案を提出する事が実践者としては重要だと改めて思いました。
そして実践者の最大の協力者は情報発信者です。

話がそれてしまいましたが、当ブログでも実装済みですので、是非ご利用ください。


WordPress関連記事を手動で選択表示できるプラグインRelated Posts for WordPressが便利すぎる

記事が一部間違ってました。

[修正済み]
・プラグインの正式名称
Related Posts for WordPress

・ダウンロード先

http://wordpress.org/extend/plugins/microkids-related-posts/

先日、はじめて使ったWordpress関連記事を手動で選択表示できるプラグインRelated Posts for WordPressが便利すぎましたので、紹介します。

このプラグインを導入すると、記事を投稿する際に自分のブログにある類似した記事を手動で選択し、、関連記事として記事下に内部リンクで紹介できるようになります。

何が便利かと言いますと、

・関連選択した記事にも逆に内部リンクが張られる ←個人的に神機能
・自分の過去記事をタイトルタグ、本文、その両方で簡単に検索できる
・検索して出てきた記事をクリックするだけで選択出来る

になります。

説明しづらい部分もありますので、ひとつひとつ紹介します。

すぐに利用したいと言う方は、記事下に設定項目の例がありますので、そちらを参考ください。

関連選択した記事にも逆に内部リンクが張られる

記事Aからの関連記事で記事Bを選択すると、記事Bからも記事Aへリンクすることが可能です。

これで、関連するサイト内ページ同士でトラフィック誘導が期待できます。
1ユーザーのページビュー数を上げる事により、言及される可能性が上がりますので、ソーシャル対策、ナチュラルリンク対策としてお薦めです。

※この自動内部相互リンク設定をするためには、ページ最下部に記載している基本設定「1」でYesを選択する必要があります。

自分の過去記事をタイトルタグ、本文、その両方で簡単に検索できる

記事投稿画面下に、関連記事選択フォームが出てきます。
Search itemsの欄に検索したい言葉を入力するだけで、自動で過去記事が出現します。

ただし、日本語検索の精度が悪い時がありますので、その場合は「both」を選択する事でタイトル、本文の両方から記事を検索可能になります。

検索して出てきた記事をクリックするだけで選択出来る

クリックするだけで関連記事を選択でき、また、ドラック&ドロップで順番の入れ替えも可能です。

Related Posts for WordPressの基本設定

僕が利用しているRelated Posts for WordPressの基本設定です。
ご参考ください。

「1」が関連選択した記事にも逆に内部リンクが張られるか選択する項目
「2」が関連記事が無い時に「無いことを表示」or「何も表示しない」の選択項目(確かデフォルトがShow this textだったと思います)

Related Posts for WordPressを使う事はページビューを増やす事につながると思います。
是非、利用してみてください。

関連記事を手動で選択するのが面倒な方は、自動で表示させてくれるプラグインもお勧めです。
WordPress関連記事を表示するプラグインを3つ紹介


Googleのキャッシュを元にWord Pressを復元させる方法

今回の記事はシステム詳しい方向けです。
僕は成功した手順ですが、自己責任でお願いします。

突如起こるサーバートラブル。
こればっかりはサーバー会社に文句を言っても始まりません。

本当に喪失したくないデーターはセカンドサーバーや自社サーバーで厳重にバックアップを取るしか手段がありませんので。

しかし、WordPressの場合、データベースが壊れてしまった場合、どうやって復元するか悩みますよね。

特に、POST IDをURL含めている場合

例えば
http://www.seo-searchengine.net/deadseo/archives/139.html
感じに。

このブログもそうですが、その場合の記事データの復元方法です。

1.まずは普通にwordpressを新規インストール

まずは、普通にwordpressをインストールします。

そして、パーマリンク等もろもろの設定をすませます。

その際に、Pingは飛ばさないように設定を変更しましょう。
作業中の内容をGoogleが拾ってしまいますので。

2.Googleで検索

Googleで記事データだけ検索します。

僕の記事の場合
http://www.seo-searchengine.net/deadseo/archives/139.html
ですので
site: http://www.seo-searchengine.net/deadseo/archives/
とググルと記事データがのみ出てきます。

3.phpMyAdminよりAUTO_INCREMENTでIDを操作

ここから突然レベルアップします。

phpMyAdminにログインして、下記の図にあるAUTO_INCREMENTを次にPOSTしたIDに書き換えます。

そうすることで、次に投稿できるPOST  IDを操作できますので、URLをそのまま復元できる形になります。

Googleのキャッシュで拾った記事をWPの管理画面から通常通り投稿します。

ただし、何度AUTO_INCREMENTを設定しても若い番号にならない場合

(例: AUTO_INCREMENT を 5にしても5以下の数字にならないなど)

すでにそのID以下の投稿が存在する場合があります。

その場合は下記の図のように投稿内容を削除する必要があります

ただし、削除するIDは、投稿ではない

・リビジョン
・下書き

に留めておいたほうが良いです。

本投稿のIDは削除しない事をお勧めします。


ワードプレスでブログサービス運営の問題

SEO対策無双さんが無料ブログサービスを立ち上げたらしいのですが、
http://www.c-recipe.biz/
ワードプレス使ってるのかな??

ってことは今後運営上の問題は、サーバー負荷ですね。

特に、海外スパマーに発見されると、変なアカウントを取られまくられ、ブログが一気に増え、サーバー負荷が一気に増します。
自分で試した感じではxreaなんか10ブログで既にヤバいくらい表示速度になるので、通常の月1000円くらいのサーバーでも、100アカウントも作られると、サーバー負荷増すんじゃないかな?

無料ブログサービスってサーバー負荷との戦いだと思う。
頑張ってください!!


Google App Engineを使ってみた

お正月、実は風邪をこじらせてしまい、超具合悪くてグロってました。

そんな中でも、今しか時間が無いと思い、Google App Engineを勉強してたんですけど、イクリプスを使った開発環境が案外簡単に構築できたのが幸いでした。

実はJAVAを触ったことがなく、今回はじめてJAVAを使ってみたのですけど、サーブレットとJSPの役割を理解できただけでも進歩できたと思います。

で、自分にとってJAVA上でPHPを動かしたほうが早いと思って、結局Google App Engine上でPHPプログラミングして遊んでました。

結果、思ったことは、Google App Engineは制限が多いので、きちんと計画性を持って使わないと意味なしって事です。

最初っからGoogle App Engine用にプログラム組まないとダメって事ですね。

これがわかっただけでも良かったです。


Twitterは嫌いだけど、Twitter APIは好きだよ

今年2月くらいにTwitter APIを触って、オモシレーって思いながら、頭の中で面白そうな企画練ってたんだけど、最近、やっとまとまって来た。

あとは、Twitter APIの利用規約をよく読んで、違反しないようにしよ~

Twitter API、結構、金の臭がするんだよね。

なんかすごくねー!!!
Twitterやった事ない人が、Twitter APIでサイト作るのって。
って、よく考えたら、世の中のプログラマ、大抵、クライアントの言われるがママシステム作るから、普通か。


wordpressのbreadcrumb-navigation-xtのバグ修正

worpdressのパンクズ表示プラグインbreadcrumb-navigation-xtで、タイトルの文字制限すると文字化けしませんか?

たとえば、こんなオプション付けると。
$mybreadcrumb->opt['posttitle_maxlen'] = ’21′;

その場合、breadcrumb-navigation-xt.phpの274行目を
$bcn_post_title = substr($bcn_post_title, 0, $this->opt['posttitle_maxlen']-1) . ‘…’;
から
$bcn_post_title = mb_strimwidth($bcn_post_title, 0, $this->opt['posttitle_maxlen']-1) . ‘…’;
に書き換えるとOKです。

まあmb_strimwidth使うんだったら
$bcn_post_title = mb_strimwidth($bcn_post_title, 0, $this->opt['posttitle_maxlen']-1,’…’);
でも良いんですけどね


Boss_さんへPHPの書き方のアドバイスをしてみる

余計なお世話ですが、SEO薬箱の上司!?のBossさんが書いたPHPへ勝手にアドバイスしてみました。

アフィリエイト目的のPHPとその逆

で、問題の個所は

$dev = $_GET['did'];
$aff = $_GET['aid'];

$output = ‘http://twitter.com/’ . $dev;
$output.= ‘/’ . $aff . ”;
echo $output;

まあ、動くのですが、もう少し正確に書くなら$_GETが空のときの処理を書いたほうがいいです。

ですので、たとえば最初の処理で

$dev = $_GET['did'];

の部分を

//まず、変数を宣言するのがベスト
$dev = “”;

if(isset($_GET[‘did’)){
$dev = $_GET['did'];
}else{
$dev = “boss_”;
}

とか、もし表示させないんだったら

$dev = “”;

if(isset($_GET[‘did’)){
$dev = $_GET['did'];
}else{
header(“HTTP/1.1 404 Not Found”);
exit;
}

とかだと、ゲットしなければ余計なインデックスを流さなくて済みます。

こういったこちらが想定しないユーザーの動作に対し、どう処理をするかで、
後に長々とPHPを書いた時のハッキング対策や、SEO面でも有利になります。

もしこれがPOSTだと

if($_SERVER["REQUEST_METHOD"] == “POST”){
// POSTを要求された場合
}else{
// POSTを要求されない場合
}

とか判別できます。

GETでこれやると、なんかたまにブラウザがおかしな動きするので、あんまりやってません。
※けどGETのときも必要なのかな~

あと、偉そうですいませんがPHPある程度勉強したら、次はハッキングの方法を知る方がいいです。
私も結構ハッキングしかたわかるので。
つまり、ハッキングの仕方がわからないと、それを防ぐ方法も判らないって事ですので。

しかも、それ以上のハッキングしてくる輩もいますので。
※現状ではGET値をそのまま表示しているので、意図しない外部リンクを埋め込まれる可能性があります。

話それますが、某有名検索エンジンプログラムのPHP版も、サーバー環境によっては中のデータをハッキングでいじり放題なのをプログラムの記述レベルで確認しております。
多分、MySQLへのクエリ文見たらだれでもサーバー設定次第でハッキング可能だと判ると思いますよ。
ああいう配布型のプログラムは、いろんなサーバー設定を考慮してPHP書かないとね。

って勝手にアドバイスでした。


wordpress3 RC2がなかなか良い感じ

wordpress3 RC2になってから、なかなか良い感じに仕上がってますね。

RC1でバグってたところがほぼ解決している点なんか、すばらしいです。

実は、wordpress3をSEOに思いっきり使おうと思ってたから、待ちに待ってました感があります。

もう、フライング気味で使い始めちゃってます。

ただ、wp関数が若干変更あるっぽいので、勉強しなおさないとね。


MySQLの負荷について

外注先のシステム屋さんに作ってもらったプログラムが、最近負荷がすごくて、PHPの設計を変更してもらいました。

とりわけ、MySQLですね。

どうも最初の修正時の設計間違って、MySQLから出来る限り大きなデータを取り出して、それをキャッシュさせて、PHPで動かそうと思ったが、MySQLって取り出すデータ量多い方が負荷掛かるみたいです。

ですので、次は出来るだけ詳細なクエリを投げて、必要な分だけキャッシュしてみたんです。
そしたら、サクサク動いてくれたんで、まあ、良しかな。

これに味占めて、MySQLに負荷がかかりそうなFunctionをすべてキャッシュしてやった。

これで、サクサク動いてくれればいいんですが・・・・専用サーバーで4Gメモリでも、ギリギリなプログラムって一体・・・


ページトップへ