Moved site, stuck on old, have tried the usual remedies

I have a site at www.example.com. I cloned this site to a subfolder on a local server. I followed all the right steps including running an upgrade install and clearing cache. [[++site_url]] on the local version of the site now evaluates to ’www.example.com’ and I don’t seem to be able to shake it loose of that delusion. When I manually replaced [[++site_url]] in my template’s <base> tag, everything works fine.

Now, I can work around this problem by creating my own chunk called [[$site_url]] and putting the correct URL in there, then using that chunk wherever I have been using [[++site_url]] (which is exactly what I’m going to have to do in order to continue development). However, I really want to figure out why this is happening! I can post any relevant information needed to track down the problem.

Any suggestions would be much appreciated.

Just making sure here... did you clear your site’s cache and update the core/config/config.inc.php file as per instructions here:
http://rtfm.modx.com/display/revolution20/Moving+Your+Site+to+a+New+Server ?

Quote from: Everett at Jun 30, 2011, 02:33 PM

Just making sure here... did you clear your site’s cache and update the core/config/config.inc.php file as per instructions here:
http://rtfm.modx.com/display/revolution20/Moving+Your+Site+to+a+New+Server ?

Yup. I even waded into core/cache and deleted everything manually, just in case

I’ve checked, double-checked, and triple-checked core/config/config.inc.php - but it’s right, as are its cousins in manager/, connectors/, and root/ (I had a problem when transitioning the site and had to edit those manually). Besides, how could config.core.php change the base domain information? Isn’t everything in that file relative to the base domain?

The first time I re-ran setup there was an error (which I should have copied) referring to some kind of xPDO class not being found. However, when I re-ran it without changing anything, it completed properly.

BTW, it’s MODx 2.1.1 on Debian/Apache with MySQL 5.1.49-3 and PHP 5.3.3-7.

Hmm... well, a simplistic workaround would be to create a chunk to contain your site’s URL for use in your base tags... that’s what I used to do for Evo. I’m not sure why the site_url is sticking for you.

Quote from: Everett at Jun 30, 2011, 03:47 PM

Hmm... well, a simplistic workaround would be to create a chunk to contain your site’s URL for use in your base tags... that’s what I used to do for Evo.

Yeah, mentioned that in my original post

Since then, however, I’ve discovered that it’s not that simple. For one thing, Visioncart, which I am using to build an online store, apparently uses [[++site_url]] in constructing some of its URL’s, like the checkout pages.

Try: [[!++site_url]]

Thanks, Shaun. Sorry to waste everybody’s time.

Turns out, another member of the team was experimenting with multiple contexts and had created ’http_host’ and ’site_url’ parameters for the Web context pointing to - guess where - www.example.com. I have never messed with context settings before, so I wasn’t aware that was possible. We learn something new every day...

Quote from: kenquad at Jun 30, 2011, 04:10 PM

Turns out, another member of the team was experimenting with multiple contexts and had created ’http_host’ and ’site_url’ parameters for the Web context pointing to - guess where - www.example.com. I have never messed with context settings before, so I wasn’t aware that was possible. We learn something new every day...

Yep, definitely possible. modx.com actually has specific site_url and http_host settings on the web context. Glad to hear you figured out the issue.