Introduction

WordPress object caching stores database query results, computed data, and frequently accessed content in a fast backend store. By default, WordPress uses a non-persistent in-memory cache that lasts only for the current request. Persistent object caches—using Redis, Memcached, or database-backed solutions—store cached objects across requests, dramatically reducing database load and improving page load times.

When object caching stops working, WordPress falls back to querying the database for every piece of content, taxonomy term, option value, and transient. Sites that previously served pages in milliseconds suddenly take seconds to load as database queries pile up. The symptoms range from slow admin panels to complete site timeouts under moderate traffic. Understanding how WordPress interacts with object cache backends—and where the integration can break—is essential for diagnosing caching failures.

Object cache integration happens through the wp-content/object-cache.php drop-in file, which WordPress loads early in the bootstrap process. This file intercepts all cache operations and routes them to the configured backend. If this file is missing, corrupted, or the backend is unreachable, WordPress silently falls back to the default non-persistent cache, often without obvious error messages.

Symptoms

When WordPress object cache is not working, you will observe these symptoms:

  • Page load times increase significantly compared to cached baseline
  • Database query count spikes on every page load (check with Query Monitor plugin)
  • Redis or Memcached server shows no activity or empty keys
  • WordPress admin panel becomes slow, especially on pages with many options
  • Transients are not persisting across requests
  • Cache-related plugins report backend connection failures
  • Server CPU and database load increase without corresponding traffic increase
  • Query Monitor shows repeated identical queries that should be cached

Common indicators in WordPress debugging:

``` # Query Monitor showing high query count Queries: 523 queries in 2.3 seconds # Expected with working cache: <50 queries

# Debug log entries PHP Warning: Redis server went away in /wp-content/object-cache.php PHP Error: Memcached connection failed in /wp-content/object-cache.php

# Object cache status check wp cache status # Output: Not connected or No persistent cache detected ```

Redis CLI showing empty or missing WordPress keys:

bash
redis-cli keys "*wp*"
# Expected: hundreds of keys
# Actual: (empty list)

Common Causes

Several factors cause WordPress object cache failures:

  1. 1.Object cache drop-in file missing: The wp-content/object-cache.php file that bridges WordPress to the cache backend is deleted, corrupted, or not installed. WordPress silently falls back to internal cache.
  2. 2.Cache backend unreachable: Redis or Memcached server is offline, firewall-blocked, or the connection configuration is wrong (host, port, password).
  3. 3.Connection credentials changed: After server migration or credential rotation, the object cache plugin still uses old connection parameters stored in wp-config.php or plugin settings.
  4. 4.Cache backend authentication failure: Redis requires AUTH password but WordPress configuration doesn't include it, or password is incorrect.
  5. 5.Object cache plugin deactivated: The plugin that configured the persistent cache (Redis Object Cache, W3 Total Cache, etc.) was deactivated or removed without cleaning up the drop-in file.
  6. 6.Cache backend memory exhaustion: Redis or Memcached runs out of allocated memory, evicting keys or rejecting new writes.
  7. 7.Network connectivity issues: Firewall rules, DNS problems, or network partitions prevent WordPress from reaching the cache server.
  8. 8.PHP extension missing: Required PHP extensions (redis, memcached) are not installed or not loaded, preventing backend connections.

Step-by-Step Fix

Follow these steps to diagnose and resolve WordPress object cache issues:

Step 1: Verify object cache drop-in exists

Check the critical drop-in file:

```bash # Check if object-cache.php exists ls -la wp-content/object-cache.php

# Check file contents head -20 wp-content/object-cache.php

# If file exists, check if it's valid PHP php -l wp-content/object-cache.php ```

Expected file existence and valid content:

``` -rw-r--r-- 1 www-data www-data 4532 Jan 15 10:30 wp-content/object-cache.php

# File should contain connection configuration and cache implementation ```

If file is missing:

```bash # For Redis Object Cache plugin wp plugin install redis-cache --activate wp redis enable

# Or manually create by installing plugin through admin # Plugins > Add New > Search "Redis Object Cache" > Install > Activate # Then: Settings > Redis > Enable Object Cache ```

Step 2: Check cache backend connectivity

Test connection to Redis or Memcached:

```bash # For Redis - test connection redis-cli -h your-redis-host -p 6379 ping # Expected: PONG

# If Redis requires password redis-cli -h your-redis-host -p 6379 -a yourpassword ping

# For Memcached telnet memcached-host 11211 # Connected, type: stats # Expected: statistics output

# Check if WordPress can reach the backend wp eval "echo wp_cache_get('test_key', 'test_group');" ```

Connection failure output:

``` redis-cli -h redis.example.com ping # Could not connect to Redis at redis.example.com:6379: Connection refused

telnet memcached-host 11211 # telnet: Unable to connect to remote host: Connection refused ```

Step 3: Verify cache configuration in wp-config.php

Check cache backend configuration:

```bash # View Redis configuration grep -E "WP_REDIS|REDIS" wp-config.php

# View Memcached configuration grep -E "MEMCACHED|WP_CACHE" wp-config.php ```

Expected Redis configuration:

php
define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_PASSWORD', 'your-password');
define('WP_REDIS_DATABASE', 0);
define('WP_CACHE', true);

If configuration is missing or wrong:

```bash # Add Redis configuration to wp-config.php (before "stop editing" line) # Edit wp-config.php vim wp-config.php

# Add these lines: define('WP_REDIS_HOST', 'your-redis-host'); define('WP_REDIS_PORT', 6379); define('WP_REDIS_PASSWORD', 'your-password'); define('WP_REDIS_DATABASE', 0); define('WP_CACHE', true); ```

Step 4: Check PHP extensions

Verify required PHP extensions are installed:

```bash # Check Redis extension php -m | grep redis

# Check Memcached extension php -m | grep memcached

# For PHP-FPM specific php-fpm -m | grep redis

# Check extension details php -i | grep -A5 "redis" ```

If extension missing:

```bash # Install Redis extension (Ubuntu/Debian) apt-get install php-redis systemctl restart php-fpm

# Install Memcached extension apt-get install php-memcached systemctl restart php-fpm

# Verify installation php -m | grep redis ```

Step 5: Check cache backend server status

Verify the cache server is running:

```bash # Redis server status systemctl status redis # Or systemctl status redis-server

# Check Redis memory usage redis-cli info memory

# Check Redis stats redis-cli info stats

# Memcached server status systemctl status memcached ```

Redis memory exhaustion indicators:

bash
used_memory: 104857600
maxmemory: 104857600
maxmemory_policy: allkeys-lru
evicted_keys: 5000  # Keys being evicted - possible issue

Step 6: Flush and rebuild cache

Reset the cache if corrupted:

```bash # Flush Redis cache redis-cli FLUSHALL # Or specific database redis-cli -n 0 FLUSHDB

# Flush via WordPress CLI wp cache flush

# Rebuild object cache wp redis enable

# For Memcached echo "flush_all" | nc localhost 11211 wp cache flush ```

Step 7: Test cache functionality

Verify cache is working after fixes:

```bash # Set a test value wp eval "wp_cache_set('test', 'hello', 'testgroup', 3600);"

# Retrieve test value wp eval "echo wp_cache_get('test', 'testgroup');" # Expected output: hello

# Check via Redis directly redis-cli GET "wp:testgroup:test" # Expected: serialized value

# Use Query Monitor to verify queries drop # Install Query Monitor plugin wp plugin install query-monitor --activate ```

Step 8: Check for plugin conflicts

Identify conflicting cache plugins:

```bash # List all cache-related plugins wp plugin list | grep -E "cache|redis|memcached|object"

# Deactivate conflicting plugins wp plugin deactivate w3-total-cache --skip-dependencies

# Keep only one object cache plugin active wp plugin activate redis-cache ```

Multiple cache plugins can conflict by writing conflicting drop-in files:

```bash # Check for multiple drop-ins ls -la wp-content/object-cache*.php

# Remove conflicting files (keep correct one) rm wp-content/object-cache.php.bak ```

Verification

After fixing object cache, verify it works correctly:

```bash # Test cache hit/miss via CLI wp cache set verify-test "working" test-group wp cache get verify-test test-group # Expected: working

# Check Redis keys redis-cli keys "*wp*" # Expected: List of WordPress cache keys

# Monitor Redis during page load redis-cli monitor # Navigate to site in browser # Expected: Continuous SET/GET operations

# Check Query Monitor for reduced queries # Visit site with Query Monitor active # Expected: Significant reduction in duplicate queries

# Check object cache status wp redis info # Expected: Status: Connected, Database: 0, Keys: [count] ```

Performance comparison:

```bash # Before fix curl -w "%{time_total}" -o /dev/null -s https://yoursite.com/ # Output: 2.5 seconds

# After fix curl -w "%{time_total}" -o /dev/null -s https://yoursite.com/ # Output: 0.3 seconds ```

Prevention

To prevent WordPress object cache failures:

  1. 1.Monitor cache backend health: Set up monitoring for Redis/Memcached uptime and memory usage.
bash
# Simple monitoring script
#!/bin/bash
REDIS_STATUS=$(redis-cli ping)
if [ "$REDIS_STATUS" != "PONG" ]; then
    echo "Redis offline" | mail -s "Cache Alert" admin@example.com
fi
  1. 1.Document cache configuration: Keep configuration documented for quick recovery.
markdown
## Object Cache Configuration
- Backend: Redis
- Host: redis.internal:6379
- Password: stored in secrets manager
- Plugin: Redis Object Cache v2.0
- Drop-in: wp-content/object-cache.php
  1. 1.Use connection pooling: For high-traffic sites, use persistent connections to reduce overhead.
php
define('WP_REDIS_USE_PERSISTENT_CONNECTIONS', true);
  1. 1.Set appropriate memory limits: Configure Redis/Memcached with adequate memory.
bash
# Redis configuration
maxmemory 256mb
maxmemory-policy allkeys-lru
  1. 1.Validate after plugin updates: After updating cache plugins, verify connectivity.
bash
wp plugin update redis-cache
wp redis info
wp cache flush
  1. 1.Backup drop-in file: Keep a backup of working object-cache.php.
bash
cp wp-content/object-cache.php wp-content/object-cache.php.backup
  1. 1.Use failover configuration: Configure multiple cache backends for redundancy.
php
define('WP_REDIS_SERVERS', [
    ['host' => 'redis-primary', 'port' => 6379],
    ['host' => 'redis-secondary', 'port' => 6379],
]);

Related Articles

  • [WordPress troubleshooting: Fix Child Theme Not Enqueuing Parent Styles Correc](child-theme-not-enqueuing-parent-styles-correctly)
  • [Fix Database Connection Error Custom Socket Path Issue in WordPress](database-connection-error-custom-socket-path)
  • [Fix Debug Log Growing Deprecated Warnings Notices Issue in WordPress](debug-log-growing-deprecated-warnings-notices)
  • [Fix Fix Contact Form Not Sending On Wordpress Site Issue in WordPress](fix-contact-form-not-sending-on-wordpress-site)
  • [Fix Fix Open Basedir Restriction Blocking Wordpress Issue in WordPress](fix-open-basedir-restriction-blocking-wordpress)

<script type="application/ld+json"> { "@context": "https://schema.org", "@type": "TechArticle", "headline": "WordPress Object Cache Not Working", "description": "WordPress not caching when object cache backend unreachable or misconfigured.", "url": "https://www.fixwikihub.com/fix-wordpress-object-cache-not-working", "publisher": { "@type": "Organization", "name": "FixWikiHub", "url": "https://www.fixwikihub.com" }, "author": { "@type": "Person", "name": "FixWikiHub Editorial Team" }, "datePublished": "2026-01-23T03:00:02.078Z", "dateModified": "2026-01-23T03:00:02.078Z" } </script>