Deployment strategies for WP-Supercache [closed]

by

I’m looking to improve my deployment process, which currently uses Capistrano to deploy from a hosted git repository. For the most part, this is working pretty well.

However, I’m running into problems with deploying WP-Supercache:

  • Activating the WP-Supercache plugin creates a file advanced-cache.php in the wp-content folder that includes an absolute (and server specific path) to a file in the WP-Supercache plugin folder.
  • Cache files are stored in wp-content/cache which I’m (correctly) excluding from git.

The searching I’ve done has shown me a couple of possible alternatives for advanced-cache.php

  • Have the deployment task create the advanced-cache.php file each time (through the use of a template).
  • On the initial deployment, have the plugin create the correct file on the server, then move it to a shared folder and have a deployment task that symlinks to it.

For the cache files, the strategy seems to be to move the cache folder to the shared folder and add a deployment task to symlink it.

So, does anyone have a good solution / process for this – doesn’t necessarily need to be Capistrano related, I think this issue surfaces for any deployment that includes WP-Supercache.

1
1

I use WP-SuperCache and since I just use (don’t hack it), then it’s deactivated when I’m on development. I only activate it on production. This might not be quite effective, because you may want to test how caching works on development. However, I found (at least for me) testing in development to be useless since the data and traffic are in the production and not in the development.

So, it might not be an answer, but if you are not doing any hacking for the plugin code, you may want to skip it in development and only activate it in production.

Leave a Comment