Is your feature request related to a problem? Please describe.
This issue is related to the pagination URLs generated. The pagination for the modules is always generated in order with an internal loop counter, so a posts module that comes first will get the pretty /page/2/ permalinks and any module that comes after will get the ugly /paged-2/2/ permalinks.
I have built many sites that use a posts carousel in the banner or a blog index page with a featured posts row that only appears at the top of the first page. These modules don't use pagination, but then the main query for the blog which does have pagination uses the ugly generated permalinks. And if going from one page to another, if the visibility of an earlier query module changes, then the permalinks also change because the loop count is different for that layout.
This also makes it difficult to write hooks because there are two page query vars to consider: page and paged.
Describe the solution you'd like
There are a couple of ways to go about this. Maybe modules that use the "main query" should automatically use the pretty /page/2/ permalinks and all custom queries, acf relationships, etc. use the /paged-2/3/ permalinks. It's not likely that there will be multiple "main query" modules on a given template.
Another solution would be to only increase the loop counter for instances where the pagination setting is not none, so even if a module is using main query or a custom query it can get the pretty permalinks if it's the first one with pagination settings enabled in that layout.
A less elegant solution would be to add an additional setting in query modules that indicate this pagination is the "primary" one and it ignores the loop counter.
Describe alternatives you've considered
I have attempted to manually override the internal loop_count from the start, then have my desired module reset it back to 0 and restore the count right after, but this was very tricky to get the timing right and get inconsistent results.
I have since resorted to using hard-coded pagination HTML on the blog indexes and implementing non-post based modules if they appear before my main posts query.
Is your feature request related to a problem? Please describe.
This issue is related to the pagination URLs generated. The pagination for the modules is always generated in order with an internal loop counter, so a posts module that comes first will get the pretty /page/2/ permalinks and any module that comes after will get the ugly /paged-2/2/ permalinks.
I have built many sites that use a posts carousel in the banner or a blog index page with a featured posts row that only appears at the top of the first page. These modules don't use pagination, but then the main query for the blog which does have pagination uses the ugly generated permalinks. And if going from one page to another, if the visibility of an earlier query module changes, then the permalinks also change because the loop count is different for that layout.
This also makes it difficult to write hooks because there are two page query vars to consider: page and paged.
Describe the solution you'd like
There are a couple of ways to go about this. Maybe modules that use the "main query" should automatically use the pretty /page/2/ permalinks and all custom queries, acf relationships, etc. use the /paged-2/3/ permalinks. It's not likely that there will be multiple "main query" modules on a given template.
Another solution would be to only increase the loop counter for instances where the pagination setting is not none, so even if a module is using main query or a custom query it can get the pretty permalinks if it's the first one with pagination settings enabled in that layout.
A less elegant solution would be to add an additional setting in query modules that indicate this pagination is the "primary" one and it ignores the loop counter.
Describe alternatives you've considered
I have attempted to manually override the internal loop_count from the start, then have my desired module reset it back to 0 and restore the count right after, but this was very tricky to get the timing right and get inconsistent results.
I have since resorted to using hard-coded pagination HTML on the blog indexes and implementing non-post based modules if they appear before my main posts query.