generateblocks
generateblocks copied to clipboard
Query loop pagination urls
Description
Pagination on query loop generates query strings for each page such as: https://domain.com/blog/?query-8d7afef8-page=2 https://domain.com/blog/?query-8d7afef8-page=1
Would love to see a way to make these urls more semantic and SEO friendly. ...
Steps for testing
References:
...
Hi @hollytga, thanks for the feedback!
I agree these could be made nicer. Any suggestions for a way to improve them while keeping them unique to their individual Query Loops?
Sorry to chime in here.
I'm not sure about making it more SEO-friendly, but it might be nicer to have something like this:
?gbql={query-loop-id}&page={page-number}
Making the URL path SEO-friendly reads to me like you want pretty URLs, but that's highly unlikely to be possible on something that has the potential of unlimited query parameters.
You'd then get people wanting to define the order of those parameters in the path structure, and that would be an awful user experience.
If it's not too complicated, here's an idea:
I'm assuming that the query strings are set up that way to account for more than one query loop being on a page. What if the pagination URLs default to /blog/page/2/
, /blog/page/3/
, etc. if there is only one query loop on a page (which is probably most use cases)? Only if there happen to be multiple query loops on a page does it fall back on the query string syntax.
If it's not too complicated, here's an idea:
I'm assuming that the query strings are set up that way to account for more than one query loop being on a page. What if the pagination URLs default to
/blog/page/2/
,/blog/page/3/
, etc. if there is only one query loop on a page (which is probably most use cases)? Only if there happen to be multiple query loops on a page does it fall back on the query string syntax.
You've introduced a variable based on the assumption that the most common use case is one query loop per page. This introduces complexity and ambiguity to the (backend) UI and functionality.
I have pages where I use multiple (more than 3) instances of the GenerateBlocks Query Loop block on a single page.
I also have instances where I implement custom filtering, which (obviously) gets appended to the URL as a query string. How would that fit into your example? You have query functionality defined as path parts AND query strings.
Your suggestion just adds a level of complexity for little to no gain in my opinion.
Perhaps the assumption on how it's used is invalid. I guess I'm thinking more along the lines of it may be more rare to have more than one page-enabled query loop on a page. (whether or not that's true, I don't know) So in reality, it would need to detect if there's more than one query loop on a page that has paging controls added. Which makes it more complex. But again, just an idea if it works to clean up the URLs (I like clean, user-friendly URLs where possible).
@seemly, I'm curious how you are using filtering in a way that generates query string parameters. In my (admittedly limited) use of the query loop, I've only ever seen query strings for the paging functionality. Are you referring to somehow allowing each individual website visitor to change the filters on the query loop? Perhaps this is off-topic, but I'm always interested in learning how other people are using things.
This Page uses the Generate Blocks Query Loop block: [redacted]
I added a form for filtering and some custom code to update the query. (This site is still very much in development).
You'll need to make use of generateblocks_query_loop_args
filter hook, and a unique identifying attribute (class/ID) on the block itself to target the desired Query Loop instance.
@seemly, thanks. So you've turned the query loop into a search...that's a neat idea.