[Revolution] Clear cache of custom components

For a still private component, I needed extra cache functionality which MODX already provided me with. I’ve got it working pretty quickly and I thought I’d share it with all of you. Nothin’ special but it may save you a couple of minutes finding it out!

Creating some DEMO data to use as a cache substitute.

• $array contains an array of 10000 keys with the value "MODX Cache" (this needs to be referenced!)
• ’filename’ should be replaced by the name you want (eg: test; will result: test.cache.php)
• 7200 is the lifetime in seconds, thus 2 hours
• xPDO::OPT_CACHE_KEY defines the folder, omit it if you want it to be placed in /default/
  
• Note: $modx->cacheManager should be called with $this->modx-> inside your classed

Clearing the cache within your component
If you have chosen to omit the OPT_CACHE_KEY, you can simply call it as it is, thus;


If not, call it like so:


Clearing the cache together with the Site Cache (known as Clear Cache in the English MODX menu)
Create a plugin that hooks on OnBeforeCacheUpdate with the following code:



And that’s it! Nothin’ to it, right? I realise that it is very basic and very simple, but this might help you creating your own cache manager for your classes.

Thanks, this has helped me a long time ago.


Though to add something, clearCache should only be used in < 2.1, while refresh should be used in > 2.1.

http://rtfm.modx.com/display/revolution20/Caching#Caching-ProgrammaticCaching

Mark, I think it might be clearer if that documentation page had separate examples for refreshing just the resource cache, refreshing just the System Settings cache, and refreshing the cache for a particular resource. I assume that you wouldn't need to retrieve the contexts for the last two, but maybe that should be stated and it would be nice to see an explanation of why you wouldn't want to refresh the Manager context resource cache and whether it's OK to refresh any one part of the cache without refreshing the others.





---------------------------------------------------------------------------------------------------------------
PLEASE, PLEASE specify the version of MODX you are using . . . PLEASE!
MODx info for everyone: http://bobsguides.com/MODx.html [ed. note: BobRay last edited this post 14 years, 8 months ago.]

Can you file that at http://bugs.modx.com/projects/docs/issues so it doesn't get lost in the forums?

Done.

Quote from: BobRay at Jan 28, 2012, 10:39 PM

Mark, I think it might be clearer if that documentation page had separate examples for refreshing just the resource cache, refreshing just the System Settings cache, and refreshing the cache for a particular resource. I assume that you wouldn't need to retrieve the contexts for the last two, but maybe that should be stated and it would be nice to see an explanation of why you wouldn't want to refresh the Manager context resource cache and whether it's OK to refresh any one part of the cache without refreshing the others.

System Settings changes affect everything. If you update a System Setting, there may be certain keys which do not affect anything else, but in most cases, they will affect every cacheable Context, Resource, and Element in the site where they are used.

For the Resource cache, you may have components using this partition to cache additional Resource specific data, that is intended to be removed when the partition is refresh()'d. And custom components may have their own custom cache partitions with dependencies on data in other cache partitions.

I guess my point is that the interdependencies in the cache are complex and defining what must be refreshed when certain changes are made can be be very difficult. Thus the default behavior is to clear all Contexts and Resources, etc. when you clear the site cache, or all affected Contexts and their Resources when editing a specific Resource. This complexity is not eased by the flexibility of the framework in this case either.

My preference for future is to allow custom cache refresh configurations to be defined and applied, so site owners/developers can have fine-grained control when desirable, without having to delve into code.

Good points. I was thinking of a case where I wanted to clear a System Setting specific to an extra of my own. I know there are no dependencies.

I was also thinking of the case where you create a new resource, but need to clear the cache to retrieve it with getObject().

BTW, The reason I'm so interested in this is that I've been having fits with Package Manager and what I think is a cache issue. If a transport package creates new resources, as far as I can tell, those objects can't be retrieved with getObject() in a script resolver, even after calling refresh(). It works fine with elements. I think the same problem exists for new System Settings, but I'm not sure.

Also, getOption() seems to not be able to get the value of a System Setting that's just been changed and saved, even in a snippet, even after clearing the cache. This snippet changes the value successfully, but reports the old value:



Output:

Setting: 999

You would have to reload the MODX instance from scratch after each setting change to get the new values; in fact save()'ing a Setting already clears the cache for you (like it or not). Settings are configuration and are not meant to be changed during the course of a request to MODX for immediate use.

I do not know how much this method is correct if you want to clear the cache of a particular resource (if it has no interactions with other resources). For example, I need to clean up the resource with the id 5.

Is there a safe way to reload the MODX instance in a script resolver?

getObject() in a script resolver is still consistently failing to retrieve resources and system settings created in the package.

I need to set the system setting to the ID of the resource and can't retrieve either of them.