Caching

DokuWiki speeds up browsing through the wiki by caching parsed files¹⁾. If a currently cached version of a document exists, this cached copy is delivered instead of parsing the data again. On editing and previewing no cache is used.

To force the recaching of a single page just add the parameter purge to the URL. Example:

http://www.example.com/namespace/page?purge=true

To force recaching of all pages, including page instructions, touch²⁾ the local configuration file, conf/local.php.

To only force recaching of page xhtml, touch inc/parser/xhtml.php.

To prevent a page from ever being cached, use the NOCACHE tag anywhere in the document. This is useful if the page contains dynamic content, e.g. PHP code that pulls in outside information, where the caching would prevent the most recent information from being displayed.

~~NOCACHE~~

Depending on how big and complex the page is, this may considerably reduce the speed with which that page displays.

DokuWiki uses two cache files per page. To understand this you need to know that a page is parsed to an intermediate instruction format first before it is rendered to XHTML. DokuWiki caches both – the instructions and the rendered XHTML.

• Instruction Cache
  The instruction cachefile only gets updated when the page, the config files³⁾, some of DokuWiki's PHP files⁴⁾ are changed or plugins are added/removed/enabled/disabled using the plugin manager.

• XHTML Cache
  The XHTML cache is also affected by a maximum cache age setting (cachetime), its metadata, some more php files⁵⁾, whenever the existence state of an internal link changes (i.e. the link target page is created or deleted) or when an RSS feed needs refreshing.

The XHTML and instruction cache are located in data/cache/* ⁶⁾. The files end in .xhtml, .i. Other files are also stored under the cache directory, including:

• .feed — any rss feeds generated for the wiki
• .code — portions of the page between <code> ... </code> tags after highlighting has been applied.

Plugins can now influence cache use via the PARSER_CACHE_USE event. This allows plugins which introduce additional dependencies for specific pages to check those dependencies and force DokuWiki to refresh the page when it wouldn't normally.

Up until now plugin developers have only been able to turn off caching completely. This has been necessary for plugins like discussion & include. To make use of the new functionality a syntax plugin will need to:

• save some information relating to the pages its involved with and the dependency specific to each of those pages. The page's metadata is a useful place for this. Metadata can be accessed via $INFO['metadata'] and the p_get_metadata() and p_set_metadata() functions. If using metadata please try to stick to Dublin Core Metadata standards.
• add an action_tutorial component to handle the PARSER_CACHE_USE event.

Caching itself is handled by the cache object⁷⁾. The key parts of that object of interest to plugins are:

• the depends array — DokuWiki fills this all the known dependencies of the page and then uses standard routines to process them. Plugins can add/modify these dependencies before they are processed. The different types of dependencies are:
  • purge — expire the cache
  • age — expire the cache if its older than age
  • files — expire the cache if it is older than any of the files in this array. Only local files may be added.
• the cache name, cache — a unique identifier under which the cache is stored. Normally it is dependent on the page name, HTTP_HOST and the server port. Plugins can generate more complex identifiers, e.g. the include generates identifiers using included page names and whether or not the current user has read access to those pages.

• To reduce server load, map all links directly to the cache dir. When a page is missing from the cache, have an ErrorDocument catch it and redirect to the wiki engine.

This requires a vastly different sort of cache - as the whole page needs to be cached, not just the wiki content.

• Now, if someone has a clever idea how to include in the http response header the information that an expired page from the html cache should be retrieved from the wiki engine instead of the original location, one could also make sure that there are never old pages in the cache without having to check on the server side.

Given only the server is going to know if the page can be delivered from the cache - there is no way it can be done without involving the server side. Effectively DokuWiki does this now. The browser askes for a page, DokuWiki checks to see if the cache copy is valid, if it is it sends it.

Above quoted comments by — Christopher Smith 2006-09-26 00:35

Where are images and css styles cached? When i delete all contents in /data/cache my css or image changes are still not applied.
See forum discussion: http://forum.dokuwiki.org/thread/1282 I'm getting desperate

I use a small batch file with best results

@echo Are you sure ?
@pause
del /F /S /Q data\cache\*.*
del /F /S /Q data\index\*.*
del /F /S /Q data\meta\*.*

Meiki bml040 strudel motorola dot com 18.11.07