Keeping Ditto Pagination Placeholders Working When PHx Is Involved

One of the stranger PHx-era edge cases in Evolution CMS was that adding PHx to a Ditto-driven page could make pagination placeholders disappear entirely. The list rendered, but the paging block vanished.

The symptom

Typical placeholders such as [+previous+], [+next+], and the output created by dittoSplitPagination would stop rendering once PHx entered the page flow.

[!Ditto? &startID=`1` &summarize=`10` &tpl=`mkNewsItem`
   &paginate=`1` &paginateAlwaysShowLinks=`1`
   &sortBy=`pub_date` &sortDir=`DESC` !]

[!dittoSplitPagination!]
[+previous+] [+splitPages+] [+next+]

Why it happened

The issue was not really “Ditto pagination is broken.” It was a parser-order problem. PHx and pagination placeholders were both trying to participate in the final render stage, and under the wrong caching setup the paging placeholders were lost before the page finished rendering.

The practical fix

The workaround from that period was simple and reliable: make the page itself uncached, but let Ditto and dittoSplitPagination stay cached. That preserved the pagination placeholders while avoiding repeated parser collisions.

Why this belongs in the timeline

This tiny case captures a lot of what historical Evolution CMS work felt like: not a huge bug, but a very real parser-order problem that could consume hours. It also explains why many later best practices pushed teams toward lighter template helpers and away from stacking too many parser layers on the same page.

Source

Related Ditto pagination material in this archive

Related posts

SEO-Friendly Pagination URLs for Ditto
Hardening PHx: Placeholder Cleanup and Safer then/else Parsing