初めまして。
さくらインターネットのレンタルサーバを使用しているため、
MySQL 4.0.xでの内部文字コード設定に起因する検索不具合の
解決方法を血眼になって探しておりましたので、
早速、プラグインを使わせていただきました。
coreserver上のテストブログ(MySQL5[文字コードはutf8]+PHP5)
との比較もしてみましたので結果をご報告します。
・さくら版に貴殿のpluginを導入したら、
それまで不具合を起こしていた特定の検索ワードでの検索結果が正常になりました。
・さくら版とcoreserver版で検索結果に差は見当たりませんでした。
・plugin”SearchEverything”がONでも特に変化(異常)はありませんでした。。
・ウィジェットの”最近の投稿”を使うと、
検索結果画面において、”最近の投稿”でHTMLの出力が止まります。
（テーマは、デフォルト、クラシック、K2と変えてみたが、全てにこの現象が発生）
また、何か発見しましたらご報告させていただきます。
すみません。重要な事を書き忘れていました。
Wordpressのバージョンですが、
さくら版は2.5.1、coreserver版は2.6です。
書き損じ、大変、失礼いたしました。
ありがとうございます。
これでMySQL4.0系で運用しているサイトで検索が可能になると思います。
ただ、当方では
Fatal error: Cannot redeclareがline.19で発生します。
PHP5.2.6
MySQL4.0.27
Wordpress2.6
関数内関数を２回以上実行するさいに発生する再定義エラーのようです。
convert_like_to_strposをconvert_like_to_strpos_25へ替えsearch_with_old_mysql_25関数内から出しpreg_replace_callbackの第二引数を”convert_like_to_strpos_25″とすることで動作しています。
ご報告まで。
みなさま、ありがとうございます。
総じてまだまだ品質に問題があるということがわかりました。
取り急ぎ、関数の二重定義に対応いたしました。
ウィジェットの件はこれから対応したいと思います。
それでは、よろしくお願いします。
ざっとソースを見てみて気になったところを提示してみますので、修正されるときに取り込んでもらえれば幸いです。
●16, 46行目
$q = $wp_query->fill_query_vars($q);
は必要性がよく分かりません ($wp_query を汚染してしまう気が……)。18行目および48行目を単に
if (isset($wp_query->query_vars['s']) && $wp_query->query_vars['s']) {
じゃだめなんでしょうか。
●19, 49行目
$regex をうまく書けば function convert_like_to_strpos() は同じ内容にできると思いますので、外に出してしまって共通にできます (結果として二重定義も回避)。
●24, 52 行目
$search = bin2hex(stripslashes(strtoupper($matches[2])));
stripslases() と strtoupper() は逆の方がいい気がします。現状でもたぶん問題はないはずですが。
●31, 59行目
$regex = '/\('. $wpdb->posts. '\.post_(title|content) LIKE[^\x5c]\'(.+?[^\x5c])\'\)/s';
検索文字列が1バイトまたは、最後の文字がバックスラッシュ (0x5c) の場合、正規表現にマッチしません。バックスラッシュでクォート文字がエスケープされる可能性があるときのクォート区間をマッチさせるのは結構難しいのですが、
'([^\'\\\\]*?(\\\\.[^\'\\\\]*)*)'
という正規表現が正解です。
'((\\\\.|[^\'\\\\])*)'
でもよいのですが、上記の方が選択がない分高速に動作します。
●70〜73行目
if (strpos($GLOBALS["wp_version"], "2.6") !== false ||
strpos($GLOBALS["wp_version"], "2.5") !== false) {
add_filter("posts_where", "search_with_old_mysql_25");
} else if (strpos($GLOBALS["wp_version"], "2.3") !== false) {
ここは version_compare() 関数を使ってみてください。少なくとも、WordPress 2.2.3 では問題が生じる可能性があります。
あと、WordPress バージョンを確認する前に MySQL バージョンもチェックした方がよさそうです。
Byerkut様、
取り急ぎ、関数の二重定義に対応いたしました。
いえ、これでは対応できていません。
convert_like_to_strpos_25
convert_like_to_strpos_23
をそれぞれ
search_with_old_mysql_25
search_with_old_mysql_23
の外へ出す必要があります。
早速の対応は感謝しています。
が、バージョンを上げていただかないと同じバージョンで違うコードが出回ることになり混乱が生じる恐れがあります。
またBag Fix Reportを出していただくと変更点が確認でき使用する側としては助かります。
大変なご尽力に水をさすつもりはありません。
このような機能のプラグインを待ち望んでいた一人として、またこのプラグインの更なる充実のためにお願いいたします。
Search with old MySQL のバージョン 1.1 を公開いたしました。
http://www.blueocean.bz/pub/search-with-old-mysql.1.1.lzh
変更点は以下になります。
lilyfan 様
申し訳ないです、投稿いただいたのに見落としておりました。
これから葬儀のため、帰り次第対処させていただきます。
taikiken 様
至らぬ点をご指摘いただき、ありがとうございます。
今回の対応でエラーは回避できますでしょうか。
Byerkut 様
今回の対応でエラーは回避できますでしょうか。
早速の対応ありがとうございます。
失礼な言い方になっていないかと、心配しています。
MySQL4.0系で運用を余儀なくされているものにとっての大きな助けになります。今後の開発・改良にも期待しています。
早々のバージョンアップのご対応をどうもありがとうございました。
ご報告が遅れましたが、Ver 1.1では、前の書き込みでご報告いたしました、
「検索結果画面において、”最近の投稿”ウィジェット部分でHTMLの出力が止まる」
という現象は起きなくなりました。
※ちなみに、ver1.0使用時、別のテーマでは、”Loop”に入るところでHTML出力が止まってしまっていましたが、ver 1.1にすることで解決した事も付け加えておきます。
引き続き、今後のバージョンアップを期待しております。
どうぞ宜しく御願いいたします。
プラグイン利用させていただきました。
これまでは本文・抜粋の検索ができませんでしたが、有効になりました。
5.0への引越しはちょっと不安だったので、大変助かりました。
【動作環境】
WordPress2.6.3
※searchEverything4.7.8利用
使用サーバ：チカッパ！
DB:MySQL4.0
DBエンコード：ujis
これでPHP5になってくれたら、チカッパのままやっていけそうです！ あとはcronサポート（ちょっと脱線しました）。
今後のバージョンアップも期待しています。
