Rewriting Ditto Pagination Links Without Breaking the Query String

This scenario came from a common Evolution CMS storefront problem: the pagination links generated by Ditto pointed to one URL pattern, while the actual catalog page lived on another. The visible difference was small, but it was enough to confuse users and make the URL structure look inconsistent.

The practical fix is not to rebuild pagination from scratch. First identify which page should own the paginated list, then make sure the pagination parameter stays attached to that canonical page instead of an outdated alias or an inherited route.

Typical Symptom

The generated link looks like cat.html?c2_start=6, but the page that should receive the request is catalog.html?c2_start=6.

Recommended Approach

• Treat the catalog resource as the single canonical page for the listing.
• Keep Ditto pagination parameters intact instead of renaming or removing them.
• Fix the link source in the pagination template or wrapper, not by adding redirects on every page view.
• After the change, verify that page 1, page 2, and deep pagination all render the same list logic.

What to Check in Practice

• The resource alias used by the pagination template.
• The exact pagination parameter name such as c2_start.
• Whether custom wrappers or placeholder output override the base URL.
• Whether strict URL logic or redirect plugins rewrite the path unexpectedly.

In most cases the safest result is a stable catalog URL plus the original Ditto pagination parameter. That gives you readable links and avoids rebuilding a working paginator for no real benefit.