01077: Locale gets lost after Post / Redirect()
Description:
Sporadically when posting a page my German dates swap to English. Not the $TimeFmt, but the month and day names.
What happened? The LC_TIME, supposed to be 'German_Germany.1252', has changed to 'C'.
This really only happens after POSTing. Not when CANCELing. Refreshing the Browser restores the German Locale.
Some pages don't seem to suffer from this at all. Some pages sometimes do and sometimes don't. Lucky debugger I was I got some pages that always reproduced the buggy behavior (No, I don't know what's special about those pages).
I traced the Locale from the start of pmwiki.php script by inserting the following code at appropriate places:
$XLocaleInfo .= "\n"."reached line XY/doing Z: ".setlocale ( LC_ALL, 0);
and StopWatching the $XLocaleInfo in HandleBrowse().
config.php calls XLPage('de','PmWikiDe.XLPage'); and it stays 'German_Germany.1252' until stdconfig.php is inlcuded.
In the line after include_once(" the Locale had ALWAYS changed to:
$FarmD/scripts/stdconfig.php");
LC_COLLATE=C;LC_CTYPE=German_Germany.1252;LC_MONETARY=C;LC_NUMERIC=C;LC_TIME=C
So what happens within stdconfig.php?
Nothing special. Mainly the inclusion of a bunch of other scripts. Which one is the bad one?
It's none of them. Sometimes the Locale stays German until the first inclusion, sometimes it holds out until the fifth or eleventh - no system, not reproducable. The only fixpoint is: after the inclusion of stdconfig the German Locale is gone.
Some experimenting provided two possible workarounds. They both are patches in pmwiki.php:
Workaround 1: Fix Locale
Restore the desired Locale after the inclusion of stdconfig.php. Insert (its about line 326) into pmwiki.php the following:
setlocale(LC_ALL, XL('Locale'));
That's not very elegant and who knows wheter it's only by accident that the Locale swaps within stdconfig and never afterwards.
Workaround 2: Alter Redirect()
As the bug only happens after Redirect() it should be fixed there. Don't know why but commenting out the red lines in function Redirect() did the trick:
if (IsEnabled($EnableRedirect,1) &&
(!isset($_REQUEST['redirect']) || $_REQUEST['redirect'])) {
header("Location: $pageurl");
/*
header("Content-type: text/html");
echo "<html><head>
<meta http-equiv='Refresh' Content='$RedirectDelay; URL=$pageurl' />
<title>Redirect</title></head><body></body></html>";
*/
exit;
}
Not a very good one, too. Especially cause I don't understand why cutting off the friendlyness prevents the Locale, set in the redirected URL, from swapping.
Notes
- My server is a local one.
- I decided to use workaround No1, seems less side-effective to me.
- Maybe this feature is related to (closed) PITS 00903 ?
What exactly seems a problem, does a page get saved with dates in the wrong locales? Are RecentChanges and AllRecentChanges affected? Does it happen when you press "Save and edit"? If that happens upon redirects only, after the browser is redirected and opens the target page, is the locale wrong? --Petko March 02, 2009, at 12:00 AM
No, luckily nothing weird happens to page contents. Only the display of dates is affected, like e.g in the footer where $[Page last modified on {$LastModified}] instead of being displayed as 'Zuletzt geändert am 02. März 2009, 09:04' changes to 'Zuletzt geändert am 02. March 2009, 09:04'.
Of course since LC_COLLATE, LC_MONETARY and LC_NUMERIC have changed too, there will be other display effects, but I didn't explore them...
As I said: as soon as I refresh the browser (call action=browse) or any other action (edit, source, diff..) the Locale/month name is fine again.
Also redirecting from another page via (:redirect PageThatKillsLocale:) doesnt produce the bug. Nor does it happen wenn Redirect() is called by pressing "Cancel".
Really, it seems to be Redirect() after Post only. And only casually.
Presuming it was a matter of time I enlagerd the $RedirectDelay but without any effect...
If I only could tell what's so special about the bug-is-reproducale-pages... --Tontyna March 02, 2009, at 02:46 AM
More Notes
This bug drives me mad! I know, it shouldn't - my little son wants to know what's so horrible about reading 'March' instead of 'März' when it turns back to 'März' by pressing "F5". But - but - but - I'm a programmer - and had another confrontation with the switching Locale that made my addiction worse:
Turned off the computer (yes, I do, sometimes) and told FF to store the Tabs and Sessions:
- Tab#1 contained my favorite bug-is-reproducable-page in EDIT mode.
- In Tab#2 SiteAdmin.AuthUser?from=Site.AuthUser was open (research item Redirect())
- Finally Tab#3 displayed my internal documentation about this bug in BROWSE mode
When I left them, all three, of course, were perfectly German.
Turned on the computer again and opened FF. I didn't realize it at once, but when I did it drive drove driven me crazy.
As $EnableStopWatch was turned on I hat the StopWatchHTML list to look WHO DID IT and WHEN.
- Tab#2 was ok
- Tab#1 (remember: EDIT mode) dislpayed 'zuletzt geändert am 02. März 2009, 11:29' in the SideBar and 'Zuletzt geändert am 02. March 2009, 11:29' in the Footer.
Output of StopWatch shows that Locale stays German almost until the end:
.... 122: 04,35 FPLTemplate: Chain end 123: 04,36 ---- ListCategories begin 124: 04.63 ---- ListCategories end 125: 04.70 MarkupToHTML end 126: 04.71 now
What strikes you? Nothing? Ha, don't you see how the German comma switches to the English dot? Any idea about funny things ListCategories might do? No. fopen, fgets, fclose PageIndexFile, do some string operations.
By the way: this happens somewhere at the end of the RightSideBar so the {$LastModified} at the top of the SideBar is ok.
The {$LastModified} in the Footer is provided at the very end of the .tmpl file and uses the switched Locale. (I love PTVs ant PVs not being assigned once forever but being evaluated anew on every request.)
- Tab#3 knocked me out with this:
See the switch? In the midst of the GroupHeader! SideBar follows...
The Locale swaps within a Template/section included by the GroupHeader:
...
32: 00,52 FPLTemplate: Chain begin -- the trail-like pagelist in GroupHeader
33: 00,52 FPLTemplate: FPLTemplateLoad
...
58: 00,69 FPLTemplate: FPLTemplateFormat -- evaluating the template
59: 00,74 MarkupToHTML begin German dates: 28. Februar / 1. März
| comma
= = = = = = = = = here the Locale swaps -- output of the dark gray box
| dot English Locale: Mar / Sunday
60: 01.61 MarkupToHTML end
61: 01.61 FPLTemplate: Chain end
...
Want to inspect the Template? Won't be any enlightment. Uses MarkupExpression substr to cut an iso date off the prev and next $Name and ftimes them (still German). Afterward similar with =$Name but within the gray box (now English).
Never heard that strftime affects the Locale setting.
But funny ideas arise when weird problems turn up. To be honest - there were moments I thought: "This MUST be FireFox". Yeah, I know ... but ... nothing in Apaches error.log ... nothing in access.log ... I don't wanna tell ... but: IE is fine ... my famous bug-is-reproducable-page ... FF switches to English, forever ... IE doesn't. Oh my!
Before I change the Priority of this PITS to X let me suggest another workaround I detected:
Workaround 3: Turn on Error Reporting
Changing the first code line in pmwiki.php from
error_reporting(E_ALL ^ E_NOTICE);
to
error_reporting(E_ALL);
fixed the bug. Indeed it did.
Okay, now the upper half of my screen is filled with Notices (no, I didn't expect THAT much!) but 'März' stays 'März'.
Wasn't that what I wanted?
Conclusion
I'm almost shure that this is a runtime issue with a timing problem. Nothing that PmWiki could or should fix.
Tontyna March 02, 2009, at 07:40 PM
I am closing this entry as your conclusion suspects that it is not a PmWiki bug. In case we have more information and some action is required, we can reopen it. Thanks. --Petko July 08, 2009, at 09:11 AM