Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Block Library - Query Pagination Numbers]: Fix first page's link #33629

Open
wants to merge 1 commit into
base: trunk
Choose a base branch
from

Conversation

@ntsekouras
Copy link
Contributor

@ntsekouras ntsekouras commented Jul 22, 2021

Description

Fixes: #32792

paginate_links doesn't use the provided format when the page is 1. This is great for the main query as it removes the extra query params making the URL shorter, but in the case of multiple custom queries is problematic. It results in returning an empty link which ends up with a link to the current page.

A way to address this is to add a fake query arg with no value that is the same for all custom queries. This way the link is not empty and preserves all the other existent query args.

Reference: https://developer.wordpress.org/reference/functions/paginate_links/
$link = str_replace( '%_%', 1 == $n ? '' : $args['format'], $args['base'] ); $link = str_replace( '%#%', $n, $link );

How has this been tested?

  1. In page with many Query Loop blocks with QueryPaginationNumbers blocks check that by clicking another page number first, the pagination link for the first page (1), works as expected.
  2. This can be tested with a single custom Query in a page as well, but it's better to have multiple Query Loop blocks which can be both custom and ones that inherit the global query.

Notes

  1. The issue can be replicated only when we have no other query args, because in that case the link is not empty - thus the hacky approach here to add an empty query arg.

I couldn't find any better alternative so a more elegant solution would be more than welcomed. We could also look at making some changes in core paginate_links but needs more exploration there. For example we could extend the paginate_links filter by passing the current page number ($n) and use this filter in the block??(🤔 ).

@ntsekouras ntsekouras requested a review from WordPress/gutenberg-core Jul 22, 2021
@ntsekouras ntsekouras self-assigned this Jul 22, 2021
@ntsekouras ntsekouras requested a review from ajitbohra as a code owner Jul 22, 2021
*
* @see https://developer.wordpress.org/reference/functions/paginate_links/
*/
$paginate_args['add_args'] = array( 'cst' => '' );

This comment has been minimized.

@youknowriad

youknowriad Jul 22, 2021
Contributor

What does cst stand for here, is it just a random useless param?

This comment has been minimized.

@youknowriad

youknowriad Jul 22, 2021
Contributor

I feel ideally, we should add a dedicated argument/option in paginate_links to disable the default behavior of skipping format. That said, this is fine a stopgap solution.

This comment has been minimized.

@swissspidy

swissspidy Jul 22, 2021
Member

So this causes ?cst to be added to every link? 🤔 Seems a bit unexpected/weird.

Why not just filter paginate_links_output?

Theoretically it could cause some confusion if someone's already using a query arg with this name and expects it to do something else.

Could you perhaps share what the expected output is with this change?

Agreed that this should be fixed with a patch in core.

This comment has been minimized.

@ntsekouras

ntsekouras Jul 22, 2021
Author Contributor

What does cst stand for here, is it just a random useless param?

Yes.

Theoretically it could cause some confusion if someone's already using a query arg with this name

We can change this to whatever. That's why I didn't used a single character, as it would increase those chances. I'm open to any suggestions.

Why not just filter paginate_links_output?

This would require parsing the html string and I'm not sure it worths it and how complicated it can get with other filters having been applied before, to other parts of this html construction. An extra variable in core should be the best solution probably.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

3 participants