This plug is is incredibly complex and may lead to your site being wiped to dust just by misconfiguring it a litte.
Don’t rush it on a live WP 3.6 site, unless you love to be in a world of hurt.
When will updating be save? Tell me a ~date please.
I updated, currently not having problems with w3….
I updated it as well, it work so far on a shared host website leveraging both Cloudflare CDN and self hosted CDN (doing different things).
Updated a monster machine (sub 2 seconds response time *without caching*) with a Varnish + Nginx + memcached + APC + PHP 5.5 + MySQL 5.6 + WP 3.6 + W3TC setup.
These are the results after upgrading to WP 3.6, it looks like the setup is still OK!
So what are those developers then talking about?
I’m also a W3 Total Cache user who is running it with WordPress 3.6 and haven’t encountered any issues thus far.
The reason for being careful about performing the WordPress upgrade is to give you time to make sure your important plugins will be compatible with the new version. I’ve already seen some of my important plugins get updated to support WordPress 3.6 before I even upgraded WordPress, itself.
SO FAR my W3 Total Cache with WordPress 3.6 experience has been good. 🙂
Peace…
I noticed a performance drop after upgrading to wordpress 3.6. After checking around, I found that w3tc’s database caching with memcached is somewhat broken with wp 3.6.
I’ve got pages running some heavy mysql queries in some pages. W3TC’s page caching takes care of this for non-logged in users. For logged in ones, I rely mainly on database caching since object caching is broken (http://wordpress.org/support/topic/transient-api-not-working-with-object-cache?replies=1) .
After upgrading to wp3.6, I’m experiencing quite some delays accessing these pages, but not others. That’s why I believe database caching is broken.
So in my particular scenario, w3tc is practically off for logged in users.
I’d like to add that before wp3.6, even though the database cache is set to disable for logged in users, w3tc still manage to cache some of them. I’m not sure if it’s a bug or feature. But after 3.6, caching for logged in users are completely disabled.
From where I stand, it looks like I’ll have to implement custom database caching mechanisms outside of wordpress.
I really wish that you guys could fix the object cache feature, and make it work with memcached, because this API is surely one of the best features wordpress has to offer.
Does the developers recognize this thread and are working on a fix (or update for 100% WP 3.6 compatibility? The beta versions were out for a long time for developers to test)
Still no answer from those developers.
I am reverting my installations to the rock solid (for me!) 0.9.2.11, which is perfectly compatible with WP 3.6.
The latest W3 TC version has some open, severe bugs that in my eyes make it not ready for production.
Sh**… just a few minutes ago I updated the plugin to 0.9.3 – how can I test those bugs?
Update: I checked the cached site… using the developer console of chrome: And as far as I can see there are NO duplicate links to css- or js-files. I can see all cached files and those three js-files which I did not want to be minified. So where exactly is the problem?
Or did you mean the newest update 0.9.3 in combination with WP 3.6? I am still using 3.5 here…
