When I’ve run into plugin conflicts in the past, it was often pretty obvious which plugin was at fault. In this case, it was more ambiguous: After debugging, I found that it was WP Super Cache’s
.htaccess file in the root of the
wp-content/cache directory that was adding a
max-age of three seconds to all files in subdirectories of that directory—including
wp-content/cache/autoptimize, where Autoptimize creates its aggregated files.
If you’d like to duplicate the issue, the steps are as follows:
- Install WordPress on an Apache server.
- Install and activate WP Super Cache and Autoptimize.
- Turn on WP Super Cache and set its delivery method to Expert.
WP Super Cache’s Expert delivery method uses
mod_rewrite instead of PHP to serve files, so the plugin generates a
.htaccess file when that delivery method is activated. Inside the file is this line:
Header set Cache-Control 'max-age=3, must-revalidate'
Applied to all files in the cache directory’s subdirectories, it reduces cache time to three seconds. (So if you’re refreshing very quickly, cached versions of your Autoptimize files might be served by your browser the first one or two times before requiring another trip to the server for validation.)
I think ideally WP Super Cache would create its
.htaccess file directly inside each of its own subdirectories, but I suspect that when the decision was made to create that file, no other plugins were creating subdirectories in
wp-content/cache. (And if another plugin was doing so, there was probably an assumption that users wouldn’t run competing caching plugins simultaneously.)
The easiest solution for end users encountering this issue is to change Autoptimize’s cache directory:
define( 'AUTOPTIMIZE_CACHE_CHILD_DIR', '/resources/' );
(That line is taken from Autoptimize’s FAQ and should be added to
wp-config.php; the directory would then be created at
/wp-content/resources/, though you could also use values like
/aggregated/ depending on what you think is appropriate.)