Symphony.

Have had some thoughts about this extension:

When querystring parameters are added to the mix (?pg=1 for example) the cache ID (using the getCurrentPage()) will always resolve to the page URL without the querystring parameters. What I think this means is that if I have page /articles/ cached, if I have pagination and go to page one /articles/?pg=1 then this overwrites the cache file for the original /articles/ page. Max, is that right?

In some cases I’ve found the ?flush method to be insufficient. In the example of a blog post with a comments form, I need to flush the cache when a new comment is posted. The flush method only works when the user is logged-in, not for frontend users. Similarly, when setting cache times high (on high-load sites) clients editing content through the backend (who don’t have a technical grasp of how caching works) have wanted updates to propagate instantly.

Therefore I’m suggesting a few changes which might give more control over how a cache is flushed. I have made modifications such that in addition to the flat text file storing the rendered HTML of a page, an entry is added into a cache table storing a list of any Section and Entry IDs that appear in the page XML. I’m suggesting adding an event Filter to the extension to “Flush CacheLite page cache” which would:

• when editing an existing entry, search the cache table for all pages which display this entry and flush their cache
• when creating a new entry, search the cache table for all pages which have Data Sources pulling from this section and flush their cache

The same functions could be triggered by delegate calls in the backend so that page caches are flushed when editing content here.

In this way, cache times could potentially be infinite (or extremely high) and content creation/updates trigger the expiry/flushing. I’m half way to implementing this, but wanted to know whether you’d accept this as an update to your existing CacheLite extension or whether I should add it as an Advanced CacheLite extension. I do rather like the simplicity of the original.

When querystring parameters are added to the mix (?pg=1 for example) the cache ID (using the getCurrentPage()) will always resolve to the page URL without the querystring parameters.

Blergh, can’t believe I missed that all this time—a result of my aversion to URL parameters I imagine. Thanks for picking it up, Nick.

I’ve updated the extension (1.0.1) so that it determines the cache ID based on the $current-page parameter rather than the getCurrentPage() function and thus it should include all URL parameters as part of the cache ID.

In some cases I’ve found the ?flush method to be insufficient

I agree, it’s not an ideal way of managing the freshness of pages. I’ve certainly had the same issue where a client has forgotten to clear the cache and sent me some panicked emails.

Your solution sounds good to me. I’d like to keep this extension as simple as possible for people to implement but I don’t see the changes you’re proposing making it any more complex.

Nice one mate. Did you mean the $current-url parameter?

I’d like to keep this extension as simple as possible for people to implement but I don’t see the changes you’re proposing making it any more complex.

I think they add a layer of complexity that others might not be interested in. I like the simplicity of the existing CacheLite extension because you can just throw it up and it just works. I’ll send you a pull request when I’m done and you can make your own mind up. I’m happy to maintain as a separate extension, but it’ll be your call. Expect something soon!

Nice one mate. Did you mean the $current-url parameter?

Actually, I meant the $current-path parameter :p Stupid words.

I’ll send you a pull request when I’m done and you can make your own mind up.

Coolies, sounds great.

Coolies, sounds great.

Pull requested for zis.

FYI: I’ve integrated Nick’s changes into the main CacheLite repository on Github so the extension now allows you to 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 details on usage are available in the CacheLite README.

All credit to Nick for this addition. It should make CacheLite a much more powerful extension for you (and your users).

Woop! Cheers Max.

I should add that these new updates are entirely optional. By default CacheLite will work just as before. To enable this new flushing functionality you need to enable the checkbox in the System > Preferences.

Nice one mates.

You can also remove cache files using your FTP client: navigate to /manifest/config and remove the files named as cache_{hash}.

It should be /manifest/cache/, right?

Good spots.

CacheLite updated to version 1.0.3 on 9th of December 2009

Changes

• Subscribe to the Delete delegate to flush pages when an entry is removed (delegate not included in Symphony 2.0.6) (Nick Dunn)
• Fixed bug introduced in 1.0.2 where caching was occurring for logged in users
• Fixed bug introduced in 1.0.2 where ?flush was being included in the cache ID

CacheLite updated to version 1.0.4 on 17th of December 2009

Changes

• Added support for flushing the cache on a per-URL basis during Event execution

CacheLite updated to version 1.0.5 on 17th of December 2009

Changes

• Changed intercept_page delegate to FrontendPageResolved. Should now execute immediately after the Page is found, but before anything else happens (speed FTW).
• Because of the change above, headers are determined manually (as with normal pages). Supported types are HTML, XML and JSON.

Any idea if this would work in a 2.0.4 install? it says 2.0.6+ in the git but was just wondering?

Can’t say for sure — you could try it and see. Most likely 2.0.4 is missing some page rendering delegates CacheLite requires.

Ok I’ll try it out now!

Hi, I try this extension on 2.0.6 but it returns this error:

Fatal error: Cannot access protected property FrontendPage::$_headers in /extensions/cachelite/extension.driver.php on line 119

could someone help me?

@pngised: Do you have the latest version of CacheLite? If not, what version are you running?

@Makenosound: I was sure to have the latest, but I downloaded it from github link and looking better at it I realize the version is the 0.1.6 Look at these: github link

I was looking for a zip package but I’ll go through github…

Thank you

I downloaded it from github link and looking better at it I realize the version is the 0.1.6

Ah, right. I’ll make sure to tag the releases on GitHub and upload a .zip to the Symphony site from now on.

Hello

Cachelite seems to be causing a funny domain caching when 2 or more domains point at a symphony install!

I have a .co.uk where symphony is installed and a .com domain mapped to the .co.uk site..

When Cache lite is enabled (Cachelite 1.0.5 and a 2.0.4 symphony install) and I enter the site through the .com url, I see the .co.uk on all the subsequent links in the nav and everywhere that has {$root} or {$workspace} in the link.

Anyone else experience this or is it down to my 2.0.4 install?