With ListPages, there is an urlAttrPrefix attribute, which allows you to name individual ListPages modules so that they can paginate correctly. This also allows you to specify @URL values on a per ListPages module basis.
Problem: When assigning multiple ListPages modules with the same name, this breaks the @URL functionality entirely.
Expected: If there are multiple ListPages modules with the same name, they should all behave the same as each other. They should all paginate identically and collect @URL variables correctly.
Just in case this is by design, and not a bug, there is no warning in the documentation:
To prevent such conflicts use the urlAttrPrefix argument. This prepends a text (unique for each of the modules) to the argument names in the URL. So the …/created_at/2008.7 would become …/prefix_created_at/2008.07. If you can set unique prefixes for each of the ListPages instances you would avoid any conflicts.
The closest thing to a warning is "If you can set unique prefixes for each of the ListPages instances you would avoid any conflicts".
But this, to me, reads more like "if you set the same prefix for each ListPages, then they will experience URL sharing conflict in the same way they did without the urlAttrPrefix in the first place".
Like I said, if this is by design, and not a bug, them the documentation should read something like this:
"Do not set the same urlAttrPrefix on multiple ListPages modules on the same page. Setting the same urlAttrPrefix for multiple ListPages will cause all of the ListPages modules to not detect URLs at all."
Fixed, it was a nasty ListPages caching bug.
Bartłomiej Bąkowski @ Wikidot Inc.
';.;' TeRq (Write PM)