Forums / Suggestions / Static Cache created on demand

Static Cache created on demand

Next topic

Author	Message
Geraint Edwards	Monday 04 July 2005 2:47:21 am First up - Static Caching is a great idea and, subject to a few minor problems with siteaccess ini files, works brilliantly. However, publishing items which feed into a number of AlwaysUpdateArray entries can be very painful, especially if there are a number of translations to generate, as the static caches for all the different URLs (some of which may not even be valid) are generated. Again when an editor is adding a number of article/images etc. there is no point in updateing the static cache until they are finished. Why not have the option of creating static caches on demand? In other words - publishing removes the old static cache files but doesn't create the new ones. Then the first time a request is made for a page (which should have a static cache, but doesn't) is made, the static cache is updated with the results of this request. Geraint
Geraint Edwards	Monday 04 July 2005 2:52:34 am In the same vein - there is probably no point creating static caches for "archived" versions of articles etc. If an 'on demand' approach was implemented then the static cache for such material would only be created if it was accessed (which it may never be!).
Frederik Holljen	Monday 04 July 2005 5:37:48 am This should be pretty simple. It is just a matter of adding a settings that controls if publish should create static cache when publishing. However, we opted not to make it this way because it sort of defeats the point of having the static cache in the first place (high traffic sites, no way to handle the additional load that simultanious requests to a new page can lead to).
Georg Franz	Monday 04 July 2005 5:56:51 am Hi, I suggest to introduce a feature where you can specify the classes for the static cache. (example: I've an article, users can write comments. I show all comments at the end of the article, they are not clickable, there is no full view for the comments. So, there is no need to make static cache pages for each comment - full view.) Another nice feature would be - as already mentionend somewhere in the bug reports by someone else - a possibility to specify the static cache depth by path for wildcards. Example: CachedURLArray[]=/news/technic/;5 CachedURLArray[]=/forum/;3 In that case the 1st path should be cached till a depth of 5, the 2nd one should be cached till a depth of 3. -) Moved, renamed pages: If you move or rename a page, a redirection or "404" page at the old location should be placed. Current behaviour: The static cache file is stored at all places. (Old locations and new location). -) Static cache generation should be deferred to a cronjob. (Like the subtree cache block feature. Best wishes, Georg. -- http://www.schicksal.com Horoskop website which uses eZ Publish since 2004
Geraint Edwards	Monday 04 July 2005 6:16:18 am I'm not suggesting that this should be the default/only behaviour Frederik. It should be toggled by a switch in staticcache.ini. The overhead on the server should be less than the current publish driven cache generation and makes administration more tolerable. I've written a few extra functions that implement this type of behaviour (works perfectly on my setup): 1. Taking the $templateResults from index.php 2. If !POST , staticcache and CreateCacheOnDemand are enabled 3. Pass $templateResults by reference to ezstaticcache 4. Use 2 new routines cacheURLWithResults and storeCacheWithResults (based on their namesakes) to store the results. What is the best way to make these available for testing/comment?