How is ++site_url determined during parsing?

How is [[++site_url]] determined when pages are rendered by Modx?

I am seeing situations where site_url is defined as 'www.example.com' but at random times, it renders as 'subdomain.example.com' Wayfinder seems to do this a lot.

What would happen if my client logged into the manager using 'subdomain.example.com/manager' instead of 'www.example.com/manager' ? Would Modx assume that the value of HTTP_HOST is actually the value of ++site_url ?

It's done in your config.inc.php file. site_url is built up from base_url, which is set during installation. The domain part is calculated at run-time from some of the $_SERVER variables, primarily $_SERVER['HTTP_HOST'].

The Wayfinder variations are probably because people are coming in from different subdomains, and the page is getting cached that way. Other pages will get cached from other user requests.

Based on your explanation and my own observations, it is possible for an anonymous visitor to effectively override the value of ++site_url as defined in the config file. They simply request a page from another subdomain. That's a problem. Why have a config file at all if the values in it can be completely retooled through anonymous requests? Seems very counterintuitive.

In my experience MODX almost always calculates the correct URL except in a few rare circumstances where I was working on custom server setups.

Can you demonstrate how a value in the config file could be "retooled" via an anonymous request? The only case where I can think of this possibly coming up is if you have multiple domains or sub-domains mapping to the same docroot without URL forwarding...

I used to have a problem when I had a "parked" domain pointing to my sottwell.com domain. I ended up having to add a rewrite rule to my .htaccess file to rewrite all requests to seconddomain.com to sottwell.com

This can also be an issue if you're using subdomains in subdirectories; you can have subdomain.domain.com/ and domain.com/subdomain/ both working. Again, rewrite rules in the .htaccess file can solve the problem.

@Everett, that's exactly my situation. We needed the site to run faster. So we set up a subdomain (media.example.com) which is cookie free, so request/response times are faster. media.example.com has identical mapping to www.example.com. I.e., www.example.com/image.jpg and media.example.com/image.jpg are identical, except the latter has no cookie data in the request. YSlow! recommends this approach, and it actually works great, especially when pages have a ton of external images, css and scripts.

So: if I then access a page using media.example.com/page.html, and the cache is empty, ModX will assume that 'media.example.com' IS the value of ++site_url. ModX will then use media.example.com as the value in the <base> tag as well as any (and all) absolute URLs reference anywhere in the code.

At some point, my client somehow stumbles onto http://media.example.com/manager and bookmarks it. Because ModX does not actively enforce ++site_url, my client makes page edits and repeatedly previews their changes, causing media.example.com to be constantly written to html and cached. Then. googlebot spiders the site, and now we've corrupted our SEO ranking. Even better: any visitors viewing the site under media.example.com have no cookies set, so, Analytics says we have zero traffic. In the end, I have a huge cluster to deal clean up and I've got some extremely aggravated clients.

I think ModX should actively enforce ++site_url, not just lazily assume that the value of $_SERVER['HTTP_HOST'] is accurate. Why have a config value at all if the browser request simply overrides it?

Yeah, that's a somewhat unusual situation. I think you'll find most web apps behave very similarly in this situation, so this isn't particular to MODX. You're pegging the domain, so it's not entirely unexpected that things downstream (including cookies and webapps) follow suit.

I would do a couple things:

1) There are better ways to get speed out of your site, e.g. put assets onto a CDN, use a lightweight server process (e.g. NGINX), or install something like mod_pagespeed to help compress CSS and Javascript. That's probably a much more effective way of reducing load times without the headaches of multiple domains. Your solution may work in some circumstances, but it's not conventional, so you have to be prepared for the chaotic edge-cases it creates. Talk to me about some VPS hosting options with some *sick* load times if you're interested. We can spin up a server optimized for this exact thing in minutes.

2) if nothing else, hack the config file to force the site url. This is not entirely kosher since MODX timestamps the config (i.e. rewrites it) on upgrade. I would guess that some .htaccess modifications or a clever plugin would help shepherd requests here too, but I would only go down this route after I had optimized the stuff from #1

Hope that's helpful.

You can also specify a site_url by creating a custom setting for the web context. I'm pretty sure this will override the one that comes from the config.inc.php file.

That's genius, Susan. Much better idea than hacking the config file...

Also, you can use the tag uncached so it will use the domain requested by the client as the host, or the the one rewritten by the server...