WordPress Related Post for Japanese 1.50 RC リリース

WordPress の関連記事表示ためのプラグイン、WordPress Related Post for Japanese の 1.50 RC をリリースしてみます。 Yahoo! Japan の API エントリポイント変更対応が入っていますので、アップグレードのほうお願いいたします。 機能追加もいくつかありますが、不具合なさそうならそのまま JSeries のほうにリリースします。 🙂

現バージョンと表示は互換を持たせてあるはずなので、アップグレードの方はそのままファイルを上書きしていただければ良いと思います。 辞書の再生成はしなくても大丈夫だと思います。(解析テキストに the_content フィルタかぶせたので若干変わっていますが、影響ないところがほとんどかと思います)

wp-jralated.tar.gz

とりあえず、ダウンロードは CVS Head からです。

新規インストールの場合は JSeries をご参考にファイルだけこちらをお使いください。

WordPress Related Post for Japanese

Yahoo! Japan が提供する日本語形態素解析APIを利用して、WordPress の投稿をアナライズし、自動的に投稿の下部に「関連する記事」へのリンクを付与するプラグインです。

wp-jrelated は辞書作成のため Yahoo! Japan の日本語形態素解析を使っていますが、こちらの API の URL が(実は結構前に)変わっています。 おそらくそのうち旧 URL は使えなくなって辞書つくれなくなるとおもいますので、使われている方は適宜アップデートの方向でお願いいたします!

URL の変更は新機能対応をするときに変更しようとおもっていたら遅くなってしまいました。

というわけで今回はをかもとさんのストップワードの対応もマージさせていただきました。 以下変更点です。

  • Yahoo! Japan 日本語形態素解析のエントリポイント URL 変更対応
  • をかもとさんに作っていただいたストップワード対応をマージしました。 単語設定は管理画面から行えます。
  • 形態素解析前に the_content のフィルターを通すように修正しました。 ショートコードやプラグインなどで文字列置換を行っている場合に置換後のテキストで辞書作成を行います。
  • 出力関連数、検索単語数、出力単語数を管理画面から設定できるようになりました。
  • the_content により自動的に記事の下に表示するのとは別に、新設された jrelated_get_array 関数により関連情報をつめた配列を取得できるようになりました。 これをテーマに記述することで自由度の高い表現ができます。

ストップワード対応は以下の記事を参考にさせていただいています。

WordPress Related Post for Japanese 導入 : 独断と偏見の何でもレビュー

とりあえず、試験的に導入したこちら以外のブログでは、英文記事の引用が多いため “this,that,it,is,of,in,and,the” なんかのいわゆるストップワードが頻出単語上位に含まれるため、精度がイマイチ。
と言うわけで、簡単なストップワード対応をしてみました。

wp-jrelated は記事に頻出する名詞がその記事の特徴を表すという考えのもとに作られていますが、その中に記事の特徴を表すわけではない一般的な単語が各記事に多く現れると抽出の精度が落ちてしまいます。(あんまり関係ないのがでちゃう)

これに対して一般的な単語を検索対象からはずす機能がストップワード指定です。 アップグレードの方は最初は指定されていませんので、管理画面から指定してみてください。 🙂

ちなみにぼくの設定は、

this,that,it,is,of,in,and,the,とき,こと,ところ,もの,こちら,あと,これ,やつ,ため,わけ,の,ふ,0,1,2,3,4,5,6,7,8,9

です。 これはサイト(言葉遣い)によって変わりますので、辞書のテーブルとにらめっこして特徴と関係なさそうな単語が上にきていたらそれを指定していってみてください。 🙂

jrelated50

また管理画面から”検索単語数”が指定できます。 これは頻出単語の上位どれくらいがその記事の特徴を表すかの指定です。 前回は 10 固定でやっていましたが、これを変更できるようにしました。 .another では 15 くらいがちょうど良さそうです。 こちらも記事の平均的な文章の長さなどにも左右しますので調整してみてください。 ちなみにあんまりでかくすると意味ないうえに遅くなりますぞい。

ストップワードと検索単語数は即検索結果に反映します。

最後に、新設された jrelated_get_array 関数ですが、引数に post_id を渡すと関連の情報をつめた array を返してくる機能です。 形は・・・

jrelated51

です。。

array[ポストid][‘title’]、array[ポストid][‘link’]、array[ポストid][‘text’] になります。 スクリーンショットが文字化けしているのは、デバッガが日本語を化かしてしまうからで、ほんとはちゃんとした日本語が入ってきます。

管理画面で、the_content の自動出力をやめるように設定して、テーマを変更して次のようなプログラムをいれると出力できます。

うちの wp-kougabu もついでに呼び出して関連記事の画像も出力するところの抜粋です。

single.php。 the_content の下あたりにいれるといいでしょう。

<?php // ポストの関連情報を $jrelateds に取得 ?>
<?php $jrelateds = jrelated_get_array(get_the_ID()); ?>
<?php // wp-kougabuに問い合わせるために出力する関連記事のpost_id配列作成 ?>
<?php $post_ids = array(); ?>
<?php foreach($jrelateds as $post_id=>$value) {
    array_push($post_ids, $post_id); } ?>
<?php // wp-kougabuにつくった配列渡して関連記事の画像URLを先にもらっておく ?>
<?php $images = kougabu_get_images(
    array('array' => true, 'post_id' => $post_ids
    , 'max_width' => 100, 'max_height' => 100)); ?>
<div id="wpjr">
    <h3 id="related">このブログで関連すると思われる他の投稿</h3>
    <ul id="wpjrelated">
    <?php // wp-jrelated からもらった関連記事をループする ?>
    <?php foreach($jrelateds as $post_id=>$jrelate) { ?>
    <li>
        <div class="thumbnail">
            <?php // wp-kougabu 画像がその関連にあれば出力する ?>
            <?php if(isset($images[$post_id])) {
                echo $images[$post_id][0]; } ?>
        </div>
        <div class="sumarry">
            <?php // wp-jrelated からリンクと頻出単語を出力する ?>
            <a href="<?php echo $jrelate['link']; ?>">
                <?php echo $jrelate['title']; ?></a><br>
            <?php echo $jrelate['text']; ?>
        </div>
    </li>
    <?php } ?>
    </ul>
</div>

自動出力と違って HTML タグは好き勝手にできますので、こちらのほうが人によっては使いやすいかもしれません。

画像を出したくて wp-kougabu 使ってないよ~という方は、

hiromasa.another :o) » Blog Archive » WordPress メディアライブラリから指定ポストの画像を一括取得する

WordPress Related Post for Japanese の関連に画像を出力してみた試験をしたときに「SQL で一括~」なことを書いていたら、yuriko さんが SQL を書いてくださいました。早速試させていただいたところ、みごとに一発抽出できました。 :-)

こちらの SQL をアレンジしてつけてみてください。

画像とかいらないよ、というかたは適宜それっぽいところを削除の方向で。 CSS はみなさんのほうがずっと詳しいので各自お願いします(笑)

というわけで、長くなってしまったのであとはのりで。。 不具合などありましたら教えてください。 😀

帰ってきました

ちょっと私用のため札幌を放れて旅人になっていました。 というわけで道中の写真などを。 北海道はまだまだ雪景色が残ります。 🙂

北海道某所、パーキングエリア。

kuma01

太陽を撮ってみたらなんと黒点が!!(嘘) ・・・なにか明るすぎてカメラのソフトがバグったような画像の気がするのですが気のせいでしょうか?! それとも未確認飛行物体か!?

kuma02

そこで地獄にいってみました。(意味不明

kuma03

出発前、待ち時間用に iPod touch の DanceDanceRevolution S を買ってみました。 (結局道中はあんまりやらなかったのは秘密だ

体験版ができものだったので本物も購入です。 大変良作。 これで 800円 はお買い得。 10曲 + α ということで曲買うだけでもっといきますよね(笑) 適当にぽちぽちやって実績解放 50% くらいで既に 7曲増えました。

DDR は昔、酔っぱらってやるのが恒例だったものです。。 ゲーセンのは初代しかやったことありませんが、今も結構でているんですね~。

touch のは足でやらずに指でやります。 なんだか加速度センサー使って振りながらやるモードもあるらしい。

ddr03

キャラも選べます。

ddr02

曲も選べます。(あたりまえ。。

ddr01

音ゲーやったことあるひとなら適当にやってもクリアできるのでサクサクあそべてかなり面白いす。 ハードにするとぼくは初見は無理、、しばらく遊べそうです。 🙂

というわけで、ただいまです。(遅い

Head Cleaner(仮) を入れてみました

をかもとさん作の WordPress プラグイン、Head Cleaner(仮) を先日から導入してみています。

ブラウザがレンダリングに必要とする CSS ファイルや動作に必要な JS ファイルの多くはHTML の head 要素に集まっていますが、たとえばこれが大量にあるとブラウザは何度もサーバに対して読込みリクエストをだす必要があり、サイトの表示までに時間がかかるようになってきます。(head 読み終わらないと body にいかない)

このような head をうまく修正してブラウザのレンダリングを早くする手法はいくつもあるようなのですが、をかもとさんの Head Cleaner はプログラムに様々な最適化テクニックをつめこんで head などを自動解析し、サイトの表示を速くしてくれるプラグインです。

Head Cleaner (仮) : 独断と偏見の何でもレビュー

WordPress にプラグインをガンガンと突っ込んでいくと <head> 部に、JavaScript やら CSS やらが、ドンドン追加されて、カオスなことになってしまいます。
そんな状態の自サイトを「YSlow for Firebug」で診断してみると、とても低いスコアになったりしてガックリ来るわけです。
プラグインを外したりしたくなかったりするので、チマチマと修正したりして使っていたんですが、プラグインのバージョンアップのたびに修正するのも面倒です。

もちろん効用はサイトが高速に表示されるのもありますが、特に WordPress の場合、プラグインによって head にいろいろ追加されて、改行とかインデントとかも変なことになりがちなので、再パースしてきれいにしてくれるのも嬉しい効果です。

さて、この head 再パースですがこれは当然サーバ側の処理。 当然いくらかは時間がかかります。 サーバパース時間 < ブラウザの読込時間 となれば全体的に高速ということになります。

まぁネットワークとサーバ処理の競争なので、後者のほうが速いであろうことは確かです。

[tegaki]どれくらいかかるんだろう?[/tegaki]

をかもとさんもおっしゃっていました。

WordPress サイトのフロントエンドの処理速度が、結構改善されると思います。ただし、バックエンドに負担をかけますが

おし、調べてみましょう。 🙂

以前書きました、PHP 用の xdebug というデバッグモジュールですが、こいつはプロファイラの機能ももっています。 各処理にかかる時間とかを測定できる機能です。

これで動作ログをはかせて、WinCacheGrind というソフトでよませるときれいにサマって表示してくれるます。 (KDE 用のもあるのですが、ちょっと KDE 調子悪いので Windows にて。。)

profile01

head のパース処理のみしぼりこんでみてみました。

profile02

profile03

小さくて申し訳ない。。 一番右の累積時間をみれば良いと思います。 関数の呼び出し順もあるので単純に合計はできませんが、、、ははは、数ms 単位が並んでいるのが分かります。 ネットワークとは相手にならない速度でこりゃ高速化されるわけです!。 これであれば負荷もほとんど影響しないでしょう。

せっかくなので自分のプラグインも見てみました。 ぼくので一番重量級なのは、jrelated です。 あれは、辞書を全読みしないとだせないのでおもい。(といっても 多くても1000とか2000レコードオーダなのででかいアプリにくらべれば全然ですが)

profile04

上から順にメソッド呼ぶので全体で 66ms + α となると思います。 うちのサイト全体が 0.350ms くらいなので思ったよりおもくないですね!。

次は kougabu。(同期部のみ)

profile05

あら、こんなもんなんだ。(笑)

これは xdebug のプロファイル機能を ON にしている(負荷がかかる)状態なので、実際にはもう少し速くなると思われます。  PHP なかなかやるじゃん、と思った瞬間でした。(ぼくのほうはMySQL かもだけど。。

というわけで脱線してしまいましたが、Head Cleaner いれると体感的にも速くなるのが分かります。 すごいなぁ。 ぼくには絶対つくれない種類のプラグインなので、をかもとさんについていこうとおもいます。 🙂