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

Some of your URL might look like this ?id=pagename then use & between parameters. Note that order does not matter. Both examples below are valid and produce the same result:

http://localhost/dokuwiki/doku.php?id=my_page_name&purge=true
http://localhost/dokuwiki/doku.php?purge=true&id=my_page_name

To force recaching of all pages, including page instructions, touch¹⁾ the local configuration file, conf/local.php. Saving the configuration settings form over the admin interface will have the same effect.

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

To purge the editor toolbar (and other cached JavaScript) call

http://www.example.com/lib/exe/js.php?purge=true

and clean up your browser's cache (Ctrl+F5) as well. This especially helps if a new button introduced by a plugin does not show up.

You can also clear the CSS cache in the same way:

http://www.example.com/lib/exe/css.php?purge=true

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 Extension 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.

DokuWiki can also store metadata e.g. additional information of pages. Metadata is generated from the Instruction Cache, of which the XHTML of a page is generated too. The metadata has its own caching mechanism.

Metadata can furthermore be added to the Metadata Index. Here is the added information searchable.

To improve the performance for the user, DokuWiki tries to cache external images. If someone wants to use an external image in the wiki content without caching or cache the image with a certain interval, there is syntax to influence the caching behavior.

howto link (external) images in plugins with caching.

Plugins can 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.

A simple measure to avoid caching is that plugin developers turn off caching completely. This is discouraged due to the extra rendering activities, in particular adversely for high traffic wikis. Instead of the plugin developers make use of the functionality to influence the cache by checking (themself formulated) dependencies. Therefore a syntax plugin will need to:

• save some information relating to the pages it's 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 plugin 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 (affected by the metadata value 'date valid')
  • files — expire the cache if it is older than any of the files in this array. Only local files may be added. Take a look at dokuwiki\Cache\Cache and it’s subclasses for a list of the files. Perhaps most interestingly the cached xhtml is dependent on the page's metadata.
• 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, by extending the key with a certain identifier and recreate the cache name e.g. the include generates identifiers using included page names and whether or not the current user has read access to those pages.

As described above, DokuWiki verifies the validity of the cache rather than actively expiring the cache. However, the page xhtml is dependent on its metadata. That is, if the metadata file is more recent than the cache, DokuWiki will determine that the cache is invalid and re-render the page. So, we can update the metadata to expire the cache.

/* code to expire the cached xhtml of page ns:page
 * $id = 'ns:page';
 * $data = array('cache' => 'expire'); // the metadata being added
 * $render = false;     // no need to re-render metadata now
 * $persistent = false; // this change doesn't need to persist passed
 *                         the next metadata render.
 */
p_set_metadata($id, $data, $render, $persistent);