Menu
▾
▴
#239 Fatal error when ja_utf8 enabled without mbstring support
Fatal error: Call to undefined function mb_language() in html/modules/legacy/language/ja_utf8/global.php on line 186
The line calling the mb_language() function should be removed as in the EUC version of the japanese language file.
XCL 2.1.8b
The ja_utf8 language sends mail with using JIS. So it needs mbstring lib. To remove dependency on mbstrings, we have to modify more lines. Even if mb_language() is removed, your XCL causes Fatal Error when you send a mail.
When we prepared ja_utf8, all mail clients didn't have UTF-8 feature. So site owners needed to send JIS mail. But, now, all mail clients (including mobile phone) may have UTF-8 feature. We can change it. But, we have existing users and consider. Do they agree this change at minor upgrade?
[ja]現在の ja_utf8 はメールは UTF8 以外で送っています。これは当時、メールクライアント側（ソフトとか携帯電話とか）が UTF-8 に必ずしも対応しているわけではなかったため、 UTF-8 でメールを送っても、受信者がメールが読めないことがあったためです。そのためメールの送信には mb_string のサポートが必要で、たとえ指摘の行を削除しても、メール送信時に mb_string の関数にアクセスして Fatal Error を起こしてしまうのが、現状の実装です。
当時と違って、今は UTF-8 のメールクライアントは行き渡っていると思うので、このメール送信時に mb_string のサポートを使って JIS に変換するプロセス自体を削っても大丈夫だろうと思われます。ただ、既存のユーザーがおりますので、マイナーバージョンアップでメール送信の文字コードを変えてもいいのかどうかが判断のポイントだと思います。バージョンアップを適用したら、notifyメールが携帯電話で読めなくなったという人はゼロではないので、そういう人たちを無視するかどうかです。
僕はちょっと腰が引けてます。^^ どう思われますか？[/ja]
We can add function_exists(). If mb_strings is not supported, XCL UTF-8 can not run perfectly. But we may be able to prevent FatalError.
Since all other parts in XCL (including X2) always check the availability of mbstring functions before actually calling them,
I don't really know why we can't do so as well here. As far as I can see, there shouldn't be any fatal errors related to
mbstring in other parts of XCL.
Also the mb_language() function gets called (if it exists) in Legacy_LanguageManager::_setupMbstring() upon startup,
so we could probably just remove the line from the language file without any side effects.
hmm.. after further looking at the code, it seems like that the langauge files of the installer (both ja_utf8 and japanese version)
don't even check whether mbstring functions exist or not and call them directly. I think we should add function_exists() calls
to these files as well.
[ja]XCL（X2含む）の他の部分ではmbstirng関数が利用可能かどうかをその使用前に必ずチェックしている模様なので、
Fatal Errorが起きることはないと思います。
また、mb_language()は初期化ステージでLegacy_LanguageManager::_setupMbstring()内でも呼んでいるので
言語ファイルからは削除してしまっても問題ないのではないでしょうか。
それでもう少し調べてみましたが、実はインストーラの言語ファイル（japanese/ja_utf8いずれも）では
mbstring関数が使用可能かどうかチェックせずにこれらの関数を使用してますね。ということはXCLは
mbstring関数がないとインストールできない。。ただ、インストーラ以外の部分ではそのチェックを
行っている（ja_utf8言語ファイルの問題の行以外）ので、できればインストーラの方もチェックするように
した方が良いのかなと思います。
#こちらの環境でインストールできたのは、インストール時にはmbstringが有効なPHPバージョンを
使用していたからでした。[/ja]
Thank you for your code review. I feel the same way. I sealed mbstring function calls with function_exsists().
As you said, Legacy_LanguageManager calls mb_language() after reading global.php. In addition, mb_language() in global.php and _MBSTRING_LANGUAGE are different. Why?
I removed mb_language call from global.php of ja_utf8.
[ja]
ありがとうございます。インストーラのほうにも封をしました。あと、mb_language()は確かに多重コールになってますね。しかも、 _MBSTRING_LANGUAGE と値が違うし...
mb_internal_encode() や mb_http_output() の呼び出しが今も使われているのであれば、まとめて書いておいてもいいかもしれませんが、今やこれらも呼び出されてませんし、ご指摘の通り削ることにしました。
[/ja]