日本語のロール名・ロールの説明が消える 【解決済み】

[kazuike]

-----
ご利用のサーバ：KDDI ホスティングサービス S20
http://www.kddi.com/pub/hosting/service ... index.html
MODXのバージョン：1.0.6J-r8
PHPのバージョン：5.2.8
MySQLのバージョン：5.0.45
ブラウザ：IE9、Firefox16.0.2
-----

ロールの作成/編集画面で「更新」すると、日本語のロール名とロールの説明が消えます。
何も変えず「更新」を押すだけでも消えます。（投稿担当者、ウェブマスターともに消えました）
英字は問題ありません。
英字と日本語を混ぜると、最初に出現する日本語以降がすべて消えます。

ちなみに、
リソースの作成/編集やグループ管理では、日本語名でも問題ありません。

[yama]

manager/processors/save_role.processor.php内の処理ですね。調べてみます。

コード: 全て選択

if (!isset($name) || empty($name)) {
    echo 'Please enter a name for this role!';
    exit;
}

この判定をすり抜けているのが気になります。

[kazuike]

manager/processors/save_role.processor.php内の処理ですね。調べてみます。

コード: 全て選択

if (!isset($name) || empty($name)) {
    echo 'Please enter a name for this role!';
    exit;
}

この判定をすり抜けているのが気になります。

当然ながら、ロール名が空欄の状態で「更新」すれば、このエラーメッセージが表示されます。
（余談ですが、このエラーが出ると入力に戻れず最初からやり直しになります）

入力欄にはちゃんと日本語が入っているので、
この空欄判定の後で、日本語がばっさりカットされてるのでしょうね。

[kazuike]

デフォルトのphp.iniでは、
mbstring.internal_encoding = EUC-JP
になっていたので、
試しに、
mbstring.internal_encoding = UTF-8
に変えてみたところ、日本語でも更新できるようになりました。

リソースの作成/編集等との違いは何でしょう？

このホスティングサービス、
.htaccessでphp_valueやphp_flagが設定できないので、
ＰＨＰを使うディレクトリ毎にphp.iniを置く必要があり、
MODXでは、managerとドキュメントルートには必要ですね。
（インストール時は、installにも）

[yama]

manager/processors/save_role.processor.phpの先頭のほうで
mb_internal_encoding($modx->config['modx_charset']);
または
mb_internal_encoding('utf-8');
とするとどうなるでしょうか？

リソースの作成・編集で化けないとすると、mbstring.detect_orderの設定でたまたま正しくUTF-8と判定されているのかも？だとしたら、内容によってはリソースでも化けそうです。

[kazuike]

manager/processors/save_role.processor.phpの先頭のほうで
mb_internal_encoding($modx->config['modx_charset']);
または
mb_internal_encoding('utf-8');
とするとどうなるでしょうか？

manager/processors/save_role.processor.php
の先頭に入れてみましたが、どちらもダメでした。

試しに、
$modx->db->insert
や
$modx->db->update
の直前に入れても同じでした。

[yama]

mb_detect_order($modx->config['modx_charset']);
utf-8一択というのもアレですが、これならどうでしょう？

[kazuike]

mb_detect_order('UTF-8');
でもダメでした。

[kazuike]

試しに、
manager/index.php
の先頭に
mb_internal_encoding('UTF-8');
mb_detect_order('UTF-8');
を入れてみましたが、これもダメでした。

[yama]

できればスクリプト側で解決したいですが、とりあえずサーバ設定に頼るしかなさそうですね。
$modx->db->escape()を通した時点では値が保持されているみたいなので、DBにストアする時点で値が消滅しているみたいですね。
以前のバージョンでは大丈夫だったでしょうか？今回のバージョンではDBAPIで特定環境に対してset namesを実行していますが、もしDBがujisならset names ujisとする必要があるかもしれません。

[kazuike]

ini_set('mbstring.internal_encoding','UTF-8');
も
manager/processors/save_role.processor.php
manager/index.php
で試してみましたが、効かないです。

[kazuike]

できればスクリプト側で解決したいですが、とりあえずサーバ設定に頼るしかなさそうですね。
$modx->db->escape()を通した時点では値が保持されているみたいなので、DBにストアする時点で値が消滅しているみたいですね。
以前のバージョンでは大丈夫だったでしょうか？今回のバージョンではDBAPIで特定環境に対してset namesを実行していますが、もしDBがujisならset names ujisとする必要があるかもしれません。

試しに、
manager/includes/extenders/dbapi.mysql.class.inc.php
の
mysql_set_charset($this->config['charset']);
の直前に
@mysql_query("SET NAMES UTF-8", $this->conn);
や
@mysql_query("SET NAMES ujis", $this->conn);
を入れてみたところ、うまくいきました。
（どちらを入れても同じようです）

なお、
このホスティングサービスを使うのは初めてなので、
以前のバージョンについてはわかりません。

[yama]

コード: 全て選択

@mysql_query("{$this->config['connection_method']} {$this->config['charset']}", $this->conn);
$tend = $modx->getMicroTime();
$totaltime = $tend - $tstart;
if ($modx->dumpSQL)
{
	$msg = sprintf("Database connection was created in %2.4f s", $totaltime);
	$modx->queryCode .= '<fieldset style="text-align:left;"><legend>Database connection</legend>' . "{$msg}</fieldset>";
}
if (function_exists('mysql_set_charset'))
{
	mysql_set_charset($this->config['charset']);
}
else
{
	@mysql_query("SET NAMES {$this->config['charset']}", $this->conn);
}

1. mysql_query(SET CHARACTER SET) (上記の１行目)
2. mysql_set_charsetまたはSET NAMESの必ずどちらか

該当部分の処理順番は上記のようになっているので、（その環境では実行されなさそうな）mysql_set_charsetが関係してる気がします。普通は問題が起きないはずなんですが、気になる部分ですね。また調べてみます。
（もしかするとmysql_set_charsetを最初に実行する必要があるのかも？）

[kazuike]

試しに、
manager/includes/extenders/dbapi.mysql.class.inc.php
の
mysql_set_charset($this->config['charset']);
の直前に
@mysql_query("SET NAMES UTF-8", $this->conn);
や
@mysql_query("SET NAMES ujis", $this->conn);
を入れてみたところ、うまくいきました。
（どちらを入れても同じようです）

なお、
このホスティングサービスを使うのは初めてなので、
以前のバージョンについてはわかりません。

すみません。
テストの仕方が間違っていました。
上記の方法では、日本語の処理はできませんでした。

[yama]

save_role.processor.php冒頭で、$modx->db->escape()を通す前の$_POST['name']と、エスケープを行なってextractした$nameのそれぞれで値が正しく保持されているかどうか、気になります。save_role.processor.php冒頭のちょっとした処理に問題があるのか、DBAPI側か、どっちかという感じですね。
echo $_POST['name'];exit; みたいなコードを混ぜて目視で確認してみることは可能でしょうか？そろそろやりとりが長引いてますので、気が向けばでよろしくお願いします。
シンプルに書き直したコードをいちおう添付しておきます。

[kazuike]

$_POST['name']
にはEUCで文字が入っていました。

ということは、
リソース作成/編集との違いは、入力フォーム側にあるのかな？

[yama]

そのようですね。フォームの側ではutf-8で固めてあるので、POSTの入出力プロセス上で変換されてる感じがします。(http_outputとかencoding_translation)
リソース編集画面とも基本的な違いはないはずなので、自動変換がきいてるように思います。フォーム内の文字数が多いリソース編集画面では誤判定をしにくいのでは？と。
mbstringの下記の設定は分かりますでしょうか？phpinfoで見ていただいてもいいですが、管理画面右上のヘルプ→supportのタブでも確認できます。

mbstring.detect_order
mbstring.encoding_translation
mbstring.func_overload
mbstring.http_input
mbstring.http_output
mbstring.internal_encoding
mbstring.language
mbstring.strict_detection
mbstring.substitute_character

[kazuike]

Supportで関連しそうな情報は以下です。

mbstring
mbstring.detect_order auto
mbstring.encoding_translation 1
mbstring.func_overload 0
mbstring.http_input auto
mbstring.http_output pass
mbstring.internal_encoding EUC-JP
mbstring.language Japanese
mbstring.strict_detection 0
mbstring.substitute_character

MySQLの文字コード情報
接続メソッド SET CHARACTER SET
文字セット照合順序 ujis_japanese_ci
character_set_client utf8
character_set_connection utf8
character_set_database ujis
character_set_filesystem binary
character_set_results utf8
character_set_server ujis
character_set_system utf8
character_sets_dir /usr/local/mysql5/share/mysql/charsets/

[yama]

ありがとうございます。mbstring.encoding_translationが1になってますね。あえてこのまま検証してみたいと思います。
添付のファイルをmanager/actions/ディレクトリに上書きしてみていただけますでしょうか。

[kazuike]

以下のエラーになりました。

Fatal error: Call to undefined method ManagerAPI::makeToken() in /usr/home/****/virtual/test/manager/actions/mutate_role.dynamic.php on line 3