Multi-Site Cache Deletion Issue with WP Rocket's Background CSS Image Caching

[admdanielspalma]

WP Rocket's recent implementation of the "Activate for CSS background images" feature creates a folder at /public_html/wp-content/cache/background-css. This folder is at the same directory level as /wp-content/cache/wprocket. In a WordPress multisite setup, when the cache is cleared on one site, it deletes the entire contents of the /public_html/wp-content/cache/background-css folder. This action inadvertently affects other sites on the network, breaking their functionality. This issue suggests that in a multisite environment, this feature cannot be used without causing interferences among sites.

To Reproduce
Steps to reproduce the behavior:

Set up a WordPress multisite network.
Enable WP Rocket and the feature "Activate for CSS background images". Clear cache to recreate files.
Notice the creation of the /public_html/wp-content/cache/background-css folder. Wait it to be populated.
Clear the cache on OTHER of the sites in the network.
Observe that the entire contents of the /public_html/wp-content/cache/background-css folder are deleted, impacting other sites on the network.

Expected behavior:
The expected behavior is that clearing the cache on one site should not affect the cached content of other sites in a multisite network, particularly not deleting the entire contents of shared cache folders like /background-css.

Additional context:
This issue is particularly critical in environments where multiple sites are relying on WP Rocket for performance enhancements, as it leads to unexpected downtime and broken site functionality.

Suggestions:
Ensure that cache clearing in one site of a multisite network does not affect the cache of other sites, especially in shared folders like /background-css.
Implement a mechanism to isolate cache clearance activities to the site where it's initiated.
Test across different multisite setups to ensure robustness of the solution.

[piotrbak]

Hello @admdanielspalma thanks for creating the issue. Could you tell me what kind of multisite you're running? Subdirectory, subdomains or mapped domains?

Thanks

[admdanielspalma]

Hello!

I'm using a subsite installation with Top Level Domains as its roots.

[RomelloKortbeek]

Hi!
I’m having the same issue on my multisite (with subdomains).
Following this issue, hopefully it will get fixed soon :)

[admdanielspalma]

I've been struggling with this since it was implemented... but I didn't know what was causing the problem before. I hope it doesn't take too long to fix. Does anyone know if it usually takes a long time?

[admdanielspalma]

Hello @admdanielspalma thanks for creating the issue. Could you tell me what kind of multisite you're running? Subdirectory, subdomains or mapped domains?

Thanks

Hello!
Shouldnt we set the TYPE-BUG tag?

[admdanielspalma]

This another bug was posted 2 weed ago and is already fixed.😅

#6389

Will the bug of this topic be in the queue? Thanks

[piotrbak]

Hello @admdanielspalma yes, we'll handle this problem soon.

[remyperona]

@CrochetFeve0251 Your input would be good on this one for the following point:

I can see that the background CSS cache folder is set by default to background-css in Common\ExtractCSS\ServiceProvider, but it's set to background-css/' . get_current_blog_id() in Media\Lazyload\CSS\ServiceProvider.

When testing the background CSS cache path during the clear(), the value doesn't contain the blog ID.

On another level, the cache clear should happen based on the current site domain (the cache and mapping files are created inside sub-folders of a main folder named after the site domain), but it's currently deleting the whole background-css folder as reported.

[admdanielspalma]

Hello. Was it fixed?

[abecuwedahive]

+1. This issue is really annoying because we have a multisite with 20+ blogs.