New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Server locale warning #184

Closed
jacmaes opened this Issue Feb 10, 2017 · 27 comments

Comments

Projects
None yet
5 participants
@jacmaes

jacmaes commented Feb 10, 2017

Short description of the issue

I've added the recommended "setlocale(LC_ALL,'en_US.UTF-8');" to my config.php file. Even after clearing the cache and refreshing modules, the warning that it's not properly set keeps coming back whenever I log in.

Expected behavior

It should recognize that I properly set the locale in my config.php

Actual behavior

The following warning keeps coming back:

Warning: your server locale is undefined and may cause issues. Please add this to /site/config.php file (adjust “en_US.UTF-8” as needed): setlocale(LC_ALL,'en_US.UTF-8');

Since I'm in Spain and using Spanish, here are the two relevant lines:

$config->timezone = 'Europe/Madrid';
setlocale(LC_ALL,'es_ES.UTF-8');

Setup/Environment

  • ProcessWire version: 3.052 dev
  • PHP version: 7.015
  • Any 3rd party modules that are installed and could be related to the issue: Fresh install
@matjazpotocnik

This comment has been minimized.

matjazpotocnik commented Feb 10, 2017

@jacmaes That warning is introduced in the latest commit. Please check that /wire/modules/Process/ProcessLogin/ProcessLogin.php is UTF-8 encoded. If it is, then please remove setlocale form /site/config.php and provide the results of this lines:

var_dump(setlocale(LC_ALL, "0"));
var_dump(basename("§"));

setlocale(LC_ALL, "es_ES.UTF-8");
var_dump(setlocale(LC_ALL, "0"));
var_dump(basename("§"));

Be sure that file is UTF-8 encoded! Are you sure locales are even installed on your server? Check with your provider or with this command in shell:

locale -a

You may also try:

setlocale(LC_ALL, "C.UTF-8", "en_US.UTF-8");

@jacmaes

This comment has been minimized.

jacmaes commented Feb 10, 2017

@matjazpotocnik thanks for your help.

Please check that /wire/modules/Process/ProcessLogin/ProcessLogin.php is UTF-8 encoded

I believe it is, but I'm not sure how to check this. I uploaded the file as I usually do with the Transmit FTP app, and it should preserve the original encoding.

the results of these lines: var_dump(setlocale(LC_ALL, "0"))....

I hope I'm doing this right. I've placed this code on my "home.php" template and this is the output:
string(1) "C" string(0) "" string(11) "es_ES.UTF-8" string(0) ""

Are you sure locales are even installed on your server?

Yes, I've double-checked and it's correctly returning a long list of locales, including es_ES.utf8

You may also try: setlocale(LC_ALL, "C.UTF-8", "en_US.UTF-8");

Same issue.

@matjazpotocnik

This comment has been minimized.

matjazpotocnik commented Feb 10, 2017

Could you provide the output of locale -a? How about:

setlocale(LC_ALL, "es_ES.utf8");

@jacmaes

This comment has been minimized.

jacmaes commented Feb 10, 2017

Here's the output:

C
C.UTF-8
en_AG
en_AG.utf8
en_AU.utf8
en_BW.utf8
en_CA.utf8
en_DK.utf8
en_GB.utf8
en_HK.utf8
en_IE.utf8
en_IN
en_IN.utf8
en_NG
en_NG.utf8
en_NZ.utf8
en_PH.utf8
en_SG.utf8
en_US
en_US.iso88591
en_US.utf8
en_ZA.utf8
en_ZM
en_ZM.utf8
en_ZW.utf8
es_ES.utf8
POSIX
pt_PT.utf8

@jacmaes

This comment has been minimized.

jacmaes commented Feb 10, 2017

And setlocale(LC_ALL, "es_ES.utf8"); with double quotes still produces the same warning.

@matjazpotocnik

This comment has been minimized.

matjazpotocnik commented Feb 10, 2017

hope I'm doing this right. I've placed this code on my "home.php" template and this is the output:

Can you confirm that "home.php" is UTF-8 encoded? If you just used existing home.php provided with site profiles, than test will fail. If you don't know how to create file with UTF-8 encoding, then try this in home.php:

setlocale(LC_ALL, "es_ES.utf8");
if(basename("\xc2\xa7") === "") echo "fail";
else echo "yupee!";

And setlocale(LC_ALL, "es_ES.utf8"); with double quotes still produces the same warning.

You put setlocale in /site/config.php, then you logged out and logged in and you still get an error? Could I gain access to your site? PM me on the forum (matjazp).

@jacmaes

This comment has been minimized.

jacmaes commented Feb 10, 2017

  1. The code you sent me prints "yupee" on the homepage.
  2. Yep, it's in site/config.php. Then I logged out and then logged back in and still got the error.

I'll PM you on the forum. Thanks.

@matjazpotocnik

This comment has been minimized.

matjazpotocnik commented Feb 11, 2017

We have managed to make it work by putting setlocale() to the /site/templates/admin.php as putting the setlocale() just in /site/config.php didn't help.

@matjazpotocnik

This comment has been minimized.

matjazpotocnik commented Feb 13, 2017

It turns out that this PW instalation has Language Support installed and setlocale in config.php is rewritten in LanguageSupport.module ...

@adrianbj

This comment has been minimized.

adrianbj commented Feb 15, 2017

Hi everyone,
I haven't been following this fully, but I recently installed PW on a new server which returns "" for basename("§") and even after setting setlocale in config.php, the new Warning: your server locale is undefined and may cause issues. warning won't go away.

It looks like there is some issue with: setlocale(LC_ALL,'en_US.UTF-8'); in config.php
If I check the locale using setlocale(LC_ALL, 0); then it returns the system "C". But if I set it in /site/init.php then it works fine, returning the correct locale and the warning is gone.

Any ideas?

PS - just pinging @ryancramerdesign as well.
PPS - I have another server where setting it in config seems to work just fine.

@LostKobrakai

This comment has been minimized.

Collaborator

LostKobrakai commented Feb 15, 2017

Those locales do need to be installed on the server as well. Otherwise setlocale() will do nothing.

@adrianbj

This comment has been minimized.

adrianbj commented Feb 15, 2017

The locale is installed:

~# locale -a
C
C.UTF-8
en_US.utf8
POSIX

Besides if there was a problem with setlocale() not working in init.php then I would be suspicious, but it works there (and any template file for that matter), just not in config.php

Oh, and I checked setting setlocale(LC_ALL,'en_US.UTF-8'); vs setlocale(LC_ALL,'en_US.utf8'); and there was no difference.

@adrianbj

This comment has been minimized.

adrianbj commented Feb 15, 2017

@jacmaes - do you find that it works if it's placed in site/init.php ?

@LostKobrakai

This comment has been minimized.

Collaborator

LostKobrakai commented Feb 15, 2017

Check @matjazpotocnik's post above about LanguageSupport overwriting setlocale() calls in config.php. Is it that?

@adrianbj

This comment has been minimized.

adrianbj commented Feb 15, 2017

Thanks @LostKobrakai

Yeah, that is probably it - it is a ML site that has the problem and the single language site is fine.

@LostKobrakai

This comment has been minimized.

Collaborator

LostKobrakai commented Feb 15, 2017

In case of an ML site this check should probably be triggered after language support is loaded.

@matjazpotocnik

This comment has been minimized.

matjazpotocnik commented Feb 15, 2017

@adrianbj you can only set the locale that is installed, in you case either C.UTF-8 or en_US.utf8 (notice the missing dash).

@LostKobrakai if this check is done after language support is loaded, and locale is not set (or is C) on the underlying OS, the warning would still pop up, unless you put it in init|ready|admin.php. Now, I'm not ML user, complete noob to be honest, but I guess the proper way would be translating string "C" in LanguageSupport.module for each installed language. In this particular case C.UTF-8 for all languages since others are not installed.

@adrianbj

This comment has been minimized.

adrianbj commented Feb 15, 2017

you can only set the locale that is installed, in you case either C.UTF-8 or en_US.utf8 (notice the missing dash).

Actually as I mentioned, that doesn't actually seem to be the case - I can easily set the locale using en_US.UTF-8, even though it is not installed as such. It seems weird I know, but maybe there is some internal translation somewhere?

@matjazpotocnik

This comment has been minimized.

matjazpotocnik commented Feb 15, 2017

How are you sure, that you can set locale to en_US.UTF-8?

@adrianbj

This comment has been minimized.

adrianbj commented Feb 15, 2017

screen shot 2017-02-15 at 12 56 54 pm

@matjazpotocnik

This comment has been minimized.

matjazpotocnik commented Feb 16, 2017

From setlocale manual:

Returns the new current locale, or FALSE if the locale functionality is not implemented on your platform, the specified locale does not exist or the category name is invalid.

But setting the wrong locale doesn't work, I mean it won't fix basename() (and other) functions while setting the correct locale it would (if it wouldn't get overwritten by setlocale() in ML module file)?

@adrianbj

This comment has been minimized.

adrianbj commented Feb 16, 2017

http://superuser.com/a/999151/428562

The 'proper' name is UTF-8. However, Linux glibc will internally normalize the encoding name, by converting it to lowercase & removing most special characters, so both variants will work (as long as they don't escape to BSD systems).

Also, as an experiment, I tried: pt_BR.utf-8 and it returns "C", so I think on my system at least, both: en_US.utf8 and en_US.UTF-8 are valid, even though locale -a doesn't list the uppercase version.

@ryancramerdesign

This comment has been minimized.

Contributor

ryancramerdesign commented Mar 7, 2017

It sounds like resolution to this is to place the setlocale() call in /site/init.php or /site/ready.php – am I understanding correctly? If so, I will update the login warning message to reflect that.

@matjazpotocnik

This comment has been minimized.

matjazpotocnik commented Mar 7, 2017

Placing setlocale() to /site/init.php or /site/ready.php would make the warning go away, but I'm not sure this is the way to go. If multilanguage is not used, /site/config.php is just the right and obvious place. But, if multilanguage is used than I believe the proper way would be translating string "C" in LanguageSupport.module for each installed language. As I think more and more users will get this warning, maybe it should be displayed only if $config->debug is true?

So I would go this way:

If site is not multilanguage (LanguageSupport module is not installed), the warning should be the same, instructing the user to place setlocale() in /site/config.php. If LanguageSupport module is installed, the warning should instruct the user to either:

a) put setlocale in /site/init.php and let him know that this will affect all languages

or

b) translate the string "C" in LanguageSupport.module for each installed language

@ryancramerdesign

This comment has been minimized.

Contributor

ryancramerdesign commented Mar 7, 2017

Sounds like a good plan. I'll go ahead and update for that. Thanks.

ryancramerdesign added a commit to processwire/processwire that referenced this issue Mar 7, 2017

@matjazpotocnik

This comment has been minimized.

matjazpotocnik commented Mar 16, 2017

@jacmaes can you close this issue?

@jacmaes

This comment has been minimized.

jacmaes commented Mar 16, 2017

Sure.

@jacmaes jacmaes closed this Mar 16, 2017

foobarlab pushed a commit to foobarlab/processwire that referenced this issue Sep 15, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment