MySQL 4.0.x + WordPress 2.6.x におけるサイト内検索機能の不具合を修正する

ざっとソースを見てみて気になったところを提示してみますので、修正されるときに取り込んでもらえれば幸いです。

●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 バージョンもチェックした方がよさそうです。