> Chris Smith wrote: > > I realise I am being lazy and the answers to the above two questions > > are probably maybe and yes, in which case I should probably propose > > something so cache management can be centralised. Maybe someone > > else has some ideas, inspiration and time. > This inspired a whole lot of comment. :-) :-) > I have done some checking. Dokuwiki does a lot of filemtime checks in > order to deliver a page, its css and its js. In addition to checking > the filemtime of the particular file, Dokuwiki also checks: > > for renderer instructions: 4 files > for xhtml: 5 files > for js: 10 + each plugin styles.css (not including the two for write > option) for css: 4 + each template css file + each plugin css file > > Is this a lot of checks? Will it make any significant difference to > reduce them? I don't think so and we should test this before putting too much effort in it. Linux (and I guess every other OS as well) will cache stat info for frequently accessed files in memory, so accessing those timestamps should be really fast. > Say to have a cache checking value in config, so developers could have > it set it to exhaustive and stable wiki's could have it set to > minimal? that could work - hower I could also live with a manual cachrefresh while developing. In my experience developers have no problem with refreshing caches... the problem is with the user - she always expects to see an immediate change if she changes something - so everything that is changeable through the interface should be autochecked. > Putting aside the template CSS files which are there for user change, > in a stable wiki how often will any of the other files get changed > independently of a dokuwiki upgrade? > > I think not very often. In which case, I'd reckon the number of > checks for a stable wiki could be reduced to three files: > - dokuwiki.php (above four all check this file and it will be updated > with a dokuwiki upgrade). > - local.php (above four all check this file, and it represents user > config changes) > - new file, $conf['data']/meta/<thiscache>.cache > > A cacheutils function ... cache_expire($cache_name) would provide a > defined interface for expiring caches. sounds good. > To expire all caches, it will touch local.php what wehn local.php isn't writable by the webserver? why not add meta/local.cache (I know - another file to check) > It looks like the js handler sends headers which tells the browser not > to cache css & js. Uhh that shouldn't be the case and needs to be investigated. > Might it be better to allow the browser to cache > these files, or at least for this to be configurable - again, for a > stable wiki there should not be a problem with the browser caching the > CSS or 90% of the JS. That may mean split the js files into two, > browser cacheable and browser not cacheable? for now I always did put the not cachable stuff in a small <script> section in tpl_metaheaders Andi