[Plugin: WP Super Cache] Major BUG: Network Deactivating deletes files

Why would you create a symlink in a “cache” directory to files like that? The cache directory is generally for temporary files.

Unfortunately it’s not really possible to second guess what people will do on their servers. You can’t avoid symlinks because some people may actually have symlinks in there to temp folders holding temporary files.

What I will do however is add a filter on the list of “protected directories” in the prune_super_cache() function in wp-cache-phase2.php.

Best practices for deactivating plugins includes cleaning up after themselves which is what this plugin does. I am considering how to tackle this however as a number of people have complained about it.

“Why would you create a symlink in a “cache” directory to files like that? The cache directory is generally for temporary files.”

Because WP multisite installs resolve file URLs by invoking WordPress, reverse-engineering the permalink, locating the file, and then serving it up. This file serving tactic doesn’t happen with single blog installs, just multisite installs. The symlink approach allow for blog names to resolve cleanly to their internal numeric value and using a simple rewrite rule to point at the correct location. The symlinks themselves are the “cached/temporary” items, not the files/directories they link to. This approach makes perfect sense to me.

If you feel you must delete files and directories on deactivation, please at least make a call to the PHP function is_link() and only remove the link so that you don’t just blindly walk every directory deleting everything willy-nilly. The result will still be annoying but will be MUCH less painful.

You could put those symlinks in the uploads directory. Sorry, I won’t be putting an is_link() check in.

Well-behaved programs on *NIX systems don’t blindly traverse every directory while deleting files. Determining the difference between a symbolic link and a real directory is easy.

WP Super Cache is already directly responsible for causing data loss.

More importantly, I read your reply to mean that you aren’t interested in preventing future data loss from happening.

I see your stance on actual data loss as horribly wrong. If I learned that my software caused data loss, I would bend over backwards to make sure it never happened again.

Hi Bigsite and Donncha O Caoimh.

This happened to me as well – I’m using “Nginx + WordPress 3 Network with multiple domains + WP Super Cache” and all the uploaded files on all blogs were deleted when i clicked the button “Delete Cache on All Blogs”, which calls “prune_super_cache()” and delete everything inside “/wp-content/cache/”.
I used Bigsite approach to place symlinks inside this directory (/wp-content/cache/ms-filemap/).

I now moved “ms-filemap/” dir to “wp-content/”.
Bigsite, it would be great if you could please edit https://codex.www.ads-software.com/Nginx, so others don’t get their images deleted as well?

While you are at it, you could substitute the PHP script that generates symbolic links by the one i suggested on https://www.ads-software.com/support/topic/nginx-php-fpm-php-apc-wordpress-multisite-subdirectory-wp-super-cache/page/2 (it’s just a a slight improvement over yours)

Donncha O Caoimh, it would be great if you could please change “prune_super_cache()”, so it doesn’t delete everything inside “cache/”, just the WP-Super-Cache dir/files.

Thank you both for sharing and helping the WordPress community.

Gon?alo – I didn’t know that codex page was there but I’ve edited it now and it recommends using wp-content/ms-filemap/ instead of the cache directory.

I am really sorry that you suffered data loss. I’m going to add a note to the readme.txt warning users that only temporary files should be put in that directory.

Multiple issues: A symlink on a modern filesystem isn’t a file. The directory tree a symlink points to isn’t meant to be walked during a tree delete. Calling the directory ‘/cache/’ makes it look like it is a general place to store cached content for any plugin – NOTHING about the name says that it is ONLY for ‘wp-super-cache’ content. In my case, I recreate the symlinks every few minutes if they get deleted.

WordPress, on our installation, also has a nasty habit of creating a (broken) symlink instead of a directory when setting up a new site, which I have to manually fix from the command-line. I strongly suspect this is due to our PHP opcode cache. It is conceivable that this plugin with a PHP opcode cache could create a working symlink that later causes severe data loss.

Or let’s suppose someone manages to somehow set up a symlink somewhere in the cache directory tree. If the admin later disables this plugin there will be severe data loss.

The simple fix is to use ‘is_link()’ before traversing into what looks like a directory. The real fix is to stop deleting files on deactivation.