A tough Plugin/Caching question

I have a plugin that switches the template of the requested resource based on a $_REQUEST variable. This works amazingly well for uncached resources. However, I would like it to support cached resources, as well.

I'm using both lines of code below:


This works for cacheable resources, but not until I reload the page. It doesn't matter where I put the code. This will only be fired for graceful degradation, so its not a huge load on the system, but I do need it to work with cached resources. Any suggestions?

Additional Information:

The plugin fires on the OnLoadWebPage event. This means that the resource is found, but is not supposed to be parsed yet. This is definitely true, as the uncached pages work properly. It seems as if the cache refresh happens after the event instead of during it.

The cache is checked before anything else is done. So if the page is cached, it's served without any further processing (except for the post processing); the parser never even checks for the template if it finds the document in the cache.

I think somebody's going to have to do some kind of plugin to skip the cache if the GET value is there. I never was able to figure it out for Evo all those years ago when I first wrote the template switcher for Evo.

Aw, bugger. Well, I'll keep the thread open in case someone else has some awesome input. And if I figure it out, I'll shoot you a message!

I've thought of using an event before the cache is checked and if the GET is there (and points to a valid template) delete the cache file; that way when Revo gets around to checking the cache, it won't be there so the page will get parsed, and the new template assignment from the plugin will work.

I could probably do that. My system for aliasing and handling requests is even more simplified and passes through events quite easily. I would just have to find the correct event.... WAIT!! I already have it. By George, Susan!! You are a genius!! Tell me what you think of this::

Since my AJAX Aliases fire on OnPageNotFound, this is already before MODx checks the cache. This is because there is not currently any document to check the cache for. So, before I issue the sendForward(), I can clear the cache for the page... Then the sendForward happens and fires OnLoadWebPage. Just one question:

Is there any way to clear the cache for one resource? [ed. note: fuzzicallogic last edited this post 14 years, 2 months ago.]

Sounds good.

Just make sure to do all kinds of sanity checks on the GET input before you do anything else. I can see all kinds of opportunities for mischief and general mayhem, not to mention interference from our good friend Murphy.

I don't need to!! I'm not using GET I use REQUEST_URI and parse it. GET is used by the specific resources only. I'm super excited. Now I just have to research how to clear cache for one resource only.

All GET does is take the REQUEST_URI and break up the query string into a nice, neat array. The input values are the same. There is no advantage of manually parsing the REQUEST_URI over using GET. The input is still untrustworthy.

All GET does is take the REQUEST_URI and break up the query string into a nice, neat array.

Are we talking about the same thing? _GET is part of _SERVER['REQUEST_URI'] but they are not the same thing. _GET is simply the part after '?' in the REQUEST_URI. The REQUEST_URI is the actual URL including _GET minus the host and scheme. If we're not talking about the same thing, please enlighten me, as I have done a lot of testing regarding the security and usability of these URLs, even to the point of being able to change index names and specific aliases via the System Settings.

The input is still untrustworthy.

No doubt. I'm not building a query, so there's no worry for SQL Injection. The Path for the REQUEST_URI is ordered, uses no param names, and does its own validation where necessary. In other words, it is simply to find the right document and pass it (normally just one or two, always nondescript numbers) unnamed parameter. Additional security measures are handled by the document retrieved, normally in the form of URL validation and user validation.

There is no advantage of manually parsing the REQUEST_URI over using GET.

It depends on what you do with it. Given that they are not the same, a hacker would have to poke around quite a bit to figure out the values necessary to make desired changes. With GET, the user would know the params and have immediate insight into their usefulness. Given the above conditions, I'd say that my system is much more secure than using GET to pass named and known params.

If you've already got the resource as per your original post, you could try $resource->setCacheable(false), I think that might override the cache before it even checks if it exists.