Cache

The chart can deploy an internal Dragonfly instance (which serves both Redis and Memcached protocols simultaneously) or connect to an external cache server.

wordpressConfigureCache configures, it does not install. Since 7.1.0-9 the cache configuration script only runs when W3 Total Cache is the active caching plugin; on sites running a different caching plugin it logs and exits, touching nothing — activating a second page cache would fight over the advanced-cache.php/object-cache.php drop-ins. To install and activate W3TC declaratively, list it in wordpressPreinstallPlugins.

Every release gets its own cache key space. W3 Total Cache prefixes its keys with an instance id it stores in wp-content, so a site copied from another one would share keys with its original on the same cache server. Since 7.1.4-5 the configuration script sets the id on every start, derived from namespace and release name; wordpressCacheInstanceId sets it explicitly.

Internal Cache

memcached:
  enabled: true
  image: "docker.dragonflydb.io/dragonflydb/dragonfly:v2.0.0"
  password: "cachepass"
  persistence:
    enabled: true
    size: 1Gi

wordpressConfigureCache: true
externalCache:
  type: redis  # or memcached - determines which protocol to use

External Cache

memcached:
  enabled: false

externalCache:
  type: redis        # or memcached
  host: redis.example.com
  port: 6379

wordpressConfigureCache: true

Cache authentication

The bundled Dragonfly always starts with --requirepass, and its password is handed to the cache plugin automatically — nothing to configure.

An external cache needs the password spelled out. Redis with requirepass fails every cache operation without it:

externalCache:
  type: redis
  host: redis.example.com
  port: 6379
  password: ""                       # or:
  existingSecret: ""                 # name of a secret you manage
  existingSecretPasswordKey: cache-password

The password reaches the plugin through an environment variable sourced from a Secret. It is deliberately never templated into the post-init ConfigMap: a ConfigMap is readable by anyone with read access to ConfigMaps in the namespace, and a password there is a disclosure that does not look like one in a diff. The chart's template test enforces this with a sentinel value.

Page cache and WP_CACHE

WordPress only loads the page cache drop-in wp-content/advanced-cache.php when the WP_CACHE constant is true. Without it, every page cache plugin — W3 Total Cache, WP Rocket, LiteSpeed Cache — installs its drop-in and then silently never uses it.

Those plugins normally write the constant into wp-config.php themselves. That does not hold here: the init container writes wp-config.php anew for every pod, so a plugin-written constant is gone with the next pod (a rollout, or a pod that is rescheduled or deleted), and the page cache quietly stops working until someone touches the plugin's settings again. The chart therefore owns the constant:

wordpressWpCache: true     # null (default) follows wordpressConfigureCache

Leave it unset when using the bundled wordpressConfigureCache integration — it follows along. Set it explicitly when running a different page cache plugin without that integration, or to force page caching off regardless.

Note the same regeneration applies to any other constant a plugin writes into wp-config.php. If you depend on one, put it in wordpressExtraConfigContent rather than relying on the plugin's edit to persist. Released chart versions up to 7.1.408 do not read that value; there, set the environment variable WORDPRESS_CONFIG_EXTRA through extraEnvVars.