le Fri, Jul 09, 2004 at 10:25:54AM -0400 par Sylvie Greverend :
> > > Tiki by default takes advantage of Smarty's caching. >
> > I have the impression that Smarty's caching is questionable at the
> > moment. Is that the case?
> So far I know, tiki is not using the caching feature from smarty (except for
> the user menus). The templates are only compiled. (the cache goes one step
> further by resolving the variable subtitution)
> Perhaps, it will be a good idea to evaluate the smarty caching.
> BTW: MikeW is developping a tiki to html compiler
- I made test with enabling caching, it won't work out-of-the-box and
requires that cache-id are built depending the cached environment,
that means, include a lang-perm-userpref thing in cache file name so
that pieces of pages cached for admin don't appear as is to anon (nor
in an unexpected language, but that trick we already have in
That means a huuuuuge amount of cache, more interesting if your users
are intensive and few, than if they are just visitors and plenty.
It is probably possible that a cache is used only for anon user, in
case of one-time-visitor intensive traffic, though.
Anyone around tried such thing ?
From: David R. Newman <d.newman@qu...> - 2004-07-09 17:01:59
> - I made test with enabling caching, it won't work out-of-the-box and
> requires that cache-id are built depending the cached environment,
> that means, include a lang-perm-userpref thing in cache file name so
> that pieces of pages cached for admin don't appear as is to anon (nor
> in an unexpected language, but that trick we already have in
For most pages, since the permissions depend on the groups, not the
individual user, the output cache just needs to keep track of
the groups and the language. E.g.
$mid = $smarty->fetch('tiki-index.tpl',"$page|$group1|$group2|$lang");
Or at least that is true if you do not cache the whole page, but
each part of a page (i.e. each module separately, the top bar,
the bottom bar and the middle). Then it won't be affected by
users choosing different modules to see.
The real advantage of output caching comes when you set a particular
page or module to be cached for ever until the cache is deleted;
and write into any code that updates it a cache delete instruction.
That would mean that except when lots of updates are being made,
everything comes out of the cache.
I don't see space as a problem, as what is being cached is small
bits of HTML.
Of course, the caching needs to be tested and timed. There are
probably some pages that take much longer to generate than others.
Those should be the target for caching. You can turn caching on
only for forums, or only for modules, or whatever is slowest.
Dr. David R. Newman, Queen's University Belfast, School of
Management and Economics, Belfast BT7 1NN, Northern Ireland (UK)
Tel. (direct) +44 (0)28 9027 3643 (office) +44 (0)28 9033 5011
FAX: +44 (0)28 9033 5156 mailto:d.r.newman@...