A new Extension, “CacheLite” is now available for download. Comments and feedback can be left here but if you discover any issues, please post it on the issue tracker.

Allows for frontend caching using the CacheLite library. It should help lighten the load on the server if you’re serving mostly static content. You can set the lifetime of the cache on the preferences page.

Get the latest version from GitHub:


Caching is done on a per-URL basis. To flush the cache for an individual page simply append ?flush to the end of its URL. To flush the cache for the entire site you just need to append ?flush=site to any URL in the site. You must be logged in to flush the cache.

You can also selectively flush the cache when new entries are created or an entry is updated. Updates through both the backend and frontend Events are supported. More usage details are available in the README.

You can exclude URLs from the cache by adding them to the list of excluded pages in “System” - “Preferences”. Each URL must sit on a separate line and wildcards (*) may be used at the end of URLs to match everything below that URL.

Excluded pages are assumed to originate from the root. All the following examples will resolve to the same page (providing there are none below it in the hierarchy):


Note that caching is not done for logged in users. This lets you add administrative tools to the frontend of your site without them being cached for normal users.



Thanks to some great work from Nick Dunn, version 1.0.2 adds the ability to flush the cache selectively from either the front or backend of your site.


  • Fixed an error in the calculation of the cache ID where GET parameters weren’t included.


Due to changes in the Symphony core, version 1.0.0+ of the CacheLite extension only works with Symphony 2.0.6+. Versions prior to 1.0.0 are compatible with Symphony 2.0.1-2.0.3. If you’re using 2.0.4-5 then you should upgrade :p

Thanks alot for that extension! Would come in very handy if i could get it to work - only i'm getting all my cached pages delivered as "text/plain"-type instead of "text/html" when enabling it within the official 2.0.1-Release - any ideas what's going wrong?

That's odd. I can't seem to replicate the problem on my end, nevertheless I've updated the extension so it explicitly serves any headers that were attached to the original page. Just git pull to update.

Let me know if you're still having problems.

Problems gone... seems to work like it should now - thanks alot!

Great initiative, some questions though;

So this caches only actual pages, or also content genrated by url-param filtered datasources?

Setting the cache period to 30 minutes means that if a page is visited, and it is revisted within these 30 minutes, it will still offer the same snapshot, but if its revisted after these 30 minutes, a new snapshot will be made? So if a page isn't viewed less then 30 minutes ago it creates a new snapshot. And the counter is reset each time a new snapshot is made, not on each visit? So this is the same way the dynamic datsources are cached?

When the content of such page is changed because of changed entries, the cache is not automaticly renewed? Only the time mechanism renews? So your changes have a delay of the set time, at worst (when pae was visited right before the change), at best (when page hasn't been visted for 30 minutes) you have no delay when you visit the page after the edit?

I have a frontpage on which 3 pictures from an external feed (dynamic datasource) are pulle dand then a random pic is showed on pageload (xslt template). When this page is cached, it will mean I lose the randomness? or rather delay the randomness with 30 minutes?

Any news on the exclude page? I have one frontend entryform with preview displayed next to it, ofcourse this would need excluded, although I guess I could append ?flush to the link showing that page. But then when i hit save entry, the page will relaod without this append and cache anyhow. Any suggestions?

Pear is needed, will it work on php5.2 out of the box? or should I check my phpinfo?

Any link to official documentation on CacheLite library?

  1. Yes, it caches the rendered output of the page. So your Symphony page executes, the events and data sources run producing XML, the XSLT processes and generates the HTML. This HTML is then cached, so future requests to your page don't run the data sources again.

  2. Yes, the same theory as the Dynamic XML data source. Setting a 30 minutes expiry time means that the first visitor to the page will see the normal un-cached version (which is the point at which the cache is generated). Subsequent visits within that 30 minute period will be served the static cached version. If nobody visits the site for an entire day, the cache won't self-update every 30 minutes (because nobody is viewing pages); but the next visitor to the site will trigger the update.

  3. No, the cache works independently of your updates to content. If someone has just triggered the cache and you make an update to your content, it will not be visible until the cache refreshes in 30 minutes.

  4. Yes, the randomness will be lost since the page output is cached in its entirety. Your XSLT will only run max once every 30 minutes. To achieve the random nature with caching you would need to use JavaScript to manipulate the page in the user's browser, since the page returned from the server is always the same.

  5. No idea :-)

  6. No idea!

  7. Cache_Lite looks like it's the documentation.

I'd like to add that I've been working on Data Source level caching. Rather than caching the entire page, specific data sources can be cached (using the same time limited expiry mechanism). Many of my sites have things such as a "Logged in as {$name}" at the top meaning the entire page can't be cached. It won't replace CacheLite; more an alternative when you need finer granularity, perhaps on pages that you have chosen to exclude from using with CacheLite.

Thanks, as for random pictures, each time the cache is refreshed, it loads the page, and each time it loads the page a different picture is shown. So I would argue that this extension only delays the randomness, but still, every 30 minutes, when clicked you get a random picture. ?

Thanks for answering most of those questions @nickdunn :) As for the rest:

  1. Hopefully I'll get a chance to add in the exclude list functionality in the next couple of weeks. Probably won't get to it first week of May at the earliest :/

  2. I'm pretty sure PEAR isn't actually required. The CacheLite library sits almost entirely separate to PEAR barring one error logging function which I think I disabled.

Re: random pictures: newnomad, your assumptions are correct. As the extension caches the output of the page it'll still execute and datasources with random sorting when writing the cache. So each time the cache is refreshed you'll get a random image.

Added the ability to exclude URLs from the cache; works pretty much like the white-list from the JIT Image Manipulation extension. If you come across any bugs/problems, let me know.

Hooray, the ability to exclude URLs means performance increases for all websites with some static pages. Thanks, Max! To maximize effectiveness of caching, perhaps the EventFinalSaveFilter Delegate can be used to update cached files only for pages that have entries/fields that just have been updated.

@Nickdunn, have you made any progress on Data Source level caching?

Progress, yes. But not enough for it to be released as a stable piece of code. Unfortunately it requires modifications to the core itself which we haven't yet sent to Alistair for approval. I'm hoping that it may be included in Symphony 2.1, perhaps.

I've started work on a Cache Manager extension which provides functionality such as:

  • seeing which DSs have been cached and their static XML files, allow user to purge the cache
  • seeing which Dynamic XML DSs are cached, allow user to purge the cache

And potentially feedback for the CacheLite extension also — allow users to configure them or purge them through the same UI.

Well, the functionality you mention definitely sounds worth the wait.

Max, where exactly do the cache files are written? I am testing(locally) and can only see some differences in loading (firebug) but would like to understand whats going on behind the scenes. I see it is set to /tmp/ yet no files appear there (I assume the tmp in manifest)

@newnomad: The cache files should be written to /manifest/cache/ alongside any other cache files (images, dynamic DS, etc).

that directory is completely empty on my local install, and I have dynamic DSes, and global write permissions.... anyone has this to? How can I debug and find the reason why it doesnt write in there? Local install macports.

I learned here that the dyn DS are stored in tables. My cache dir stays empty. Could it be that your code has a bug? I have read in it that cache is stored in /tmp/ ..... Did you sucessfully ran it on macports or mamp local install?


I'm getting that as well, no new files written to /manifest/cache. Wondering if its a permissions issue? If you've got a local install, look at your php log.

update: Opening up the permissions for /manifest led to cache files being created, so my problem was permissions.

ashooner, no errors in my log (only favicon missing), but my acces log does show; - - [22/Apr/2009:16:16:04 +0200] "GET /edit/ HTTP/1.1" 200 7242

alot, the 200 means what exactly?

Maybe leopard file info openeing of permissions is not enough, bc symphony is owned by apache or something?


200 is the http code 'OK' so that is probably not related. I've never had trouble opening permissions through Finder, but you can try this:

If you want to test the permissions, you can totally open up you /manifest (probably not wise once its up on the server)

  1. Open Terminal

  2. type 'chmod 0777 ' (space at the end)

  3. Find your /manifest folder and drag it into the terminal window (should put a text string of the file location of /manifest after the command above)

  4. hit return

if you don't get an error message, then your manifest folder has totally open permissions. Like I say, if the caching works after this, you'll still need to determine what your perm should be on your webserver, but at least it helps with troubleshooting.

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details