Same boat: WP-DBManager breaks database cacheing in W3TC for me.
But I did the opposite as you because working W3TC is more important than scheduled db backups. I guess I’ll just have to do them manually…
If you are using the file/disc object cache, this is because wp-cron does not work anymore. The wordpress cron and transient API rely on their values being saved persistently in the wordpress cache between requests. Having W3 Total Cache installed and using disc/file based object cache, these values are stored as w3 cache files and they are broken:
http://wordpress.org/support/topic/updated-w3cache-and-now-very-slow?replies=6#post-3710678
You can verify this by installing a cron viewing plugin like WP-Crontrol: http://wordpress.org/extend/plugins/wp-crontrol. You will notice, that the crons “next-run” values are not updated. This is because they are simply not run.
Nice tip ptnplanet.
This explains a lot. I upgraded WP3.5 core, W3TC, and WP-DBManager at the same time and couldn’t isolate the problem.
Thanks guys – I have this problem too with WP-DBManager, but didn’t realise I had it until I came across your reports.
For my personal opinion, for this specific and others related issues, the problem is not WP-DBManager plugin, or W3 Total Cache, but a WordPress core bug regression. Add more cron, freeze WordPress to work correctly. Deleting WP-DBManager, or W3 Total Cache, save more cron core sessions, and WordPress seem to work. WP-DBManager is one of my fovorites plugin, and for me work fine. WP-DBManager author GamerZ is a WordPress guru for me. W3 Total Cache is affected to more bugs and security hole. I have 30 WordPress 3.4.2 installation, on vary host, and, for me, all work fine with WP-DBManager + W3 Total Cache. The only problems is when was upgraded to WordPress 3.5 … WP Crontrol is a very importatnt cool plugin!
@ptnplanet
Your analysis is very accurate 🙂
Thanks for those that have posted, thankfully I came across this post without too much trouble finding it.
So what’s the fix? I don’t want to disable either Plugin, that’s why I have them both, because I want them both!
In WP-DB, it’s saying that the MySQL paths do not exist, is this related?
@funkster
it’s saying that the MySQL paths do not exist, is this related?
Paths do not exist, if database is not hosted on the same machine of hosting files 😉 (godaddy for example)
So what’s the fix? I don’t want to disable either Plugin, that’s why I have them both, because I want them both!
I’m just doing my database backups manually until it gets fixed. To me, it’s not worth downgrading any of the software and re-introducing the (now fixed) vulnerabilities.
I’ve disable database cache on my w3 total cache setting.
“I’ve disable database cache on my w3 total cache setting.” Thanks – I’ve done the same – cron jobs now OK.
Well I’m on 3.4, not even 3.5, and W3TC has disabled all cron functions, including backups and scheduled posts.
Thanks ptnplanet for pinpointing the issue.
Disabling functionality on a Plugin is not the solution I’m looking for. I want to retain full functionality on all Plugins.
This is meant to be a Support forum, so where is the developer’s support or are we saying it’s a WordPress issue?
@ptnplanet is right. You can set up a cron on your server to call WP Cron if you find this issue happen. This mostly happens to users with users on shared hosting that don’t have a lot of WP Admin usage or comments. In those cases database caching in particular to disk specifically is not going to provide benefits and should be disabled.
Hi Frederick,
Thanks for dropping in. I’m on a VPN, what would you advise here?
For Info,
ENABLED – Page, Minify, Object, Browser, CDN
DISABLED – Database, Varnish, Cloudfare
I’m not clear on what my solution is.
