Blog Sections Open
Caching News Blocks for High-Load Evolution CMS Projects
A practical caching strategy for news-heavy sites where article lists should refresh only when content changes, not on every request.
News pages create a familiar performance problem: one project may have thousands of records, but most pages only need a handful of “latest news” blocks. Rebuilding those blocks on every request is wasteful.
This article focused on a more deliberate strategy: cache the rendered listing output and invalidate it only when a news resource changes.
The original setup
The example used a dedicated news section structured by month folders and rendered listings with PageNav plus getResources:
[[!PageNav:default=`[[$nocont]]`?
&element=`getResources`
&parents=`[[*id]]`
&depth=`3`
&limit=`9`
&pageLimit=`5`
&sortby=`{"createdon":"DESC"}`
&pageVarKey=`page`
&includeTVs=`1`
&includeContent=`1`
&hideContainers=`1`
&tpl=`NewsPub`
&cache=`true`
]]Key idea
The goal was not to cache every document forever. The goal was to cache only the expensive listing layer and refresh it when editors add or update news items.
Why this still matters
- lists are often more expensive than the article page itself
- editors want fresh content immediately after publishing
- high-load projects need targeted invalidation instead of blind cache clears
That balance between freshness and stability is still one of the most important architectural decisions in CMS work.
Hiding Parse Errors from Public Visitors in Evolution CMS
A small but important production hardening step that keeps parser errors from exposing filesystem paths and internal details to anonymous visitors.
Using Memcached to Speed Up Data-Heavy MODX Projects
A practical introduction to Memcached for older MODX and Evolution CMS installations that need faster object and page-level caching.