There are many different caching features in Revolution at the moment, but I do not currently have a tag feature for clearing the cache. However, different aspects of the caching can be extended with user-defined classes, so it is possible to implement this kind of feature in custom component cache mechanisms (i.e. where you cache your own custom data), just not throughout the entire core.
First, lets take a look at all of the things in the core/cache/ directory of Revolution (or core/cache/MODX_CONFIG_KEY/ if you have that set to something other than ’config’)
Configuration Cache
In the root you will find the config.cache.php which contains the system settings which are loaded on any request.
Context Configuration, Event Map, and Plugin Caching
In a subdirectory for each context (i.e. web/ or mgr/ or connector/) you will find a context.cache.php file containing the context settings, a plugin event map for the context, and the plugin elements that are registered in the event map.
Resource (Partial-Page) Caching
Within the web context (or another custom front-end context) there will be a subdirectory for resources/ containing files like 1.cache.php where the 1 represents the id of the resource. These files contain the resource object as well as any cached element output used by the resource.
Element Caching
Within each context you will also find an elements/ subdirectory containing cache files for various kinds of elements (especially snippets and plugins). These contain various kinds of cache files which the element classes make use of when they are being processed. For instance, snippets and plugins both cache a generated global function which is included and made available at runtime.
xPDO Object and Database Result Set Caching
If you enable this, xPDO can cache query result sets representing any objects and collections in the objects subdirectory. This can be enabled in environments where database access is more expensive than PHP include time. This is separate from all of the other caching mechanisms which are very specific to the operation of MODx.
Programmatic Caching
xPDOCacheManager and the modCacheManager class derived from it provide some useful features for caching any kind of data to just about any cache system and includes a memcached implementation. There is no tagging feature here as in the programmatic features of the Zend_Cache library but there are definitely some ways to clear specific parts of any custom caching, as well as various parts of the MODx-specific caching mechanisms described above.
Now, here are some examples of using modCacheManager->clearCache():
<?php
// get the cacheManager
$cacheManager= $modx->getCacheManager();
// clear all the usual stuff by default (all files with the extension .cache.php in the cachePath + all object caches)
$cacheManager->clearCache();
// clear only cache files with extension .php or .log in the web/ custom/ or logs/ paths; no objects are cleared
$paths = array('web/', 'custom/', 'logs/');
$options = array('objects' => null, 'extensions' => array('.php', '.log'));
$cacheManager->clearCache($paths, $options);
// clear all cache files with extension .php in the cachePath + all objects + execute the timed publishing checks
$paths = array('');
$options = array('objects' => '*', 'publishing' => true, 'extensions' => array('.php'));
$cacheManager->clearCache($paths, $options);
?>
I’ll let you digest this and we can begin a dialog from there...
MODX Staff