Modx locale setting when used in contexts

Support
1

Summary

When using system settings, locale setting just works perfectly. But if you have a multi context site, and you define locale setting per context, it is not overridden, even if general system setting is empty.

Step to reproduce

On a template, use the createdon date with an output modifier in order to output data with text, like 20th September 2019:

[[+publishedon:date=`%e %b %Y`]]

Then go to system settings and change locale to different language and you will see it applied properly.

If you have other contexts and edit/add locale setting into the contexts, and clear the general locale system setting, it won’t work. It just outputs in English

Expected behavior

Context defined locale should be processes just like any other system setting when defined on the context.

Environment

MODX 2.7.1-pl (Windows or Linux showing same behavior. Windows with latest xampp with php 7.3, Linux with php 7.3 and cpanel), with xrouting and Babel

Thanks in advance for your help and suggestions

1 Like
2

Hi All,

Anyone, please? :slightly_smiling_face:

Thanks in advance

1 Like
3

Ok let’s try to get more info here.

  1. When general locale is set, and context locale is set, then all contexts use general locale?

  2. When general locale is not set, then context locale is ignored?

So, context locale simply doesn’t work? Ever?

4

Have you tried adding a timezone context setting as well?

1 Like
5

Hi all,

@nuan88,
1 - yes, correct;
2 - exactly;

@digitalpenguin,
I didn’t try. I was not aware that this was a need (is it?). I will try and report back.

Thanks all!

1 Like
6

To be exact, it’s the date_timezone setting.
e.g. Asia/Hong_Kong as the value for me.

I’ve used it before when on shared hosting where I couldn’t set the server time directly.
(That was just a system setting, however a context setting should work too.)

1 Like
7

Got yor point now.
What I am trying to achieve is a language change when date is having text. This is why I am using locale. No need for timezone change on my situation :slight_smile:

2 Likes
8

Ah apologies, I misunderstood!
If it’s working with a system setting but not context switching, perhaps caching is coming into play.
My first step troubleshooting it would be to load the first context and see the expected result, then delete the cache and load the other context.
If that works then at least you’ve narrowed the cause down a bit.

1 Like
9

just tested it, no go…
3 different contexts:
fr - locale: fr_FR.UTF8
en - locale: en_EN.UTF8
pt - locale: pt_PT.UTF8

If I set locale on the general settings, it is assumed and works, but never on the contexts directly.
Not cache related as I cleared cache every single time I changed context.

1 Like
10

We can work this out, finally

1 Like
11

Hmmm it looks like PHP’s date doesn’t take the locale into account (the MODX date output modifier uses this function). So, it might be better trying to use strftime instead.
https://www.php.net/manual/en/function.strftime.php

Hopefully that sorts it out for you!

3 Likes
12

Now doing a deep read on php date and strftime function I fully understood your answer. How silly I was. It was just a matter of reading it…
Thank you for taking me out of the shadow :smile:

Next time, you can just do like this:
RTFM: (link) :joy:

Many thanks for your time. I will test and share the result.
Cheers all

1 Like
13

well, after digging a bit more, it seems that (in theory), this should be working by default with the date output modifier:
https://docs.modx.com/revolution/2.x/making-sites-with-modx/customizing-content/input-and-output-filters-(output-modifiers)

If you check the date description, it should behave just like php strftime, but it partialy does, as I explained previously.

I will try to create a snippet to be used as output modifier specificaly with strftime.
Anyway, shouldn’t this be seen as a Modx bug on the date output modifier?

Thanks all

1 Like
14

OK, I was finally able to get a conclusion out of this.

here is the small test snippet (name: phpstrftime):

$modx->log(modX::LOG_LEVEL_ERROR, '[phpstrftime - Custom Output modifier] current locale: ' .  $modx->getOption('locale'),'','phpstrftime');

// it seems that Modx cannot get the current locale setting. Let's force it
//setlocale(LC_ALL, $modx->getOption('locale'));

$output = strftime($options, $input);
return $output;

When calling the output modifier like this:

[[+publishedon:phpstrftime=`%e %b %Y`:uppercase]]

there is a line registered on the system log that shows this:
[2019-09-29 11:11:53] (ERROR in phpstrftime @ D:\xampp\htdocs\core\cache\includes\elements\modsnippet\73.include.cache.php : 20) [strftime - Custom Output modifier] current locale: pt_PT.UTF8

So the locale setting is set on the system properly and coming from the Context, as the general system setting was left blank on purpose.
But the date is still delivering the string in English:
8 SEP 2019

As soon as I uncomment the setlocale on the snippet, everything works just fine.

This seems really to be a Modx bug where locale setting on contexts is not calling the setlocale.
If locale setting is defined on the general system settings, it just works fine.

Just for reference, i am using modx 2.7.1-pl

2 Likes
15

You’ve really become a Modx expert or nearly so in these months, its great to see.

1 Like
16

I still have a very long pathway to expertise. I need still to deep-learn xPDO… This is where we can extract the real magic from :slight_smile:

I will do some additional checks regarding this point, upgrade to Modx 2.7.2-pl (just to double check) and if justificable, I will open a bug report on modxcms github.

Many thanks all for the hints (even though I didn’t read properly the documentation on these last two days).

I will share the final result with you after my final testing (I will dig a bit on the modx core).
Cheers all

1 Like
17

Haha I provide few hints, only some morale support :slight_smile: maybe a little direction sometimes

Remember, no hacking the core. You can always hack things outside the core to work out a solution

18

I do seem to recall a bug report or a pull request related the locale setting not being respected in contexts (because locales are initialised before contexts) but haven’t been able of tracking that down. Opening an issue on GitHub would be the next step.

1 Like
19

The function _initCulture is responsible for initialising the culture settings.

_initCulture is only called when MODX is initialised (link to source). By default it initialises using the web context.

When switching to another context using switchContext the _initCulture method isn’t being called.

4 Likes
20

OK, thanks for the clarification. This seems to explain why locale is not processed properly.
I will try to have some time at the end of the day to open the bug report on modx github.

Thanks all for your tips.

2 Likes