site_start setting not being affected by context settings - My Forums

site_start setting not being affected by context settings

joshkalsi — Feb 11, 2019, 04:39 PM

I'm working on a site running version 2.6.5 in MODX Cloud, with contexts set up to provide different translations. I'm trying to fix a problem where the URL of the homepages for each context is having "index" appended, e.g. /fr/index instead of /fr/ - trying to go to /fr/ will just time out. The only one that is reachable as intended (at /en/) is the English context, which happens to be the one set by the System Settings entry for site_start. Each context does have the site_start set at its own particular homepage resource, but if I show the setting with [[++site_start]], it's always showing the ID for the English homepage. If I then go in and change the System Setting to a different context's homepage, then that one will display as intended, the English one will start getting the index part added, and [[++site_start]] will now show the new homepage ID.

From everything I've read, the context settings should be overriding the system setting - I've tried with a few other settings, and those are working properly (it shows the context setting if it's defined, not the system one), but site_start is keeping its value from the System Settings instead. I've also checked the User settings and those are totally blank, so it's not getting set there. Is there something that I've missed that has a higher priority, or might be changing the setting back somehow?

Thanks very much!

Re: site_start setting not being affected by context settings

joshkalsi — Feb 15, 2019, 09:16 AM

Okay, I'll check that out - thanks for all the help!

Re: site_start setting not being affected by context settings

BobRay — Feb 14, 2019, 08:33 PM

As I said, it kind of looks like an issue with .htaccess.

The friendly URLs part of the standard MODX .htaccess file redirects everything to the index.php file in the MODX root directory. If requests are being redirecting to yoursite.com/fr/index.php, that won't be found which will bounce the user back to that same rule in an infinite loop -- hence the timeout.

Unfortunately, I don't know anything about either Babel or LangRouter, so I can't say why this is happening, but if either one alters or gives advice about altering .htaccess, I'd take another look at that process.

Re: site_start setting not being affected by context settings

joshkalsi — Feb 14, 2019, 09:53 AM

Ah, I think I've misunderstood that then, no worries - There's no user system for the site itself, I've just assumed that adding a setting to the admin user would somehow affect the whole site - thinking about it now that definitely doesn't seem right!

Yep, Babel is installed and does seem to be working properly, I've got no issues with the translated pages themselves, it's just this weird homepage thing. I'll have a look into that, anything in particular I should be looking for that might be causing issues?

Re: site_start setting not being affected by context settings

BobRay — Feb 14, 2019, 04:17 AM

Remember that a User Setting will only apply if the user has logged in *and* has logged in to the desired context.

Assuming that users are logging in, it might help to add this to the login tag:

&contexts=`en,fr,nl`

I see LangRouter is meant to be used with Babel. You have that installed and configured, right?

At this point, I'd suspect a problem with your .htaccess file.

Re: site_start setting not being affected by context settings

joshkalsi — Feb 13, 2019, 04:32 PM

Just tried defining a User setting for site_start to see if that would make a difference and that's also not behaving as expected so something funky is definitely going on. For clarity, I've got site_start set in the System settings to the resource ID of the French homepage, I'm loading the Dutch context so the Context setting is the Dutch homepage ID, and I've got a User setting that's for the English homepage. If the settings were behaving as I thought they were I'd be expecting the User one to be taking priority, and the site_start output should be that of the English ID - however, it's still showing the System value of the French ID. Not only are the Context settings not being applied, neither are the User ones, so this is obviously a bit deeper than I thought!

Re: site_start setting not being affected by context settings

joshkalsi — Feb 13, 2019, 04:14 PM

Attempted all the cache things and still no luck. There's no extra caching systems, at least none that I can find. Based on your comment about switchContext, I've been digging around in the LangRouter plugin to try and find if there's a point that the site_start ever actually equals the correct value. This is the relevant code for when the request comes in:

        if ($this->modx->context->get('key') != "mgr" && MODX_API_MODE == false) {
            $this->langrouter->logRequest('Unhandled request');

            // Get contexts and their cultureKeys
            $contextmap = $this->modx->cacheManager->get($this->langrouter->getOption('cacheKey'), $this->langrouter->getOption('cacheOptions'));
            if (empty($contextmap)) {
                $babelContexts = explode(',', $this->modx->getOption('langrouter.contextKeys', null, $this->modx->getOption('babel.contextKeys'), true));
                $contextmap = $this->langrouter->contextmap($babelContexts);
                $this->modx->cacheManager->set($this->langrouter->getOption('cacheKey'), $contextmap, 0, $this->langrouter->getOption('cacheOptions'));
            }
            $this->langrouter->logDump($contextmap, 'contextmap');

            // Determine language from request
            $queryKey = $this->modx->getOption('request_param_alias', null, 'q');
            $query = (isset($_REQUEST[$queryKey])) ? $_REQUEST[$queryKey] : '';

            $cultureKey = (strpos($query, '/') !== false) ? substr($query, 0, strpos($query, '/')) : $query;

            if ($cultureKey || $query === '') {
                // Serve the proper context and language
                if (array_key_exists(strtolower($cultureKey), array_change_key_case($contextmap))) {
                    $contextKey = $this->modx->context->get('key');
                    if ($contextKey != $contextmap[$cultureKey]) {
                        $this->modx->switchContext($contextmap[$cultureKey]);
						$this->modx->reloadContext($contextmap[$cultureKey]);
                    }

                    // Remove cultureKey from request
                    $_REQUEST[$queryKey] = preg_replace('~^' . preg_quote($cultureKey, '~') . '/(.*)~', '$1', $_REQUEST[$queryKey]);
                    $_SERVER['REQUEST_URI'] = preg_replace('~^/' . preg_quote($cultureKey, '~') . '/(.*)~', '/$1', $_SERVER['REQUEST_URI']);

                    $this->langrouter->logRequest('Culture key found in URI');
                    $this->modx->cultureKey = $cultureKey;
                }

The log function on line 2 outputs this, which shows the context as web and the site_start as 1, which I'd expect (note I've added the "from context" string to the log function, just so I can verify where the setting is coming from).

[2019-02-13 15:41:25] (ERROR in LangRouter @ /paas/c0068/www/core/components/langrouter/model/langrouter/langrouter.class.php : 155) Unhandled request:
REQUEST_URI:   /nl/index
REDIRECT_URI:  
QUERY_STRING:  q=nl/index
q:             nl/index
Context:       web
Site start:    1 - from context

Then, the context gets switched on line 24 based on the URL - I've added the reloadContext call too as you suggested, doesn't seem to be making a difference alas, as when the log is called again on line 32 it outputs:

[2019-02-13 15:41:25] (ERROR in LangRouter @ /paas/c0068/www/core/components/langrouter/model/langrouter/langrouter.class.php : 155) Culture key found in URI:
REQUEST_URI:   /index
REDIRECT_URI:  
QUERY_STRING:  q=nl/index
q:             index
Context:       nl
Site start:    1 - from context

The context has been changed correctly, but the site_start is still 1, and it's definitely coming from the context.

I've also tried changing the log to check other context settings and those are coming out correct, it's just something weird happening with this site_start for some reason. I think I'm gonna take this to the LangRouter people and see if they can help cause I am still stumped - thanks for the assistance so far though! Figured I'd throw all this up in case it helps someone else down the line.

Re: site_start setting not being affected by context settings

BobRay — Feb 12, 2019, 07:17 PM

My bad. Brain fart at 3 am. It should be site_url.

Try manually deleting the core/cache files to make sure your changes apply.

Another possibility is that your multi-language system is switching to the alternate context after the settings have already been loaded. index.php initializes the 'web' context by default which loads all its settings. The switchContext() method likely gets called somewhere, which should redo the settings, but maybe reloadContext($ctx) is also necessary.

Are you running any extra cache system like Varnish, Memcache, or APC? That could also be the problem.

Also, try your browser in private of incognito mode to see if it might be a browser cache issue.

Re: site_start setting not being affected by context settings

joshkalsi — Feb 12, 2019, 09:33 AM

It's already being called uncached, so that's not it unfortunately. It is using site_url rather than site_start though, should I be using the url of the site_start resource for the base instead?

Re: site_start setting not being affected by context settings

BobRay — Feb 11, 2019, 08:37 PM

I'm not sure this will solve your problem, but for multi-language sites, the site_start tag must be called uncached (with the exclamation point), all templates should include an uncached tag in the base href tag:

Without that, you'll often get a cached version from a different context.