Plugins and caching

admin管理员组

文章数量:1279044

So, I've been tinkering with a basic firewall plugin and today I stumbled upon a problem. Caching. I had forgotten that I had LightSpeed cache installed one one of my test sites and went to work on my plugin. I set it up to error log some details for me and started trying to load the site's main page. A hour later after dozens of refreshes and still not seeing any error log I remembered the cache. No matter what URI I plugged in the cache took complete control and basically disabled my plugin from even loading. First line in my plugin, create an entry in the error log... nothing. The instant I disabled the cache, I had error logs.

The only time LightSpeed allowed my plugin to even run was on the admin side. Not on the public side.

So, here's the question. If you were planning to write some plugin that grabs the incoming URI or IP or user agent and do something with it, how the hell could you expect it to work if these caching plugins completely bypass and essentially disable your plugin anyway?

How could your plugin even detect these cache plugins if they refuse to even let it load and run? Ok, so you could start looking for directories and headers and such during your plugin activation, but assume they install the cache after your plugin. Then what?

I've attempted to hook into wp, init, plugins_loaded, muplugins_loaded and lightspeed is still managing to bypass my plugin.

So let's assume for whatever crazy reason, I wanted to block all IP's from TOR exit nodes. If the cache won't even let your plugin fire, how are you supposed to block the IP???

So, I've been tinkering with a basic firewall plugin and today I stumbled upon a problem. Caching. I had forgotten that I had LightSpeed cache installed one one of my test sites and went to work on my plugin. I set it up to error log some details for me and started trying to load the site's main page. A hour later after dozens of refreshes and still not seeing any error log I remembered the cache. No matter what URI I plugged in the cache took complete control and basically disabled my plugin from even loading. First line in my plugin, create an entry in the error log... nothing. The instant I disabled the cache, I had error logs.

The only time LightSpeed allowed my plugin to even run was on the admin side. Not on the public side.

So, here's the question. If you were planning to write some plugin that grabs the incoming URI or IP or user agent and do something with it, how the hell could you expect it to work if these caching plugins completely bypass and essentially disable your plugin anyway?

How could your plugin even detect these cache plugins if they refuse to even let it load and run? Ok, so you could start looking for directories and headers and such during your plugin activation, but assume they install the cache after your plugin. Then what?

I've attempted to hook into wp, init, plugins_loaded, muplugins_loaded and lightspeed is still managing to bypass my plugin.

So let's assume for whatever crazy reason, I wanted to block all IP's from TOR exit nodes. If the cache won't even let your plugin fire, how are you supposed to block the IP???

• plugin-development

Share Improve this question edited Oct 1, 2021 at 18:46 uPrompt asked Oct 1, 2021 at 18:15 uPromptuPrompt 17299 bronze badges

Add a comment  | 

1 Answer 1

Sorted by: Reset to default 1

Well this is the whole point of cache plugins. Caching plugins let the page load normally, with all plugins, and then saves the result as a static HTML page. Future requests for a specified period of time, or until the cache is emptied, will be sent directly to that HTML file. This allows the page to load much much faster precisely because WordPress and plugins don't need to run again. But there are drawbacks, as you've identified.

So let's assume for whatever crazy reason, I wanted to block all IP's from TOR exit nodes. If the cache won't even let your plugin fire, how are you supposed to block the IP???

You probably couldn't do this exclusively via a WordPress plugin if a cache plugin was installed. The best case scenario is that nothing is blocked, and the worst case scenario is that you cache a request from a blocked IP, therefore blocking everyone.

So how do plugins deal with caching? It depends on the functionality that is affected.

1. Some plugins simply won't work and will require any pages they're on to be excluded from a cache, or require logged in users to be excluded from the cache. Some caching plugins have an API that plugins can use to tell the cache plugin not to cache a given page. For example, WP Rocket looks for a constant, DONOTCACHEPAGE. If the constant is true for a particular page, then it won't cache that page. In your case you'd be excluding every page, so this would not be a good solution.
2. Some plugins which perform redirects, like Redirection, have an option to export their redirects to an Apache/Nginx file that's read by the server. That way the plugin doesn't need to run, as the server will handle the redirects.
3. Plugins with some kind of user-specific dynamic output, like WooCommerce's shopping cart, will use AJAX to load the data asynchronously. AJAX requests typically aren't cached by these plugins.

So if your plugin is for blocking requests from certain IPs, I'd suggest something like #2, where you would have the option to create/update a file on the server that takes care of the blocking.

本文标签： Plugins and caching