Diagnosing Stale Content in Sulu CMS: Indexing and Cache Invalidation

The Problem: Content Updates Not Reflecting on Frontend

A common issue in Sulu CMS environments is the "stale content" phenomenon: an editor saves a change in the admin interface, receives a success notification, but the public-facing website continues to display the old version of the page. This typically indicates a failure in the synchronization chain between the database, the content index, and the HTTP cache layer.

Diagnostic Quick-Reference

Symptom	Likely Cause	Primary Diagnostic Tool
Content updates after a hard refresh or query string (e.g., ?nocache=1)	HTTP Cache / Reverse Proxy (Varnish/Symfony)	curl PURGE request
Content remains stale regardless of cache-busting	Sulu Content Index out of sync	Sulu CLI Indexer
Content is updated in Admin but not visible to any user	Workflow/Publication Status	Sulu Admin UI

Step-by-Step Diagnostic Workflow

Follow these checks in order to isolate whether the failure is at the application level, the index level, or the infrastructure level.

1. Verify Publication State

Before investigating technical failures, ensure the content is actually live. Sulu utilizes a workflow system where changes may be saved as a draft but not published.

• Open the page in the Sulu Admin UI.
• Check the status badge. If it is marked as Draft, the changes will not be visible on the frontend.
• Action: Click Publish to push the changes to the live environment.

2. Test for HTTP Cache Persistence

If the content is published but still stale, determine if the Symfony HTTP cache or a reverse proxy (like Varnish) is serving a cached version of the page.

Run the following command from your local terminal or server to bypass the cache using a query string:

curl -I "https://your-domain.com/page-url?test=1"

If the response headers indicate the new content is present (or the page renders correctly in a browser with a random query string), the issue is Cache Invalidation. The Sulu application failed to send a PURGE request to the cache layer upon saving.

3. Validate the Content Index

Sulu relies on an index to map content entities to their rendered output. If the index is out of sync, the application will continue to serve the old entity state even if the database is updated.

Check the application logs for indexer errors. Look for timeouts or connectivity issues related to the index storage (e.g., Redis or Elasticsearch). If logs are inconclusive, attempt a manual synchronization.

Resolution Paths

Fix A: Manual Re-indexing

If the content is published but not appearing, force a synchronization of the content index. Run this command from the project root on the application server.

# Run as the web user (e.g., www-data) to avoid permission issues
php bin/console sulu:content:index --full

Risk: On sites with tens of thousands of pages, a full re-index can cause a temporary spike in CPU and database load. Monitor system resources during execution.

Fix B: Manual Cache Purge

If the index is correct but the frontend is stale, manually trigger a purge of the reverse proxy. Replace [CACHE_IP] with your Varnish or Symfony proxy IP.

# Requires PURGE method enabled on the proxy
curl -X PURGE http://[CACHE_IP]/page-url

A successful request should return a 200 OK. If it returns 405 Method Not Allowed, the proxy is not configured to accept PURGE requests from your current IP.

Escalation Criteria

If the above steps do not resolve the issue, the problem likely exists in the infrastructure layer. Escalate to DevOps or System Administration if:

• The sulu:content:index command fails with a connection timeout (indicates Redis/Elasticsearch is down).
• The Symfony cache is cleared via php bin/console cache:clear but the frontend remains stale (indicates a secondary CDN or Load Balancer cache is active).
• The database shows the correct value, but the indexer consistently fails to update the specific entity.

Verification of Fix

To confirm the resolution, perform a three-point check:

1. Database: Verify the entity value in the database matches the intended update.
2. Index: Run the indexer and ensure no errors are thrown.
3. Frontend: Perform a hard refresh (Ctrl+F5) and verify the HTML output matches the database value.