#009126: Static cache uses old cache to create new cache on publishing

I can confirm both the problem and the fix.

#249787 by Ole Morten Halvorsen on October 11th, 2006 [Permanent Link]

An additional bug in the same file:

function alwaysUpdateURLArray()
{
        return $this->AlwaysUpdateArray;
}

It should be <b>$this->AlwaysUpdate</b> instead of <i>$this->AlwaysUpdateArray</i> (according to the constructor).

You should also define $AlwaysUpdate at the bottom of the class.

#249788 by Kristof Coomans on October 12th, 2006 [Permanent Link]

There are still some other bugs in the static caching:

if ( strtolower( substr( PHP_OS, 3 ) ) == 'win' )

should be:

if ( strtolower( substr( PHP_OS, 0, 3 ) ) == 'win' )

Static cache is also created for nodes not matching any entry in the CachedURLArray[] setting. eZContentCacheManager::clearObjectViewCache calls eZStaticCache::generateNodeListCache, but eZStaticCache::generateNodeListCache does not check if the paths have to be cached or not (it uses the storeCache function instead of cacheURL).

Also note that the static cache class is called from both eZContentCacheManager::clearObjectViewCache and eZContentCacheManager::generateObjectViewCache, so almost the same caching is performed twice (increasing the page response time).

#249789 by Kristof Coomans on October 13th, 2006 [Permanent Link]

Kristof's comment about alwaysUpdateURLArray() might be valid

However, The issue in the initial bugreport is invalid. Or more a documentation issue.

from doc/features/staticcache.txt (3.6) (also http://ez.no/download/ez_publish/changelogs/ez_publish_3_6/new_features/static_caching_of_content)
"- HostName is the host on where the pages can be viewed normally. The static
cache feature uses this to retrieve the generated content to store as cache
file."

Here, HostName should point to a virtualhost which doesn't serve static cachefiles. "Normally" means without static cache. This is not easy to understand from the text, I give you that.

We don't want to delete the static cachefile before a new one is generated. This is because it will then be a small time period (1sec-15 sec, dependent on system setup and load) where pages has to be served dynamicly and not from the static cache

#250129 by Vidar Langseid on November 6th, 2006 [Permanent Link]

Thanks for the info Vidar. I'm sure I'm not the only one who didn't got the point that a non-caching virtual host is required to make this working with the current code. Correct me if I'm wrong, but doesn't this require a lot of work to keep the eZ publish configuration files into sync (from the live vhost to the non-caching vhost)? Or how should this be done?

Is it possible to have an INI setting to enable my patch, so static caching can also be used on sites where adding a new virtual host is not an option? It would ease the static caching configuration a lot.

#250230 by Kristof Coomans on November 14th, 2006 [Permanent Link]

You will find my mods to static caching in the attachment (based on version 3.8.6).

Another bug or undocumented feature :-) ->
old url aliases also get cached statically, but they actually should be redirected with a "moved permanent" HTTP header.

#250545 by Kristof Coomans on November 24th, 2006 [Permanent Link]

- Attachments: » ezstaticcache.php (My modifications to static caching)

The problem with old url's being cached was first reported mid 2005:

http://issues.ez.no/6792

Also...

http://issues.ez.no/7982
http://issues.ez.no/7983

• /me whistles a little song to himself *

...furthermore I am fairly sure that I have previously had the static cache operating where the hostname is the public facing site. I too always assumed that this was the way it should be set up. No time to test now though, unfortunately.

#250673 by Matthew Carroll on November 29th, 2006 [Permanent Link]

Hello, will those bugs be corrected in 3.8.7 and 3.9.1 ?

#251833 by Vincent Lepot on March 6th, 2007 [Permanent Link]

The documentation has been updated, which is good, but could you also please integrate the fixes regarding old URLs? Patches have been sitting around for months!

#252297 by Peter Putzer on April 24th, 2007 [Permanent Link]

As for the initial issue reported here, I propose to use a different approach:

The HTTP calls will be made with a special User Agent HTTP header ("eZ Publish static cache generator"). If it's this user agent that makes the request, we won't serve from the static cache:

RewriteCond %{HTTP_USER_AGENT} !^eZ\ Publish\ static\ cache\ generator$

This allows to re-use the same host in a very easy way.

#255854 by Kristof Coomans on February 29th, 2008 [Permanent Link]

Confirmed, in the case that you only have one hostname.
This could also be seen as an enhancement, though.

#256157 by Gunnstein Lye on March 27th, 2008 [Permanent Link]

Fixed by implementing Kristof Coomans user agent based solution.
See documentation in doc/features/*/static_cache_user_agent.txt

Fixed in
stable/3.9 (3.9.5) rev. 21623
stable/3.10 (3.10.1) rev. 21622
stable/4.0 (4.0.1) rev. 21621
trunk (4.1.0) rev. 21620

#256158 by Gunnstein Lye on March 27th, 2008 [Permanent Link]

Gunnstein, I agree with you about defining USER_AGENT as a consts.

However, when referring to the const the scope needs to be defined :

-                            $content = $http->getDataByURL( $fileName, false, USER_AGENT );
+                            $content = $http->getDataByURL( $fileName, false, eZStaticCache::USER_AGENT );

self::USER_AGENT should also work

#256527 by Vidar Langseid on May 2nd, 2008 [Permanent Link]

I will look into the documentation requirements.

#272260 by Geir Arne Waaler on October 31st, 2011 [Permanent Link]

The issue is fixed and documented. I move it to Closed.

#272657 by Geir Arne Waaler on November 10th, 2011 [Permanent Link]