月: 2009年3月

PHPで実装するレコメンドエンジンについての覚書

「この商品を買った人は、こんな商品も買ってます」

アマゾンでお役立ちの、アレ。

レコメンドエンジン機能という。

これは、協調フィルタリングという手法で実現されているらしいです。

協調フィルタリング(Collaborative Filtering, CF)は、多くのユーザの嗜好情報を蓄積し、あるユーザと嗜好の類似した他のユーザの情報を用いて自動的に推論を行う方法論である。趣味の似た人からの意見を参考にするという口コミの原理に例えられることが多い。

なるほど。

で、実は、この機能を簡単に実装できるPHPのライブラリがありました。

VOGOO: http://www.vogoo-api.com/

フリーとプロ版があり、ふりーは、mySQLとポスグレの2つのDBに対応しているので、EC-CUBEにくっつけて使えそう。

サイトは、英語だけど、サイト内には、チュートリアルもあって、使い方なんかも詳しくかかれているっぽいので、時間が取れたら、ちょっと調べてみることにするワ。

とりあえず、覚書として残す。

参考:http://www.richcontext.jp/rss/richcontext.jsp (こんなのもある)

【EC-CUBE】初回の買い物は、ポイント●倍にする

EC-CUBEを再びカスタマイズ。
初回の買い物は、ポイント●倍にして、その倍率は、管理画面のパラメータ設定で変えられるようにする。

その1)初回の買い物かどうか、判定してポイントを●倍にするロジックを追加。

/data/class/SC_CartSession.phpの function getAllProductsPoint() に下記コードを追加。
L206あたり。

$id = $_SESSION[$this->key][$i][‘id’][0];
$point = SC_Utils_Ex::sfPrePoint($price, $point_rate, POINT_RULE, $id);
$total+= ($point * $quantity);
}
$objQuery = new SC_Query();
$objCustomer = new SC_Customer();
//customer_idを検証
$customer_id = $objCustomer->getValue(“customer_id”);
$order_count = $objQuery->count(“dtb_order”, “customer_id= ? and del_flg = 0”, array($customer_id));
if ($order_count == 0) {
$total = $total*FIRST_POINT;
}
return $total;
}

// カートへの商品追加

その2)管理画面のパラメータ設定にポイント倍率設定用の項目を増やす。

DBの、mtb_constantsを開いて、カラムを1行追加。

id FIRST_POINT
name 1
rank 523※一番最後に追加
remarks 初回購入ポイント倍率

nameの値が倍率になる。デフォルトは”1″(倍)。

倍率を変更するときは、管理画面のパラメータ設定で値を変えればOK。

その他の注意点としては、キャンセルがあったときなどにポイントの手動付け替えなど、色々懸念することが出てきてしまうので、

  • ポイント付与のタイミングを発送済みか支払い確認済みなどのステータスになったとき、などに変更しておいたほうがいい
  • 注文のキャンセルがあったときは、自動でポイントが付け替えられるほうがいい

こういうことも一緒にカスタマイズしておいたほうがいい。この辺は、次のバージョンあたりで解消されそうな気もするけども。

WORDPRESSへフォームをつけた。そして携帯対応にした。

WORDPRESSには、色んなプラグインがある。

その中に、お問い合わせフォームを簡単に作ろう♪というプラグインがあるのであるが、

この2つで迷い、悩みぬいた挙句(というか、やりたいことを実現するために朝方までソースをいじいじテストした挙句)今回は、contact form 7を利用することにした。

というのも、問題は、KTAI STYLEとの相性というか、、、携帯での文字化け?

フォームのメール入力欄に携帯電話のメールアドレスを使用すると、送られてくる内容確認メールが文字化けするのだ。色んなハックを調べてやってみたんだけど、PCサイトでは、文字化けなく携帯にメールが送られるようになったものの、どうしても、KTAI STYLEの携帯サイトからは、文字化けが直らない・・・

エンコードの問題があるので対応を迫られるのはしょうがない;
とはいえ、これはキビシイ。

cformでは、全体の文字化けは、回避できたけど、formの値の部分のみ文字化けする。(後ちょっとな気がするんだけど;)

てことで、なんとかうまくいったcontact form 7のハック。

wp-contact-form-7.phpのL991あたり。function validateにktai style用のコードを追加。

function validate($contact_form) {
$fes = $this->form_elements($contact_form[‘form’], false);
$valid = true;
$reason = array();

foreach ($fes as $fe) {
$type = $fe[‘type’];
$name = $fe[‘name’];
$values = $fe[‘values’];
$raw_values = $fe[‘raw_values’];

// Ktai ONLY
if (preg_match(‘/^(?:text|textarea)[*]?$/’, $type) && function_exists(‘is_ktai’) && is_ktai())
$_POST[$name] = mb_convert_encoding($_POST[$name], get_bloginfo(‘charset’) ,”SJIS”);

// Before validation corrections
if (preg_match(‘/^(?:text|email|captchar|textarea)[*]?$/’, $type))
$_POST[$name] = (string) $_POST[$name];

よし!

これで、簡単にフォームが追加できる!試しに、確認メールをお問い合わせユーザーに返信する設定で、メアドをdocomoにしてみたけど、OKだった。

は~。理屈は分かってんだけど、情報少ないし、大変だった。

参考サイト:http://d.hatena.ne.jp/v-m-s_memo/20081101/1225548282

この中で、ktai styleの作者のゆりこさんのコメントがあって、

「で、修正コードですが、SJIS 決め打ちはいろいろ問題が出そうです。現在は SJIS ないし SJIS-win しかないですが、将来的には is_ktai() が true でも UTF-8 になる可能性があるため、global $Ktai_Style; してから、$Ktai_Style->get(‘charset’) した値を使ってください。これならば、互換性が保てます。」

ということなので、

// Ktai ONLY
global $Ktai_Style;
$ktai_char = $Ktai_Style->get(‘charset’);
if (preg_match(‘/^(?:text|textarea)[*]?$/’, $type) && function_exists(‘is_ktai’) && is_ktai())
$_POST[$name] = mb_convert_encoding($_POST[$name], get_bloginfo(‘charset’) ,$ktai_char);

とかしたら、いいってことなのかな???

また、明日にでもテストしてみよう。。。 →これで、いけましたね。

追記:(09/08/17)

contact form 7のバージョンが新しくなったので、こちらに記載していたコードとコードの位置がどちらも変更になってしまった。(ketai styleもバージョンアップされている)

いい感じになったけど、ハックには不都合;

てことで、検索していたら、こちらで、モジュールを公開されているのを発見!
http://www.icoro.com/200908093906.html

WORDPRESSで登録メール等が届かない・・・対応

WORDPRESSでは、新しいユーザーが登録された場合やお問い合わせフォームプラグインなどの設置で、自動的にメールが届く仕組みがある。

・・・はずなのだが、このメールが一向に届かない。

原因は、inetd。

およそのサーバにですね、inetd(※inetd は、FTP、POP3、telnet といったインターネットサービスが使うポート番号を(指定されて)監視する。監視対象のポートにTCPパケットあるいはUDPパケットが届くと、inetd は対応するサーバプログラムを起動し、コネクションを制御させる。by wikipedia)というのが、走っているわけなんですが、このinetdが、メール送信の時に、from情報もしているようで、WORDPRESSのデフォルトのまま設定ではこの監視に引っかかってしまうので、メールを受け取れない。

どういうことかというと。

WORDPRESSは、通知メールの送信に、wordpress@あなたのサイト名のアドレスでメールを送信します。このメールアドレスが、サーバ内に実在していれば、問題がないのだが、実在していないメールアドレスからの送信は、inetdの監視に引っかかってしまう。

て、おいおい。。。

最初からwordpress@domainなんてメアド誰がつくっとるねん;
とかツッコんでしまう。

よって、主な対応方法は、2つかと。。。

  1. 上記、wordpress@domainというメアドを実際に作ってWPの管理アドレスに設定する。
  2. または、このメアドをサーバに実在している実際の運用アドレスに変更する。

ま、たいてい、2ですな。

やり方。

/wp-includes/pluggable.php を開いて、L354あたりの、

$from_email = ‘wordpress@’ . $sitename;

を、(1)

$from_email = ‘あなたのめあど@domain‘;

か(2)

$from_email = ‘あなたのめあど@‘. $sitename;

に変更。

ただし、(2)の方法で変更する場合、wordpressで送信されるメールアドレスは、wwwのサブドメインは削除されることに留意すること。(→つまり、ドメインが、www.domain.comでも@から後ろは、domain.comにしかなりませんよ、でも、sub.domain.comだったら、そのままですよ、ということです。まあ、これは普通メアド作るときにも同じようなルールになるので、問題ないかと思うのですが・・・)

こういうところって結構悩みますね。

ちなみに、メアドチェックは、サーバー内で掛かりますよ。他のサービスで持ってるメアドで運用しようとしている場合は、要注意です。