Uncacher not working as expected, can't figure out cache issues

Summary

Uncacher plugin isn’t working as expected.

Step to reproduce

Save a resource with “Clear Cache” UNchecked. The plugin is supposed to clear cache on just that resource and any parents and site start.

Observed behavior

The cache file was not deleted for the current resource or any parents or start page.

Expected behavior

The plugin’s job is to delete only the cache file of the current resource, and any/all parent resources as well as the site start page. And when the clear cache checkbox is off, this prevents MODX from clearing the entire site cache at the same time.

This plugin seems unable to delete the cache files for whatever reason, and there are no logged error messages regarding it.
File permissions at the server level are not the issue.
At best it seems like when the plugin uses the modx cacheManager, it perhaps doesn’t have some kind of internal permission to delete cache files created by modx itself?

I am able to use cacheManager->get() to grab the page and var_dump it. But switch to cacheManager->delete and nothing happens.

What is even more odd is that cacheManager->delete() returns TRUE as if it worked.

Environment

SiteGround on PHP 7.2.
Also tested on localhost.
Latest version of MODX 2.7.2.

I’ve done so much troubleshooting that I’m now giving up. I really can’t figure out why cacheManager->delete() isn’t able to delete a cached resource any more (plugin is from 2012). Something in core may have changed but I don’t know what else to check.

1 Like

I don’t know why that’s not working, but the CacheManager plugin is another way to go, although it will only clear the resource’s cache, not the parents or site_start page. (I haven’t tested it in MODX 2.7.2, so it may have the same problem as Uncacher).

Also, is it possible that the cache is being cleared but your browser cache isn’t? I really like the Chrome add-on, “Cache Killer” for testing stuff like this, although you can also use private or incognito mode.

1 Like

Hi Bob,

I’ve installed a fresh copy of MODX on localhost just for testing this one issue. Installed the plugin, and I can watch the cache folder in real time for delete/add/timestamp changes, etc.

It seems as though the delete() function simply doesn’t do anything.

1 Like

Interesting. With that setup, you might do me a big favor and test CacheMaster for me on 2.7.2. :wink:

BTW, looking at the Uncacher code, the only thing I spotted is that it assumes that $this->modx->cacheManager is set. It probably is, but it’s usually done something like this:

Instead of

$this->modx->cacheManager->delete(...);

You do this:

$cm = $this->modx->getCacheManager();
$cm->delete(...);  // etc.
1 Like

Sure thing.

I uninstalled all plugins on my localhost test site. It’s a clean install of 2.7.2.

Installed CacheMaster.

Created two resources and opened both so MODX would create cache files for them.
This became 1.cache.php and 2.cache.php in the core/cache/resource/web/resources folder.

Using all defaults, no changes to plugin settings or properties, it appeared to work fine.
I edited my 2nd document, the Empty Cache checkbox is automatically turned off by the plugin, and I saw the 2.cache.php file disappear on saving the resource.
Then I saved the 1st resource and only that cache file disappeared as well.
All seems well.

That said, I then analyzed your code. I first tried to create my own copy of the cachemanager object like you said, but that didn’t do it. I guess the main $modx object already has it available with $modx->cacheManager so no need.

Then I noticed in your code, you build the full path to the cache files manually and deleted it at the end of your code “just in case”.
When I remove this manual deletion, the plugin still worked on my localhost, but no longer worked on my client site!

Once again leaving me scratching my head, why won’t the delete function work?
This site has been through multiple fresh upgrades so I doubt there is file corruption just in the caching classes.

I guess the only option now is to disable all my plugins one by one to see if something else is getting in the way.

1 Like

I’ve disabled 15 other plugins, and I’m not making this up, but it works again when Wayfinder is disabled!

I’m at a loss what Wayfinder has to do with using cachemanager to delete items.

There are some interesting entries in the Wayfinder changelog though, such as:
“- [#27] Improve caching in Wayfinder to store cache files in resource cache so cache is synced with modx core caching”

What does it mean sync cache with modx core? Could that be something?

“Ensure that caching also caches by user ID to persist access permissions through cached result sets”

Could it be messing with cache by using user IDs somehow?
I thought there wasn’t access permissions for cache files?

Nowhere in the Wayfinder code does it even use the delete() function on cacheManager.

I confirmed this on my localhost setup. I have a barebones custom plugin I did which has the minimal code just to delete current resource cache. It works fine.
Installed Wayfinder. It still worked.

And then I made a chunk to actually use Wayfinder menu and put that in the template. Now it stopped working. The cache file would no longer delete once Wayfinder messed with cache stuff.

Sheesh.

1 Like

The culprit ended up being Wayfinder.
When that was in there, it creates more cache folders under core/cache/resource/web/resources/{id}/xxxxxxx.

The {id} there conflicts with other standard cache files like {id}.cache.php which are in the same folder.

@opengeek helped track down why, and there is a bug report for it now.

XPDO will need updated to handle the situation.

For now I had to do some code edits to get around it and so far so good.

2 Likes

Impressive detective work! Thanks for reporting back. :slight_smile:

1 Like