This site has been archived and you can no longer log in or post new messages. For up-to-date community resources please visit

eZ Community » Forums » Developer » conditional caching from within...

conditional caching from within cache-block

conditional caching from within cache-block

Thursday 30 January 2014 11:28:14 am - 3 replies

Hi, I have a rather odd situation involving an unreliable remote server.

We run a custom module that fetches some data from a remote location via curl, this can either 1) work, 2) fail producing an error code, or 3) timeout returning no error.

The operation is costly timewise so the call and handling of return data from within the template is enclosed in a cache-block construct.


Here the problem arises that if the returned data is either an error or a timeout, the block is cached regardless, meaning that even if a short time later the remote resource is returning the 'correct' information, the cached copy shows the stored 'broken' information.

Ideally we'd like to be able to check the returned content for some condition, and if this is not met, then disable the cache block that's been assigned to encapsulate the call.

Simplest solution I can see would be to move the call to the remote server outside the cache-block, but as I say, it's a costly operation run very frequently over multiple pages so this isn't viable.


Is there a method to cancel a cache-block from within itself? something like this:

{cache-block keys=$params expiry=1800}
  {def $result = expensive_call()}
  {if eq( the test_for_good_result(), false )}
    {* break out of the cache block somehow; or tell it to ignore this copy for caching? *}
    {* continue with further costly operations *}

Thanks in advance!

Thursday 30 January 2014 2:58:47 pm


To call some external resource directly in your template, even if such function you mention existed, is never a good idea.

You need to sync external data independently (e.g. by a cron script which saves the data in some local cache) and then just include the cached data locally.

Error handling is then done in the script, template is light and only reads the specified cache file.

Your site will not crash or timeout because of some external problem

Modified on Thursday 30 January 2014 3:00:03 pm by Ivo Lukač

Thursday 30 January 2014 5:39:08 pm

Hi Ivo, thanks for your reply, I would agree that separating the remote calls in general would be a good idea, however unfortunately I do not think it would be a viable solution in our circumstances.

The resource we pull from is vast and varies between objects that will only update every half year or so, mixed with others that update in real time. The eZ cache expiry length as well as the cache expiry at the external resource are already points of contention, introducing another delay and storage requirement would be most undesirable.

Thanks again though, in most situations it would definitely be the way I'd go... anyone have any other suggestions?

Tuesday 04 February 2014 9:58:07 am

If you use the ggwebservices extension for your calls to remote servers, you get basically the same API which you can use in template fetches and in php code.

This way it would be easier to move your caching-block logic to implement the do-not-cache-on-error part


You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu

Proudly Developed with from