Locale settings being lost repeatedly

Ipstenu

Zenphoto isn't retaining locale settings consistently

https://cloud.githubusercontent.com/assets/807903/3347046/95ebd0fc-f8d2-11e3-9f6d-0038421a86c7.png

Every time I log in anew, that gets wiped out. The only way to fix it is to go into settings (where I see that yes, I did too set it right)

https://cloud.githubusercontent.com/assets/807903/3347048/b7a90688-f8d2-11e3-8331-2a37f0a1afbb.png

And I hit apply at the bottom of the page. BUT. When I do that, it wipes out any language based settings for the page. So the email 'Name' of Zenphoto has to be reset.

If I neglect to do this and go into an album to edit descriptions or names (which I do frequently), it will *erase all the language based data for the page I just saved*. Yes. Erase.

Is there a place I can hard-code my locale in to lock this down?

acrylian

I tried to reproduce it on my shared hosting test site, my local site and on zenphoto.org.
- So I was logged in with English set
- Switched to German, entered text on an album and logged out again. I did not try multilingual mode yet as you didn't mention it.
- Logged in again and I still had German and all content was there as before, including the site name

Zenphoto always stores all multilingual capable content in seralized arrays, basically one field for each language. On quite older versions it did switch between plain storage and serialzed arrays if multilingual mode was set. Then disabling multilingual would indeed erase content. It was changed therefore quite a while ago. Was this by chance old content? Did you ever use multilingual at all?

Did you try to set a default language for the user you are logged in (on the user account)? That is stored in the database (administrators table > language).

If the locale cannot be fetched it might be an issue on the server. Of course to for example use the French locale your server must have it installed, otherwise it cannot be fetched naturally. Generally servers have only the locales of their country as it seems at least over here (my live one has only German and English). But I am sure you know these things already :-)

Are there really no errors in the server log?

Ipstenu

So no, there is no place I can hard force a define of my language so no matter what it shuts up?

I get that I'm an edge case (and it would be better if I find why and fix it), but I can see other reasons why someone would want to lock the language for the site down and prevent multiple languages (derp admins, etc).

I tried setting this:

`define('ZENPHOTO_LOCALE', 'en_US.UTF8');`

Which works, but it tells me that functions.php already defined it in the debug log ... wouldn't THAT make more sense to allow an override without editing core files? If the functions.php file had a check for is_defined, then it could be overridden.

I've never had multilingual set as my French and Spanish are abysmall In fact, English is the ONLY language set on my install (everything else is inactive). If I look at my profile, I have the American Flag, so it must be set. No other options exist.

PHP says my language (and lang) is en_US

Nothing in the error log for the server OR ZenPhoto. It's been baffling me ever since y'all switched from text to serialized input. I get WHY you did it, it's a totally awesome way to handle multiple languages. But it's an absolute PILL if it goes wrong, because it can wipe out your content.

"Was this by chance old content? "

Yes and no. Originally, yes, because ... all my content was old But the current setting (on the settings page) for the name of the email-from account (Zenphoto) gets wiped no matter what when I re-save that pages....

It's like it thinks it's supposed to be Multilingual and then not, and then yes again.

How old is this? I forget how long I've been using ZenPhoto on this site, but at least since 2009. I have a note on my server that says I upgraded it at that time.

The only other thing I've got is that I log in between two different computers fairly often and I'm behind a VPN half the time, so I have to log in more often than most people I suspect.

I added `define('DEBUG_LOCALE', true);` to my config to see if that gives anything meaningful.

acrylian

I get WHY you did it, it's a totally awesome way to handle multiple languages. But it's an absolute PILL if it goes wrong, because it can wipe out your content.

Yes, as with all things that go wrong ;-) But that is why we made it permanently seralized as the switching was dangerous. That change was years ago (don't even remember) but multilingual itself we have since 2008 at least.

I am sorry that I have no other idea right now what is going wrong on your install. Especially the content deletion is of course something that really should not happen. Just changing the language should not be able to do anything to content itself as that does not save anything.

I can only assume that it was old content that never was updated and something went wrong when re-saving it. Although that should be covered. We realyl should have noticed that on our site as we have quite a bit of content ourselves.

Maybe you could look up some old content how it is stored in the database, backup it and try to reproduce your issue? That would maybe give us a clue.

So no, there is no place I can hard force a define of my language so no matter what it shuts up?

Well, yes, there are:
1. The general language option: `options` table > locale (`setOption('locale','en_US',true);` – true means add to database permanently, false means temporarily - works for most options btw).

You can of course also "hack" the constant define to find out if that fixes it at all. If that doesn't as well, there must be something else really going wrong.

2. As mentioned above there is also the default language option for each user in the `administrators` table on your user account row in the field "language". That should be set if you change it on the user account.

3. And then there is of course the cookie for normal visitors that use the language selector on the front end. But that should not have any role here.

Ipstenu

I can only assume that it was old content that never was updated and something went wrong when re-saving it.

I think that's right, since if I look in the DB, the old content is NOT serialized... I recall noticing this about 8 months ago (aha, see this old post) and it wasn't until then that it became forced, because I really, truely, do no

I did the 'hack' (booooo hiss!) and it worked. So it's just not STICKING in the database. Insert Jackie Chan WTF face here.

So it's 'broken' right now and I went to the DB and it clearly says there that the language is en_US which is even weirder

Oh and I took a backup locally and tested. Same thing.

(All users have US and only US as the flag option for language so there's nothing to check or change)

`
{11052:Mon, 23 Jun 2014 16:14:10 GMT} Zenphoto v1.4.6[bbddab76753e1d753a54ead4eb74b41d7d46cf73]
getUserLocale()
getUserLocale called from setMainDomain (functions-i18n.php [182])
from require_once (functions.php [30])
from include (index.php [14])
from index.php [28]
{11052:Mon, 23 Jun 2014 16:14:10 GMT}
validateLocale(jorjafox,HTTP_HOST)
{11052:Mon, 23 Jun 2014 16:14:10 GMT}
locale from option: en_US; dynamic locale=k�
��
{11052:Mon, 23 Jun 2014 16:14:10 GMT}
getUserLocale Returning locale: k�
��
{11052:Mon, 23 Jun 2014 16:14:10 GMT}
setlocale(k�
��.UTF8,k�
��.UTF-8,k�
��.@euro,k�
��,) returned:
{11052:Mon, 23 Jun 2014 16:14:10 GMT}
setupCurrentLocale(k�
��): locale=k�
��, $result=
setupCurrentLocale called from setMainDomain (functions-i18n.php [183])
from require_once (functions.php [30])
from include (index.php [14])
from index.php [28]
`
SO! Interesting how the characters are wrong there, eh? � I tried with UTF-8 true and false, but it came out the same.

acrylian

The old content actually should work and be serialized on the next saving. Otherwise our own site would have some problems as well…

Really weird issue I wish I had a proper idea to and could even reproduce… I am sorry that I am a bit clueless right now.

Wild guess would be the lovely issue with form processing going wrong because of too many form elements to post. But on that options page…? And there probably should be an error as well… Strange with the encoding of the log as well.

Did you test what the locale constant actually says on theme pages? Maybe that gives us a clue where it gets lost or something.

sbillard

Are the characters wrong in the debug log or just in the post?

can you look in your database options table for the option "locale" and in your browser cookies for the cookie "dynamic_locale" and report their values?

Maybe also clear the "dynamic_locale" cookie and see if it helps.

Ipstenu

Tried with a fresh install on the same server:

PHP setlocale() failed
Warning!

Locale functionality is not implemented on your platform or the specified locale does not exist. Language translation may not work.
See the troubleshooting guide on zenphoto.org for details.

Well THAT'S probably it. So PHp is a moron.

acrylian

That would explain some issue but of course not really why you got content erased…

sbillard

I did try to simulate this failure on my builds. Could not reproduce your problem. So if you cannot get setlocale() to work correctly you might want to try the master branch of ZenPhoto20 and see if it works.

Ipstenu

My guess is that when there's no locale detectable, it's not actually failing back to anything so it's unable to save the serialized data?

When I check via shell:

`
$ locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
`
so that's what I want.

But if I toss `echo setlocale(LC_ALL, 0);` into a php file, it kicks back C.

>.<

From man setlocale on my box:

The locale "C" or "POSIX" is a portable locale; its LC_CTYPE part corresponds to the 7-bit ASCII character set.

This may be endemic to my OS/PHP setup?

http://bugs.centos.org/view.php?id=3187
https://www.centos.org/forums/viewtopic.php?t=11893

*sigh* Not sure how to force that around.

Same thing happens on ZenPhoto20

Ipstenu

1. The general language option: options table > locale (`setOption('locale','en_US',true);` – true means add to database permanently, false means temporarily - works for most options btw).

Where do you set that? You mean I put the option value in the DB as `setOption('locale','en_US',true);` ? I tried putting that in my zenphoto.cfg.php file, but it white-screened on me.

acrylian

Maybe just ask your host to install the locale… Shared hosts here I know have all the local one (de_DE) by default and mine installed a en_US one they forgot after a server upgrade in minutes.

acrylian

You can use that on any theme page directly or even better your theme's functions.php (like you do these things on WP ;-)). on the cfg. file you cannot do anything like that, too early in the chain.

Ipstenu

It's a VPS So technically I can install everything I want. But ... it HAS the locale, is the thing! It's set to en_US like it should be and the local is installed and working. It's just kicking setlocale weirdly. I have a ticket in to see if they can make any more sense of it.

functions.php didn't work so I put it in themeoptions.php and THAT seemed to make both the installer and the admin happy.

*fingers crossed for now*

sbillard

But if I toss echo setlocale(LC_ALL, 0); into a php file, it kicks back C.

What do you get from `echo setLocale(LC_ALL,'EN_US.UTF-8');`?

I would still like to know what the 'dynamic-locale' cookie value was.

Ipstenu

`echo setLocale(LC_ALL,'EN_US.UTF-8');` echos nothing though if I use en_US.UTF-8 it works.

The dynamic-locale cookie value is `%0E%CC%0A%E86`

acrylian

Right, my fault, theme's functions.php is probably too late to change the option for everything. themeoptions.php comes earlier. At least good if that works for now.

The dynamic locale cookie looks not correct. Makes sort of sense if there is no locale sticking…
Since I am no server export are you sure the server is setup correctly regarding the locale?

Ipstenu

Nope, I don't know either, so I have an open ticket with my host and politely asked my frind who IS a server guru

acrylian

Ok, keep us posted what those two may find out.

Ipstenu

Will do! What;'s an example of a GOOD dynamic_locale cookie content? I'm assuming it'd be like de_DE or something?

acrylian

Yep. just a locale like that.

sbillard

remove that cookie, it is probably the cause of all your problems.

Ipstenu

Update!

1) Cookie removal didn't help

2) glibc was weird.

So for SOME REASON /etc/localtime was set to an alias and pointed to `/usr/share/zoneinfo/America/Los_Angeles` (which isn't WRONG really but anyway)

I removed that and reinstalled glibc, and now it's outputting properly. Preliminary testing with Zenphoto shows this solves the issue.

So with both a fix AND a workaround, I think this just needs to be documented under "Weird stuff"

sbillard

As to the work-around. The best place to put the code would be in a custom "class" plugin. Those get loaded really early on.

Ipstenu

I wasn't sure what to hook it into. It it was WP, I'd hook it into the admin_head() function.

sbillard

So for SOME REASON /etc/localtime was set to an alias and pointed to /usr/share/zoneinfo/America/Los_Angeles (which isn't WRONG really but anyway)

I suppose that PHP is not handling the alias then. Certainly nothing wrong with the time zone. That is the one I am in after all.

Ipstenu

Ditto It's honestly weird, I got a hold of my fav server adminy friend who sorted out the glibc stuff and she said, I quote "Weird."

acrylian

Thanks for the update. Where would be the fun without such "weird" issues, right? :-)