Troubleshooting

My pages are always MISS

A handful of common causes, in order of likelihood:

1. Cache disabled. Confirm Settings → Speed Boost → Dashboard → Cache enabled is on.
2. Route disabled. Check the matching toggle in Dashboard → Cacheable Routes.
3. Logged-in session. Cache bypasses logged-in customers. Test in a private window.
4. Cart cookie. A non-empty cart cookie also bypasses. Clear the cart.
5. Un-ignored query parameter. A parameter not in the Ignored Query Parameters list disqualifies the request. Add it.
6. Response sets sensitive cookies. Some custom controllers set per-visitor cookies that bypass the cache. Inspect with curl -I.
7. Wrong sales-channel scope on the toggle. Check both global and per-channel settings.

Turn on Core → Settings → Debug Mode to confirm: every cacheable request should now return X-P2Lab-Cache-Status: HIT on the second hit.

My cache fills up but never serves a HIT (Filesystem backend)

The Filesystem backend lives under Shopware’s Symfony cache directory. Two things can break it:

• bin/console cache:clear was called — this wipes the Symfony cache, including ours. Re-warm.
• Different filesystem paths per server — a multi-host setup with the Filesystem backend isn’t shared. Switch to Redis.

Redis backend won’t connect

Check:

• The DSN format — redis://[user[:password]@]host[:port][/db]
• The Redis instance is reachable from the PHP host (telnet host 6379)
• Redis hasn’t run out of memory and rejected new writes
• maxmemory-policy allows eviction (allkeys-lru is typical)
• Cache namespace isn’t colliding with another app on the same Redis (set a unique cacheNamespace)

The plugin logs Redis connection errors to the standard Symfony log.

APCu backend serves stale or misses inconsistently

APCu is per PHP-FPM worker pool. Each pool has its own memory area. Multiple pools = multiple independent caches. Switch to Redis or Filesystem if you need cross-pool consistency.

Also check apc.shm_size — too small and entries are evicted long before TTL.

Warmup is stuck at 0%

The warmup runs on the async message queue. Verify:

bin/console messenger:consume async --time-limit=10

If the command sits idle, the queue isn’t dispatching — check your messenger transport configuration.

If you see warmup messages being processed but the Checked counter doesn’t move, the worker is running but the HTTP requests are failing. Look at Warmup history → Detail for failed URLs and their status codes.

Varnish is not being purged

In order:

1. Confirm Shopware itself is configured for the reverse proxy (shopware.http_cache.reverse_proxy.enabled: true).
2. Confirm xkey vmod is loaded in Varnish.
3. Settings → Speed Boost → Reverse proxy → Enable Varnish Cache must be on.
4. Enable the Reverse Proxy Log and trigger a save in the admin. A row should appear with the purge details.
5. If the log shows the purge but Varnish still serves stale, check Varnish’s xkey configuration — the purge endpoint, the tag matching pattern, etc.

Smart mode invalidates too much / too little

• Too much — usually a bulk import or DAL write that sends a full payload. Smart can’t tell which fields really changed, so it purges as if every tracked field did. Use Precise for bulk imports.
• Too little — your custom field or theme template reads a value the analyzer doesn’t know about. Decorate SmartInvalidationAnalyzer to add the mapping, or fall back to Extended for the affected entity type.

Enable the Invalidation Log to see exactly what each save invalidates.

The dashboard shows the wrong size

For the Filesystem backend, the dashboard uses the actual disk size. For Redis / APCu it uses the value stored in p2lab_cache_entry. After switching backends or after a cache:clear, the metadata can drift.

Fix by running the cleanup task manually:

bin/console scheduled-task:run-single p2lab_cache.cleanup_cache_entries

Then refresh the dashboard.

Logs are huge

The three log tables (p2lab_cache_invalidation_log, p2lab_cache_reverse_proxy_log, p2lab_cache_warmup_failed_url) are pruned automatically after 30 days by scheduled tasks. If they’re growing without bound, confirm:

bin/console messenger:consume scheduler --time-limit=10

If the scheduler isn’t running, the tasks never fire.

Disabling the plugin temporarily

To bypass P2Lab Cache without uninstalling — useful when chasing a bug that may be cache-related:

1. Dashboard → Cache enabled → off
2. Reverse proxy → Enable Varnish Cache → off (so Varnish stops purging based on plugin tags)
3. Optional: bin/console p2lab:cache:clear to drop the existing entries

Re-enable later. No restart required.

Still stuck?

Collect:

• The plugin version (composer show p2lab/cache or Extensions → My extensions)
• The Shopware version
• The cache adapter you chose
• A representative entry from the Invalidation log and Reverse-proxy log
• A response with debug headers (X-P2Lab-Cache-*)

Reach out to your distributor with the bundle. Most issues are resolvable from those five inputs.

Related

• Logs & monitoring
• Smart invalidation deep-dive
• Reverse proxy (Varnish)