<p>You can use the <a href="https://craftcms.com/docs/3.x/dev/functions.html#siteurl" rel="nofollow noreferrer"><code>siteUrl</code> function</a> to modify the pagination URLs and remove the additional query parameter. The function accepts a <code>params</code> hash to specify query params. Passing <code>null</code> for a param makes the function remove it from the URL:</p>
<pre class="lang-twig prettyprint-override"><code>{% paginate newsQuery as newsInfo, newsEntries %}
{% set nextUrl = siteUrl(
    newsInfo.getNextUrl(),
    params = { fetch: null, }
) %}
</code></pre>
<p>Alternatively, you could use <a href="https://craftcms.com/docs/3.x/extend/extending-twig.html" rel="nofollow noreferrer">extend Twig with a custom behaviour or extension</a> to provide the <code>removeParam</code> filter to Twig.</p>

CC BY-SA 4.0
2021-12-10T11:19:49.953Z
Huh, neat, great answer. The null behavior seems undocumented, but it also wasn't clear to me that specifying parameters would maintain the original parameters.
jishi
CC BY-SA 4.0
2021-12-10T11:21:47.090Z
@jishi Yeah, a lot of the fine details are undocumented, in particular the helper methods, so it's a bit of trial and error. If you're uncomfortable using undocumented behaviour, the second approach (extending Twig with the `removeParam` filter) would be a 'cleaner' solution.
MoritzLost
CC BY-SA 4.0
2021-12-10T10:59:49.640Z
2021-12-10T10:59:49.640Z
MoritzLost
<p>I have an implementation of a pagination which uses fetch() to get a subset of the page (i.e the page listing and pagination links), so when switching pages it gets the new list, as well as the pagination to update the available page links etc.</p>
<p>Due to CDN circumstances, I need to trigger this &quot;partial&quot; rendering via a querystring to allow caching this response independently from a full page render (vary by querystring) since the CDN doesn't care about headers for the cache key.</p>
<p>Now, the problem is, that any query string parameters that are passed in the request, will also be added the pagination urls (which, in general is fine, and wanted if those control additional filtering), but I want to exclude one parameter that is only used for triggering the partial rendering, e.g <code>fetch=1</code>.</p>
<p>However, the paginate function doesn't allow this, and I wanted to use the UrlHelper and the <code>removeParam()</code> on the paginate URLs, but I can't figure out how I can access that helper from the view?</p>
<p>To clarify, this is the flow:</p>
<p>page is /news</p>
<p>Pagination urls are: [/news] [/news/p2] [/news/p3]</p>
<p>When clicking on [/news/p2], I will append a query string parameter called <code>fetch=1</code> that returns partial content and new pagination:</p>
<p>page is now /news/p1 (via history.pushState), but fetched /news/p1?fetch=1</p>
<p>Pagination urls are: [/news?fetch=1] [/news/p2?fetch=1] [/news/p3?fetch=1]</p>
<p>I want the urls to be correct, to allow a correct fallback linking (non-fetch).</p>
<p>I can of course do some regex magic on the pagination urls in the template to overcome this, but having correct URL aware parsing would be much cleaner. Having a filter that could parse and remove query string parameters would also be great, like:</p>
<p><code>{{ pagination.nextUrl|removeParam('fetch') }}</code></p>
<p>But I can't find any such builtin filter.</p>

<templating><pagination>
Using UrlHelper from template or remove query string params when paginating?
# Using UrlHelper from template or remove query string params when paginating?

(Asked by: username_0 on 2021-12-10)

I have an implementation of a pagination which uses fetch() to get a subset of the page (i.e the page listing and pagination links), so when switching pages it gets the new list, as well as the pagination to update the available page links etc.

Due to CDN circumstances, I need to trigger this "partial" rendering via a querystring to allow caching this response independently from a full page render (vary by querystring) since the CDN doesn't care about headers for the cache key.

Now, the problem is, that any query string parameters that are passed in the request, will also be added the pagination urls (which, in general is fine, and wanted if those control additional filtering), but I want to exclude one parameter that is only used for triggering the partial rendering, e.g `fetch=1`.

However, the paginate function doesn't allow this, and I wanted to use the UrlHelper and the `removeParam()` on the paginate URLs, but I can't figure out how I can access that helper from the view?

To clarify, this is the flow:

page is /news

Pagination urls are: [/news] [/news/p2] [/news/p3]

When clicking on [/news/p2], I will append a query string parameter called `fetch=1` that returns partial content and new pagination:

page is now /news/p1 (via history.pushState), but fetched /news/p1?fetch=1

Pagination urls are: [/news?fetch=1] [/news/p2?fetch=1] [/news/p3?fetch=1]

I want the urls to be correct, to allow a correct fallback linking (non-fetch).

I can of course do some regex magic on the pagination urls in the template to overcome this, but having correct URL aware parsing would be much cleaner. Having a filter that could parse and remove query string parameters would also be great, like:

`{{ pagination.nextUrl|removeParam('fetch') }}`

But I can't find any such builtin filter.

**Tags:** templating, pagination


---

## 1 answers

### Answer by username_1 on 2021-12-10. Score: 2 | Accepted answer

You can use the siteUrl function to modify the pagination URLs and remove the additional query parameter. The function accepts a params hash to specify query params. Passing null for a param makes the function remove it from the URL:
{% paginate newsQuery as newsInfo, newsEntries %}
{% set nextUrl = siteUrl(
    newsInfo.getNextUrl(),
    params = { fetch: null, }
) %}

Alternatively, you could use extend Twig with a custom behaviour or extension to provide the removeParam filter to Twig.

> **Comments:**
> **username_0**: Huh, neat, great answer. The null behavior seems undocumented, but it also wasn't clear to me that specifying parameters would maintain the original parameters.  
> **username_1**: @username_0 Yeah, a lot of the fine details are undocumented, in particular the helper methods, so it's a bit of trial and error. If you're uncomfortable using undocumented behaviour, the second approach (extending Twig with the `removeParam` filter) would be a 'cleaner' solution.  

---

