Stale Page Cache After Chunk Edit in ModX 2.7

Short answer

No — not reliably. In ModX 2.7, saving a chunk clears the chunk's own cache entry, but the automatic "Cache Clearing on Resource Save" logic only invalidates the resource being saved and the direct dependencies recorded when that resource was parsed. Resources that pull the chunk indirectly — through a snippet such as [[getChunk]], a pdoResources call with a chunk template, or custom PHP — keep their previously rendered page cache until those resources are re-saved or the cache is cleared manually. If you want certainty after a chunk edit, clear the cache manually (Manager → Clear Cache, or delete the relevant files under core/cache/).

Confirmed vs. likely behavior

Confirmed by design: the filesystem cache stores one file per resource/context. Editing a chunk does not delete those per-resource files, and dependency tracking is built at parse time for the saved element only. Indirect references are invisible to that tracker.

Likely (environment-dependent): whether you ever see staleness depends on your cache handler and any third-party plugins. The default filesystem handler has no atomic replacement or file locking, so a request can read a cache file while another process is writing it. Under low traffic this window is tiny; under high concurrency you can serve a partially written or stale version. Database, Memcached, or APC handlers have different write semantics, so the race profile changes with the handler.

What to do for your case

1. After editing a widely used chunk, clear the full cache from the Manager rather than relying on automatic clearing. For scripted deployments, clear via the cache manager API or remove the resource cache partition.
2. If you use snippets that render chunks, consider calling them uncached ([[!snippetName]]) for content that changes often, accepting the per-request cost.
3. Audit installed plugins for OnCacheUpdate / OnBeforeSave listeners that might suppress or alter core clearing behavior.

Verifying on your install

# After saving a chunk, check whether resource cache files changed
ls -l --time-style=full-iso core/cache/resource/ | head -20

If timestamps on resources known to use the chunk are unchanged, they were not purged. You can also enable the debug system setting and watch the error log for cache-clear events after a chunk save.

To probe the write/read race, run a loop of requests against one resource while repeatedly saving it via the manager API, and diff the served HTML against the expected output. Any mismatched or truncated responses indicate you are hitting the non-atomic write window.

One detail that changes the recommendation

Which cache handler are you running — the default filesystem handler, or database/Memcached/APC? With the filesystem handler, manual clearing after chunk edits is the safe default. With some alternative handlers or a full-page cache plugin, invalidation may behave differently enough that a targeted clearing strategy (per-partition instead of full flush) becomes practical.