Reasonable plugin, but needs advanced exclusion rules

The SG Optimizer plugin does not control the static cache. It is enabled or disabled by default per domain name. It is not a full page caching and has nothing to do with the plugin or other plugins like WP Rocket. For example, you can even use another full page caching plugin with the Static cache on.

However, the Static cache should not require exclusion on first place. Can you give me some URL and way to re-create the issues you’re experiencing so I can look into it and tell you how to proceed and configure your account for best performance?

Hi @hristo-sg

Yes that is the issue. Exclusion URLs entered into the SG optimizer plugin don’t seem to apply to static cache. There’s no way to manage that at all. You simply have to login to cPanel and turn it off completely (and therefore lose dynamic cache as well).

SiteGround support are aware of this issue. They were able to replicate the problem on a test website I setup in conjunction with the “Prevent Direct Access” plugin developer. Here is what they have said: https://www.dropbox.com/s/hjmr5t4h3tyr4e9/iblekmllnjclmeoa.png?dl=0

I am sorry that my colleagues hasn’t explained this the best way.

The SG Optimizer plugin does not manage the static cache. It can just purge. It is not possible to to have an exclude the way dynamic caching has.

The Prevent Direct Access plugin can simply trigger a cache purge once the file is downloaded. At the same step they delete the file:

if (function_exists('sg_cachepress_purge_cache')) {
    sg_cachepress_purge_cache('https://yoursite.com/wp-content/uploads');
}

Doing this will purge the cache only for that folder and everything will work as supposed.

If you give me ticket ID and permission I can even hardcode it to prove the concept…

Perhaps that feature needs to be added to the plugin. Alternatively it should be added to the cPanel SuperCacher module. Though that means managing SG cache in two places, via cPanel and via SG Optimizer. That seems pointless.

Sorry I don’t have the ticket ID. The plugin developer submitted the ticket as many SiteGround customers are impacted.

It appears to be a fundamental flaw in the way SiteGround delivers its caching services. They provide a plugin to manage dynamic cache and add URL exclusions, but the same plugin cannot apply those exclusions to static cache. So the whole lot, static cache and dynamic cache has to be disabled.

A free version of the plugin we are using is here: https://www.ads-software.com/plugins/prevent-direct-access/

Almost 4,000 websites use the premium version. Although I imagine many other plugins are impacted by this SiteGround issue.

It is a completely different type of caching, that’s why it is managed in different locations.

We don’t have complaints from other plugins and honestly you’re the only one using this that has issues. It is not a fundamental flaw but the way static cache works. Plus, that’s exactly why we’ve created a public function for smart cache purge – so developers of other plugins can clear it when needed. We monitor standard WordPress hooks but we can’t predict what every plugin developer out there will do.

Again, that’s not a fault in our end.

• This reply was modified 5 years, 9 months ago by Hristo Pandjarov.

It’s not managed in different locations in cPanel. It’s all in the SuperCacher: static cache, dynamic cache and memcache.

It seems only in SG Optimizer that you want to decide to manage it different locations. Although you report there is no way to manage static cache at all. So your statements appear to be completely contradictory.

You do have complaints from other plugins, there are other similar plugins that would be affected by the inability to exclude files and directories from SiteGround’s static cache. SiteGround support staff have conceded that. It is a known flaw.

I am not the only one using this plugin that has issues, that’s why the developer themselves has been dealing with it directly with SiteGround. What a completely absurd statement.

Those are different caching layers. That’s why the Static cache is enabled per domain name, while the Dynamic per installation. When the Dynamic cache is purged, it purges the Static too but there is no way to exclude paths from it.

That’s why we’ve created a public cache purge function so developers can clear the cache at the moment that’s necessary. It is trivial for the developers of Prevent Direct Access and any other plugin that has similar issues to invoke the above provided functions and purge that part of the cache that handles data that should be private.