Just wanted to comment here and mention we’re seeing the same behavior with “empty cache” – *not* related to minify – causing the settings file at w3tc-config/master.php to be wiped and reduced to something extremely simple. See below for examples. We’ve tried ‘trunk’ (as of Sep 19) and 0.9.4, but nothing previous. We didn’t install W3TC until we were already on WP4, so I can’t say if there’s any correlation there in our case.
If you like I can submit a separate bug report… not sure if there’s value in that as it seems likely to be a dupe.
The effect is that W3TC is reverted to not-configured-at-all status. Restoring this one file from backup seems to work fine. Making changes to the config seems to work fine… only “empty cache” breaks it… and that, not every time. Sometimes it doesn’t break. Seems to be around a 50/50 gamble, though we haven’t measured precisely.
We are using page cache and object cache, both backed by memcache. Flushing all caches or all memcache caches, or either one individually, can all trigger it. There are 2 memcache nodes being used – same 2 nodes for both page and object caching, and they’re also shared by other apps, including other WP installs (that don’t use W3TC). We’re not using minify. WP and wp-content are installed separately on each node in a cluster, and the wp-content/{cache,w3tc-config} directories are shared via an NFS mount. Permissions seem okay to me (apache:apache / 644 on the files, 777 on the cache and w3tc-config dir).
Example master.php configs after a “bad” cache flush. Not sure why the variance…
1)
<?php
return array(
‘version’ => ‘0.9.4’,
‘plugin.type’ => ”,
);
2)
<?php
return array(
‘version’ => ‘0.9.4’,
‘notes.need_empty_pgcache’ => false,
‘notes.plugins_updated’ => false,
);
3)
<?php
return array(
‘version’ => ‘0.9.4’,
‘plugin.type’ => ”,
‘notes.need_empty_pgcache’ => false,
‘notes.plugins_updated’ => false,
);
