Disable mbstring in .htaccess

These values must be set before PHP is started... we could htaccess to set them. But that would only help people with htaccess ability. Feel free to make a patch. We also need to disable function overloading.

Ok, the htaccess patch would be much better. Just add the following lines to the root htaccess of Drupal for each PHP related "IfModule" block:

The following lines could also be added to the settings.php for those without htaccess:

But Steven said "These values must be set before PHP is started"... so, these changes settings.php will not be areal fix, right? Is there any explanation?

Well... I can't provide a patch for it, but the above lines will make it easy to implement it.

Thanks again.

As this problem showed its face in 4.7.3, I was helped by these lines in settings.php on my 3 drupal sites:

ini_set('mbstring.http_input','pass');
ini_set('mbstring.http_output','pass');

Now, that I'm testing the CVS version of Drupal 5.0, I am presented with the error:

Multibyte string input conversion in PHP is active and must be disabled. Check the php.ini mbstring.http_input setting. Please refer to the PHP mbstring documentation for more information. (Currently using Unicode library Error)

Again the two lines mentioned, put into settings.php, saved my day.

If this is the most correct sollution, I suggest its implemented in the shipping settings.php. If its NOT the correct sollution, I would also like to now, especially why it isn't, why I shouldn't use it, and what I should to insted. I don't think most users have access to the php.ini file on their host, so I expect this issue to affect quite some people if being ignored.

Best regards
Bjarne

http_input affects how data such as GET and POST is processed. By the time PHP starts executing, $_GET and $_POST have already been created, and will not magically change just by calling ini_set(). All you do is trick Drupal into believing the problem is not there.e

I agree with Steven's comment... this is why I believe the htaccess patch would be nice. In this way those with htaccess support will be ok with it right out of the box... for the others, the php.ini advice is ok.

Well, I have access to the .htaccess file in the root directory of the Drupal installation but the fix as described by FredCK - adding the suggested lines for each PHP related "IfModule" block - did not work for me. I added the suggested lines to settings.php which at least removed the error message if not fixed the problem.

Moving out of the "x.y.z" queue to a real queue.

None of these worked for me as there is one more setting mbstring.encoding_translation that needs to be overridden to continue with Drupal 5.0 installation. Place these three lines in a new .htaccess file in the root to get around this problem at install:

php_value mbstring.http_input pass
php_value mbstring.http_output pass
php_value mbstring.encoding_translation 0

This didn't work for me. I'm running Drupal 5 on FC5 (ppc), PHP 5.1.6, apache 2.2.3.

Changing title to match the issue.

To those testing the values: make sure AllowOverride is set in your Apache configuration. If you can turn on Clean URLs, you can be sure it works.

Confirming that on my setup, AllowOverride is set to All (I can't test clean URLs because I can't install Drupal. The following error occurs when I hit install.php :

Incompatible environment
The following error must be resolved before you can continue the installation process:
Multibyte string input conversion in PHP is active and must be disabled. Check the php.ini mbstring.encoding_translation setting. Please refer to the PHP mbstring documentation for more information. (Currently using Unicode library Error)

those 3 settings resolved my client's problem too. here is a patch. since it has worked for several people already, i set to RTBC.

i think this should be backported after commit to HEAD.

now, with a patch

Forgive me if this question seems stupid. This is the first time that I am attempting to install Drupal, and I got this error. I see that Moshe has posted a patch, but, frankly, I have no idea what to do with it. Is there a tutorial where I can find more information on this subject, or can someone describe exactly what to do with this patch. I attempted to create an .htaccess file at the root of my site with the contents of the patch file, but I get a server error when I attempt to visit my site. Removing the .htaccess file gets rid of the server error.

Any help that can be provided would be very greatly appreciated.

Thanks!

Nevermind...
I added this to .htaccess and got it working.

php_value magic_quotes_gpc 0
php_value register_globals 0
php_value session.auto_start 0
php_value mbstring.http_input pass
php_value mbstring.http_output pass
php_value mbstring.encoding_translation 0

I was also able to get Drupal to install by changing my .htaccess file with the info listed in comment #15. However, I am concerned about what sorts of problems will crop up in the future with this sort of solution. Can anyone tell me what else I need to do, or what other problems I might encounter by doing this?

This installation of Drupal is for a client on their shared hosting site, so I doubt I will get any access to php.ini file

none of the methods listed worked for me all I get is an error that say "zero file size"

my host said try a custom php.ini file but I have no idea whaty to place in the file.

no sense in holding this back. there are no drawbacks that i know of for the .htaccess solution. doing this in settings.php can be a bad idea, as mentioned earlier.

Ok, I haven't tried the settings.php solution because of the mentioned problems. But the other solution (none of them) have worked for me. Can someone give a detailed explanation or show a copy of their .htaccess

This drove me crazy, so for those out there that couldn't get the above to work in 5.1, placing the following AT THE TOP of your appropriate .htaccess section seems to work:

editing the .htaccess files did not solve my problem. continued to give me the problem till i created a php.ini file... Question is do I need to put this in every directory or just the root directory? my php.ini file only works in the folder it's located in.

This is a good safeguard and should have no side-effects elsewhere. Tested locally, and seems to work fine.

Committed to HEAD. Should probably be backported too.

Committed to 5.

Warning

Here's the drawback from not paying attention to the following warning:

Operations on Unicode strings are emulated on a best-effort basis. Install the PHP mbstring extension for improved Unicode support.

Quoted from this comment in "Unicode library" in Status report?:

VeryMisunderstood

the mbstring extension has to do with multibyte characters in internationalization of Drupal. In other words languages. What will using it give you ? The ability to internationalize your site.

WHat risk do you run if you don't install it ? you site wont work with internationalization. In other words as the internet moves forward with multi language sites to reach a larger target audience, you will be left behind as your site will only work 100% properly in English.

Not so good workaround

Here's the drawback from using the settings.ini ini_set('mbstring.http_input','pass');ini_set('mbstring.http_output','pass'); workaround from the first two comments from Drupal 5.X Installation problems 'mbstring' error:

VeryMisunderstood

yes you can live without clean urls, however, you may find other serious limitations on a "free" host. They are typically more restricting then a shred host.

rosgar

If you're using imagecache module.

'Imagecache will not operate properly if Clean URLs is not enabled on your site.'

Solution

Do as the warning stated and demand your host to install the library. Some hosts might feel entitled to their conservative ways but there's some that will be happy to accommodate you and you can use this for leverage if the demand is not met.

I also documented this on my website: http://www.williamcarrier.com/

My techark host tech pointed me here and I'm assuming techark hosting will have this installed. This setting should set register_globals off for techark - I'll try this solution and after this one http://drupal.org/node/280724#comment-1048260

Actually, I'm not sure what part of this topic applies to turning off register_globals, techark is being quite vague in their support answers.