I made lots of fixes to this code over the last few months. I’m pretty sure it now only deletes the cache on the current blog and not the whole site but please try this on your development server first!
I have version 1.1 installed on my site already and my testing so far seems to clear the whole cache. I am just looking at cached files on the network under Contents and doing some tests on sites on the network. There are never more than 10 caches pages in contents at a time.
We are running an slightly older version of wordpress… could that play a role. Version 3.3.2 I think.
Some other info about our settings:
– mod_rewrite
– Don’t cache pages for known users
– Mobile device support
– Clear all cache files when a post or page is published or updated
– Only refresh current page when comments made
– Cache Timeout: 86400
– Time: 86400
(Of course it never gets any where close to this)
I see this Debug option. I have a dev server I can test this on, but I’m not sure how this will work. I’ll play a little, but any thoughts you can give would be great. Perhaps it is just a setting.
Thanks for this awesome plugin. You really are awesome and we appreciate it so much!
Doing some more digging. So there is a folder in \wp-content\cache\supercache that has all the cached stuff, and there are folders in there for quite a few sites. They don’t seem to be deleted. But I’m not sure if it recreating them or they are just there.
Doing some more testing. Thanks Donncha!
I spoke too soon. It is definitely clearing out the whole cache. Now that I can see it I can tell very easily.
Could it be because we had an old MU site that was upgraded to Multisite when it merged? I read something about that causing some problems somewhere. Thoughts?
That’s weird. I’ll have to look at that.
I can’t replicate this. Using the development version (but this particular code is the same as in version 1.1) it only deleted the cached files in the blog’s own supercache and blogs directories.
You could try manually debugging the output of get_supercache_dir() and add an error_log to prune_super_cache logging the directory it’s looking in?
Donncha, I have done some local testing myself and can’t seem to replicate it except for on our dev and prod environments.
I’m sorry. What do you mean by a “manually debugging the output of get_supercache_dir() and add an error_log to prune_super_cache logging the directory it’s looking in”. Create some php file and put it somewhere? I’m just getting familiar with PHP. Sorry about that. But I can certainly do that.
As an aside I did notice some differences in the cache being built. In the tests I did the cache was created something like this:
http://media.oasis.unc.edu/instructional_technology/web.unc.edu/cache-testing-working.png
In the supercache folder there are then each of the site names.
But our environment it looks like this:
http://media.oasis.unc.edu/instructional_technology/web.unc.edu/cache-testing-broken.png
There are some top level pages for domains. Not sure what those are. Viewing them it looks like content, but not theming.
Ah ha! Found it I think. I was finally able to replicate the problem locally and play with it more.
It turns out that the following line was below the absolute path stuff (below the “That’s all, stop editing!” line).
define(‘WP_ALLOW_MULTISITE’, true);
I also had to add in the following line below that:
define( ‘MULTISITE’, true );
I think because my site was wordpress mu when we started it was not included. I thought just adding in the first part would work. But it requires both to work correctly. I am pushing this fix out to our dev environment now and will confirm if it is working as expected after this.
Ah, glad you found that! Support for old MU sites isn’t what it should be and I’ve forgotten all the config bits we had in wp-config.php now!
Well, this is a bit harder than we thought. Apparently the tests I did locally were on a brand new wordpress multisite database. You can not just add these lines to an older database because they have different tables.
define(‘WP_ALLOW_MULTISITE’, true);
define( ‘MULTISITE’, true );
If you add these into an older MU config file you get a “Error establishing a database connection” on the front end and a “One or more database tables are unavailable. The database may need to be repaired.” on the backend.
Repairing the tables does not help. I think that when you define multisite like this it is looking for some specific tables and structure that is defined in the multisite install.
I did a compare of the two table structures you can see here:
http://media.oasis.unc.edu/instructional_technology/compare-tables.png
So… I have two options right now I think (but please tell me if I am wrong). I can mess with the tables on the multisite install (27K tables), OR I can figure out a way to tell the plugin that this site is multisite without having those lines in the config file.
Could you tell me how I might accomplish the second option? It seems easier to modify the plugin than to start modifying the database. I hate to leave the dev path though of course so if you can add an option to the plugin that would be even better… 🙂 I can’t be the only one that had an old MU site and upgraded it to Multisite that are using the super cache plugin.
Thanks for your help Donncha!
You know how typing things out helps you think a bit. Well, I went to my MU install and tried fiddling there. I found out that you don’t need the second part of my solution above. So all you have to add is the following:
define(‘WP_ALLOW_MULTISITE’, true);
(Be sure to add it up around the database info… well, really just not at the end of the wp-config.php file).
That has gotten my local dev back up, and the caching column available on the sites page. The cache seems to be working too. But then again it was working earlier too.
Send some notes to the server folks to have it applied to the dev production server (yes we have a dev prod server… hehe).
Fingers crossed!
Wahoo… yes indeed. We are good to go! Just needed to add that one line. I hate when you spend some much time on something and it is a simple change like that. I hope this help others that might have this same problem. Thanks again Donncha.
