[(site_url)] - Drawing out incorrect site url?

Hi guys,

I’ve had issues with 2 sites recently that use the [(site_url)] placeholder.
I used it to set the base href as follows:
<base href="[(site_url)]" />

With both sites it seems to intermittently write the url out incorrectly as:
http://mydomain.com, rather than http://www.mydomain.com

Can anyone offer up an explanation as to why this surfaced all of a sudden? Both sites were fine for weeks with the full url being drawn out? I have not updated or patched either, and nothing has changed with the host.

Thanks in advance guys.

Justin

Hi. Try to uncomment these strings in .htaccess file

Then replace example with your domain. And clear cache.

Quote from: Paprikas at Apr 29, 2010, 04:14 AM

Hi. Try to uncomment these strings in .htaccess file

#RewriteCond %{HTTP_HOST} .
#RewriteCond %{HTTP_HOST} !^www\.example\.com [NC]
#RewriteRule (.*) http://www.example.com/$1 [R=301,L]

Then replace example with your domain. And clear cache.

Hi there,

I am sure I have fixed the issue, however I would like to know why the [(site_url)] placeholder would start giving out different values?

Thanks

Quote from: jusmeig at Apr 29, 2010, 10:00 AM

I am sure I have fixed the issue, however I would like to know why the [(site_url)] placeholder would start giving out different values?

It is designed to return whatever HTTP_HOST is reported by the web server to PHP. Most web servers simply pass along the HTTP_HOST requested by the client browser unless specifically configured to override it. This allows sites to serve multiple domains if you have multiple virtual hosts configured to the same location. In those cases, you would not want to cache site_url into any of your pages, and it is recommended you return the site_url from a non-cacheable snippet instead of using [(site_url)] -- which will always get cached in Evolution. In Revolution, note that you can make any tag non-cacheable, so [[!++site_url]] is a valid tag which will prevent caching it from the first client to access the page.

Quote from: OpenGeek at Apr 29, 2010, 10:25 AM

Quote from: jusmeig at Apr 29, 2010, 10:00 AM

I am sure I have fixed the issue, however I would like to know why the [(site_url)] placeholder would start giving out different values?

It is designed to return whatever HTTP_HOST is reported by the web server to PHP. Most web servers simply pass along the HTTP_HOST requested by the client browser unless specifically configured to override it. This allows sites to serve multiple domains if you have multiple virtual hosts configured to the same location. In those cases, you would not want to cache site_url into any of your pages, and it is recommended you return the site_url from a non-cacheable snippet instead of using [(site_url)] -- which will always get cached in Evolution. In Revolution, note that you can make any tag non-cacheable, so [[!++site_url]] is a valid tag which will prevent caching it from the first client to access the page.

Thanks for the reply, this is starting to make more sense now.
So in my case if the client came to the site with http://domain.com and it got cached and used as the base url, all other links from the cached page would be off http://domain.com.

Does MODx automatically clear it’s cache (Apart from when you save a doc etc)? I don’t recall clearing the site cache around the time the problems started? I guess this must have hapened, and the first client to cache the homepage came on http://domain.com

Quote from: jusmeig at Apr 30, 2010, 02:56 AM

Does MODx automatically clear it’s cache (Apart from when you save a doc etc)? I don’t recall clearing the site cache around the time the problems started? I guess this must have hapened, and the first client to cache the homepage came on http://domain.com

No automatic clearing occurs.

I generally avoid the [(site_url)] parameter because I’ve had instances where the webservers report it incorrectly... I often make use of a chunk to supply this info. It can make things a bit smoother when moving the site between dev/qa/prod environments.