まず、前回いじった wp-includes/wp-db.php は元のソースに戻します。
そのまま残しておくとバグの元となるので。

次にすべてのページで使われるファイルをターゲットにします。
それは「wp-config.php」です。

前回も wp-config.php をなおしたのですが、もう一度 見直します。
前回なおしたのは

【オリジナル】
mb_language("Japanese");
mb_internal_encoding("UTF-8");>

【編集後】
ini_set("output_buffering","on");   //2006.12.09 add
ini_set("mbstring.encoding_translation","off");  //2006.12.09 add
ini_set("output_handler","mb_output_handler");  //2006.12.09 add
ini_set("default_charset","UTF-8");   //2006.12.09 add
mb_language("Japanese");
mb_internal_encoding("EUC-JP");
ini_set("mbstring.http_output","UTF-8");  //2006.12.09 add
ini_set("mbstring.http_input","auto");  //2006.12.09 add
ini_set("mbstring.substitute_character","none"); //2006.12.09 add

このあとに核心部分を追加します。

// If the output-encoding is different than the internal-encoding,
// It converts the character-code of POST value into output-encoding.
// 2006.12.12 add
if (
     function_exists("mb_http_output")
  && function_exists("mb_internal_encoding")
  && function_exists("mb_convert_variables")
   ) {
 mb_convert_variables (
  ((mb_http_output() != 'pass') ? mb_http_output() : mb_internal_encoding()),
  "ASCII,JIS,EUC-JP,eucJP-win,UTF-8,SJIS,SJIS-win",
  $_POST
 );
}

まぁ、関数の有無のチェックはこれ以前にすべきでしょうが...
mb_convert_variablesを使い、$_POSTグローバル変数を置換してしまいます。
これでOK。

問題となるファイルの編集も、seo-title-tagプラグインにも対応することができました。
たぶん、完璧です。

これなら、もしmbstring.http_outputをEUC-JPに戻したとしても、対応できると思います。(と、本人は思っている)

それと、テーマ「Blix」を参考にしたテーマ「BeLive」ですが、問題があったようで「WP-SimpleGMaps」プラグインをそのまま使うと、サイトへの接続が切れてページを表示できませんでした。
理由が footer.php 内の do_action('wp_footer') の位置に問題があったようです。
これも直したら解決です。