Combining autoFilter with request-Based Ditto Sorting and Pagination

When autoFilter and request-based Ditto parameters collide, the clean fix is to separate filtering from sorting concerns instead of trying to force one cached call to do everything.

Catalog pages built with autoFilter and Ditto often hit a wall once sorting, per-page limits, and pagination are added on top. That is a common problem in real catalog builds: request extenders worked the way they wanted only in uncached contexts, while the filter flow depended on a different structure.

Typical setup

[!autoFilter? &parents=`[*id*]` &formTpl=`filterForm` &parseTpl=`runCatalog` &skipFolders=`1`!]

[[Ditto?
    &documents=`[+af.items+]`
    &tpl=`productsTpl`
    &display=`5`
    &paginate=`1`
    &extenders=`request`
]]

The lesson

Once filtering and sorting are both dynamic, it often becomes cleaner to control one of those layers explicitly instead of asking a single cached pipeline to infer every combination correctly.

Recommendation

If the page needs serious filtering, sorting, and paging together, treat it like a dedicated catalog controller flow, even in a legacy Evo project.

Newer post

Preserving the Manual Order of documents in Ditto

If you pass a manual list of resource IDs into Ditto, you often need to keep that custom order instead of letting default sorting rearrange the results.

Older post

Tracking Resource Views in a TV and Sorting Ditto by That Value

If you want “most viewed” listings in Evolution CMS, one practical approach is to store hits in a TV and sort the output by that saved value later.