Symphony.

CacheLite updated to version 1.1.3 on 3rd of July 2011

It seems that I can only make comments when logged in

That's a bug. The above update should fix it. I've made it so if there's $_POST the cache will be ignored. You'll still need to include the filter in your event if you want to clear the cache, but the entry should get saved regardless.

Thanks, comments are already working.

However, I'm getting this error every time I try to access one of the pages: An error occurred in [...]/extensions/cachelite/extension.driver.php around line 364

Strange. I can't replicate that problem. That line deals with parsing the page XML and storing section/entry references for clearing the cache — perhaps there's some invalid XML. If you disable the cache does that page load?

Nevermind... The problem was in the data source.

Fantastic extension Max!

Finally started adding it to some sites in development today. The speed difference is astounding. Very easy to manage page exclusions too.

My little VPS should be able to handle a lot more sites now :)

I got a few questions regarding this extension:

1. How do you handle maintenance mode (symphony 2.2.1, maintenance 1.4)? I tried to add /maintenance/ to the exclude list since the url is "redirected" to the root I always need to flush the cache after disabling maintenance mode.

2. Is it normal that also logged out users are able to flush the cache?

How do you handle maintenance mode?

Short answer: I don't. I don't use the Maintenance Mode extension, so I've never bother to check its compatibility with CacheLite. It shouldn't be hard to add in though — I don't have the time right now, but if you log an issue on Github I'll get to it eventually.

Is it normal that also logged out users are able to flush the cache?

That's a sort-of bug. As the token for the cache takes into account the $_GET params, it's recognising http://foo.com/bar as distinct from http://foo.com/bar?flush. Rather it's generating a new cache for the ?flush URL, not clearing the cache for the old one. Feel free to log an issue for this as well — the behaviour should probably be a little different.

I just installed this extension,
I checked the checkbox 'Expire cache when entries are created/updated through the backend?' in the preferences...

Creating a new entry works fine and updates the cache, but updating the entry will not refresh the cache file...

is this a bug?

(?flush works fine and time expiring too)

EDIT: deleting an entry does also no update the cache, not sure if this functionality already exists though.

Thanks!

Lately, while developing I started getting the error (about once per hour on the staging server - never locally)

I suspect it could be related to this: http://getsymphony.com/discuss/thread/83943/ – an issue I'm still trying to solve with the hosting company.

Symphony Recoverable Error

Argument 1 passed to DOMXPath::__construct() must be an instance of DOMDocument, boolean given, called in /web/sites/site/test/symphony/lib/toolkit/class.extensionmanager.php on line 559 and defined /web/sites/site/test/extensions/cachelite/extension.driver.php line 365

360     }
361     
362     # Parse any Event or Section elements from the page XML
363     public function parse_page_data($context) {
364         $xml = DomDocument::loadXML($context['xml']);
365         $xpath = new DOMXPath($xml);
366         
367         $sections_xpath = $xpath->query('//section[@id and @handle]');
368         $sections = array();
369         foreach($sections_xpath as $section) {

If this rings a bell about something you've seen, I'd be curious to know. Thanks for any eventual input

J

Ok, after the hosting company put the site on a different server, the issue have stop happening. So it was likely something on a lower level, and not symphony related.

J

Hello there again, I've just tried launching a symphony site on a new provider running on a virtual server, and I ran into another peculiar thing that I'm not sure how to start solving.

After each cache-flush, the first cached response (second after the first response), I get truncated html, it's cut off at approximately the same place every time. After a reload, everything is fine.

Anyone seen something similar?

cheers, J

Hmm weird. This could be down to an incorrect Content-Length header being set. Try commenting out the two lines in the CacheLite extension.driver.php that set this header and see if that makes a difference. Is it a multilingual site with weird characters perhaps?

Regardless if I put the header there or not, it was never sent from the server. Then I realized it was running on FCGI, and i had the option to switch to mod_php, then content-length is sent as it should and it seems to work fine

thanks a lot for the hint

J

I'm currently updating the CacheLite extension for Symphony 2.3 (updating to the latest CacheLite library as well and cleaning up the code a little bit).

Seems the method used to expire cached pages when entries are created or edited doesn't work reliably.

For example, it doesn't reflect changes in entries linked via Select Box Link or Subsection Manager or doesn't count in changes to the page itself (adding or removing datasources and stuff).

@nickdunn I can't really think of a simple and elegant way to achieve this, but I'm thinking about cleaning the cache entirely if anything in the backend changes. Maybe it's not as performant, but would prevent any kind of strange side effects and make this extension more bulletproof.

Or removing the backend delegates entirely.

Any bad feelings about this?

My thought would be to leave this as it is, as those are relatively minor problems. If a developer is changing pages then purging a cache manually should be obvious. To solve the SBL you could look up into the related table and purge those rows too, the data is there to query. Perhaps you could simply add a Purge button to the Preferences page allowing a manual delete of everything. The logic as it stands works in most situations I think.

For an unknown reason, the link to v1.2 from symphonyextensions.com (in Compatibility view) is broken. It has an extra underscore _ before cachelite in the URL.

Fixed! My bad.

jensscherbl: I agree with Nick, it's more complex, but there's no reason you couldn't include SBL or Subsection related entries in the cache expiry. You could also add your brute-force kill-the-whole-cache solution as an preference though, I can see situations where it would be useful.

You could also add your brute-force kill-the-whole-cache solution as an preference though

+1