Remove query-{id}-page pagination parameter while searching by samikeijonen · Pull Request #22 · humanmade/query-filter

samikeijonen · 2025-05-02T13:45:46Z

Search does not work on paginated pages, therefor remove it.

This should be OK because search is expected to search from all items, not just from paged items.

Fixes #21.

Search does not work on paginated pages, therefor remove it. This should be OK because search is expected to search from all items, not just from paged items. Fixes humanmade#21.

roborourke

Thanks for this, I think the approach needs a small refinement but otherwise it's great. I've left some comments inline.

roborourke · 2025-11-19T08:14:44Z


-if ( $block->context['query']['inherit'] ) {
-	$query_var = sprintf( 'query-%s', $attributes['taxonomy'] );
-	$page_var = 'page';
-	$base_url = str_replace( '/page/' . get_query_var( 'paged' ), '', remove_query_arg( [ $query_var, $page_var ] ) );
-} else {
+if ( empty( $block->context['query']['inherit'] ) ) {
 	$query_id = $block->context['queryId'] ?? 0;
 	$query_var = sprintf( 'query-%d-%s', $query_id, $attributes['taxonomy'] );
 	$page_var = isset( $block->context['queryId'] ) ? 'query-' . $block->context['queryId'] . '-page' : 'query-page';
 	$base_url = remove_query_arg( [ $query_var, $page_var ] );
+} else {
+	$query_var = sprintf( 'query-%s', $attributes['taxonomy'] );
+	$page_var = 'page';
+	$base_url = str_replace( '/page/' . get_query_var( 'paged' ), '', remove_query_arg( [ $query_var, $page_var ] ) );
 }


This is appears to just be flipping the logic around and not actually changing anything, was it solving something specific?

@roborourke Yeah, not sure what that is :)

Looks like removing pagination while doing the search should happen in view.js.

roborourke · 2025-11-19T08:52:47Z

+	// Remove pagination when performing a search
+	// for your specific pagination format: query-{id}-page
+	const searchParams = url.searchParams;
+	[...searchParams.keys()].forEach(param => {
+		if (param.match(/query-\d+-page/) || param === 'paged') {
+			searchParams.delete(param);
+		}
+	});


I think it should be possible to scope this to the current query loop block as this will reset pagination for all query loops on the page, and they should be able to work independently. E.g. if name === 's' remove the paged param, if name !== 's', remove name.replace( '-s', '-page' ).

kadamwhite · 2026-06-23T20:50:41Z

@samikeijonen Are you interested in refreshing this PR?

roborourke · 2026-09-02T10:07:16Z

Triaging the open PRs — this one is still wanted and still fixes a real bug (#21), so thanks for it and apologies for the wait.

Could you rebase onto main when you get a chance? The branch is ~74 commits behind and, more importantly, build/ was removed from the repository in c1aabe0 — built files are now generated at release time and gitignored. Your branch still carries 5 changed files under build/taxonomy/, which is where the conflicts come from. Dropping those and keeping only the src/taxonomy/view.js change rebases cleanly; I tried it locally and there are no source conflicts.

A few review notes while you're in there:

Anchor the regex. param.match( /query-\d+-page/ ) is unanchored, so it also matches anything merely containing that pattern. /^query-\d+-page$/ is what's meant.
query-page is missed. render.php falls back to a page var with no ID when the block has no queryId in context:
```
$page_var = isset( $block->context['queryId'] ) ? 'query-' . $block->context['queryId'] . '-page' : 'query-page';
```
\d+ won't match that, so the bug survives in that case. Something like /^query-(\d+-)?page$/ covers both.
It clears pagination for every loop on the page, not just this one. The search action was deliberately scoped to the block's own context ("Scope search to block context so multiple searchable query loops may coexist"), so stripping all query-*-page params resets unrelated loops further down the page. Since updateURL() already receives the field's name, the loop ID can be derived from it and only that loop's page var removed — with paged/page handled for the inherited case.
Pretty permalinks. For an inherited query, pagination can live in the path (/page/2/) rather than a query param. render.php strips that server-side when building $base_url, but updateURL() builds from the form action, so the path segment can survive. Worth stripping /page/N/ from url.pathname too.
Minor: the repo follows WordPress spacing (if ( foo ), [ ...bar ]) — npm run lint:js will flag the added lines.

None of that is blocking in spirit; if you'd rather just rebase and drop the build/ files, we can take the regex and scoping refinements in a follow-up. If you'd prefer not to pick it back up, say so and we'll carry it forward from your commit with credit.

Generated by Claude Code

@samikeijonen

The search block's form action is built from the current URL, so the pagination parameter the pagination block wrote is carried into the search. Searching from page 2 asks for page 2 of the matches, and a term with only one page of results renders an empty loop over results that do exist. Remove the loop's page parameter from the action, named as core names it so the parameter the pagination block wrote is the one that gets dropped. The taxonomy filter already resets pagination this way. Reported and first fixed by @samikeijonen in #22, which resets the same parameter on the JS side. Props samikeijonen. Fixes #21 Co-authored-by: Sami Keijonen <1820415+samikeijonen@users.noreply.github.com> Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Lj871x28S1DXjoVm7AB4k5

roborourke · 2026-09-02T11:39:15Z

Thanks for this, and sorry it sat for so long — the diagnosis was right and the report in #21 was spot on.

We've gone with #59, which drops the same parameter from the search block's form action rather than in updateURL(), so a native form submit with JS disabled gets the reset too. Your commit is credited in it (props @samikeijonen), and #21 is fixed by that PR.

Closing in favour of #59. Much appreciated.

Generated by Claude Code

samikeijonen · 2026-09-04T09:36:11Z

@roborourke Great to hear!

Remove query-{id}-page pagination parameter while searching

8095c85

Search does not work on paginated pages, therefor remove it. This should be OK because search is expected to search from all items, not just from paged items. Fixes humanmade#21.

roborourke reviewed Nov 19, 2025

View reviewed changes

roborourke mentioned this pull request Sep 2, 2026

Allow multiple choices using checkboxes #20

Closed

roborourke mentioned this pull request Sep 2, 2026

Drop the loop's page parameter when a search runs #59

Merged

roborourke closed this Sep 2, 2026

Navigation Menu

Uh oh!

Remove query-{id}-page pagination parameter while searching - #22

Remove query-{id}-page pagination parameter while searching#22
samikeijonen wants to merge 1 commit into
humanmade:mainfrom
samikeijonen:fix/search-on-pages

samikeijonen commented May 2, 2025

Uh oh!

roborourke left a comment

Uh oh!

roborourke Nov 19, 2025

Uh oh!

samikeijonen Nov 20, 2025

Uh oh!

roborourke Nov 19, 2025

Uh oh!

kadamwhite commented Jun 23, 2026

Uh oh!

roborourke commented Sep 2, 2026

Uh oh!

roborourke commented Sep 2, 2026

Uh oh!

samikeijonen commented Sep 4, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

samikeijonen commented May 2, 2025

Uh oh!

roborourke left a comment

Choose a reason for hiding this comment

Uh oh!

roborourke Nov 19, 2025

Choose a reason for hiding this comment

Uh oh!

samikeijonen Nov 20, 2025

Choose a reason for hiding this comment

Uh oh!

roborourke Nov 19, 2025

Choose a reason for hiding this comment

Uh oh!

kadamwhite commented Jun 23, 2026

Uh oh!

roborourke commented Sep 2, 2026

Uh oh!

roborourke commented Sep 2, 2026

Uh oh!

samikeijonen commented Sep 4, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants