Symphony.

CacheLite probably doesn’t take the domain into account when it caches the page. Take your home page for example, CacheLite probably just sees this as “Home” regardless of the domain used, therefore caches the page and serves the same to both (which technically is correct seeing as it’s the same Symphony build).

To rectify this you could modify CacheLite — find the code where it builds the unique identifier to the page (it probably hashes some environment variables together) and add a reference to the domain name in there. This way, it’ll create two separate cache files for each page — one for each domain name.

…find the code where it builds the unique identifier to the page (it probably hashes some environment variables together) and add a reference to the domain name in there.

You should be able to do change line 26 of the extension.driver.php to concatenate the server name and the requested URI. Something like:

$this->_url = $_SERVER['SERVER_NAME'] . $_SERVER['REQUEST_URI'];

Wouldn’t it be better to skip the domain part and serve the same data for all domains? IF I was to modify CacheLite to include domain and as you say create 2 cache files.. Theoretically I would have 2 different versions of a page live at a given time no? i.e if a page is accessed from .co.uk it is cached but if the page is later accessed through the .com domain it has not been cached yet and could potentially contain outdated data? just a thought?

If there was a means to skip the domain part this would make it a lot neater in my opinion.. but I don’t know as much about the backend workings as you guys so will take any advice to counter my theory?

@Makenosound: Thanks for pointing this out.. I had started adding my own $_SERVER['SERVER_NAME'] reference underneath the this->_url string.. but alas this wasn’t gonna work so thanks for the simple solution! Still worried different content would be served to the both caches at different times though! What do you guys think?

F I was to modify CacheLite to include domain and as you say create 2 cache files.. Theoretically I would have 2 different versions of a page live at a given time no

Yes, you would have two versions of the same page if you were to modify the driver file. The out-of-the-box matching for CacheLite ignores the domain so if you want that you don’t have to change anything.

I think you’re confusing the idea that your two domains have the same content on them. CacheLite caches and serves the rendered output of the page, so when you serve it from your .co.uk domain the rendered HTML is different that the .com even though the URLs remain the same. If you want to still have the $root param evaluated then you need to reprocess the output somehow.

If you’re worried about different versions dropping out of sync, you could look forcing the cache expiry on both versions at the same time. I do this on the http://moadoph.gov.au/ site where there are four versions of the site (different colours).

The out-of-the-box matching for CacheLite ignores the domain so if you want that you don’t have to change anything.

I think this is where the trouble started. If Cachelite is enabled and (not modified driver) I see the .co.uk reference on all links that have $root or $workspace even when I’m on the .com domain reference.. When Cachelite is switched off, all is normal but I suffer from load times of my DS.. so I really like what Cachelite is doing but weirded out by the out-of-the-box extension seemingly caching domain info even though it shouldn’t..

Adding SERVER_NAME to line 26 in the driver file has made the reference to the correct domain name return.. and I’ll see how it goes with the cache.. currently set to 3600 seconds to see how it effects things!

tally ho!

seemingly caching domain info even though it shouldn’t..

Just to be clear, it isn’t caching the domain, it’s caching the output. So when your visitor goes to http://foo.com/about/ the value of $root is being passed as http://foo.com but when they go to http://foo.co.uk/hello/ it’s being passed as http://foo.co.uk.

You could get around this by removing all reference to $root in your templates and instead using relative URLs or absolute / references.

That’s what I was thinking of doing so thanks for confirming what I had in mind! :-)

Issue resolved :)

Uhh One more thing.. If an entry is set to expire at a certain date i.e Not show on the front end.. theoretically it will still appear as the cache is not updating by itself over a 24hr period no?

I have ParamFilters:

'84' => 'equal to or earlier than {$today}',
'85' => 'equal to or later than {$today}',

So if the DS is chached along with the page, am I right in thinking that until someone accesses the page this kind of functionality will not be triggered?

What length is your cache expiry?

3600 seconds at present. so would this ensure that it would auto refresh every hour?

Yep.

Coolio :) Fangs a lot ;-)

CacheLite updated to version 1.0.6 on 8th of March 2010

CacheLite updated to version 1.0.7 on 12th of May 2010

Only minor changes to keep things up to date. Saving preferences through the administration interface is currently broken and requires this patch to be applied to the core (should be included in Symphony 2.0.8), though you can change them manually in /manifest/config.php.

I applied the patch but I’m still getting a conflict between this and the Subsection Manager extension.

I applied the patch but I’m still getting a conflict between this and the Subsection Manager extension.

Yup, the patch for the core was to do with the non-saving Preferences bug. I’ve narrowed down the conflict between CacheLite and the Subsection Manager and posted it up on the Subsection issue tracker on Github. There’s a fix there that Nils will likely roll in.

Outstanding, thanks for the heads up! I was a bit heartbroken when I realized this and Subsection had a conflict as they both are must-haves in my mind.

Max’ fix has now been integrated into the Subsection Manager repository.

Nice work, Nils.