Since Drupal made it mandatory to disable mbstring.http_input and its 'relatives', a lot complaints regarding Drupal installation was raised everywhere in cyberspace. It's not a problem if you own your own server, and there's a lot of workaround. However, If it so happened that your host [is a free web host and] is too protective [or simply a lover of deprivation] that they wont allow you to use htaccess files, Drupal's requirement of restricting mbstring and relatives is cruelty.
The safest workaround is to upload the appropriate .htaccess file. [There's a patch to settings.php but its not effective everywhere, I tried it in Freehostia with a Drupal 5.1 and yeah, I successfully installed Drupal but it keeps the site hanging whenever I use php submit command within the installation, haha.] Well we [hopefully all] understand as end-users that there's a reason why, whatever it is, and that the developer's are working on it. This post is just to remind us guys that since I read somewhere that the 6.x development team is working on a language subsystem blah blah, then please don't forget to legally support mbstring and relatives.
Or if ever it's nearly impossible as of now, please patch the next Drupal release with a built-in anti-mbstring codebase [since I guess putting ini_set('mbstring.http_input', 'pass'); ini_set('mbstring.http_output', 'pass');]. in settings.php will never be a remedy], please. [Freehostia is a great free host while Drupal is the best CMS. I want them to work together flawlessly. Sorry for the advertisement].
Comments
Comment #1
chx commentedRelevant issue: http://drupal.org/node/87138 I will ask the i18n guys to reflect but I smell a huge won't fix here.
Comment #2
gábor hojtsySubscribing :) (Need to go to eat something and then a DrupalCon session) Will reply as soon as I can.
Comment #3
gábor hojtsyThe .htaccess issue you linked to is fixed, both in Drupal 5 and Drupal 6. That solves the issue for those using .htaccess. Putting the same settings into settings.php does not work, because by the time PHP processes those settings, the mbstring encoding conversion is already done. For those, whom found the settings.php patch working, the mbstring setup was probably made that utf8 comes out.
Task 1: Our mbstring checker might be made a bit smarter about all the possible mbstring setups which Drupal works with, not only checking for the suggested one.
If the php.ini (or apache vhost) setup is not proper for Drupal and you have no .htaccess possibility, then all we can help you is to document what to tell to your hosting provider.
Task 2: See whether we can document what to do when this error is shown. (Eg. include a proper php.ini excerpt in the error massage to copy-paste).
I think these are the two possible ways to go from here.
Comment #4
gábor hojtsyComment #5
gábor hojtsyI don't think this is critical, as it affects seemingly a small number of hosts (otherwise there would be huge flames already here).
Another possibility is to fall back on the built-in single byte encoding support, if multibyte support is available but not properly configured. That would probably be a safe way even for people who can change their configs, as the site would work mostly normally until they fix their configuration. But then the error message should include information about the found but unusable multibyte setup.
Comment #6
dpearcefl commentedIs this still an active issue in D6?