[Django] #37155: Allow templatetag `querystring` to start from an empty state

2 views
Skip to first unread message

Django

unread,
Jun 10, 2026, 4:56:50 AMJun 10
to django-...@googlegroups.com
#37155: Allow templatetag `querystring` to start from an empty state
-------------------------------------+-------------------------------------
Reporter: Sjoerd Job Postmus | Type: New
| feature
Status: new | Component: Template
| system
Version: 6.0 | Severity: Normal
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
The documentation for `querystring` starts with

> Outputs a URL-encoded formatted query string based on the provided
parameters.

But the current functionality is mostly limited to taking an existing
mapping; modifying that in-place, and *then* rendering that as a
querystring. (it defaults to `request.GET` if no mapping is provided).

When constructing an update for the querystring of the current view; this
feels natural. When constructing the querystring of a different view
(e.g.: a detail page where an attribute is rendered as a clickable link to
some list filtered by that value), the current querystring is not
relevant.

Use-case:

Instead of writing

{{{
<a href="{% url 'product_list' %}?vendor={{ vendor.pk|unlocalize}}">{{
vendor.name }}</a>
}}}

I would like to be able to write

{{{
<a href="{% url 'product_list' %}{% querystring None vendor=vendor.pk
%}">{{ vendor.name }}</a>
}}}

(Note; the savings will be a lot better if there is more than 1
querystring parameter)

The change to the `querystring` would be reasonable minimal; and it would
unlock an easier way of writing querystrings in more scenarios than
currently available.

A workaround may be to create an empty dictionary, and provide that either
via the context or a contextprocessor; but I feel that's less natural than
just being able to write 'None' for starting with an empty dictionary.

If accepted; I would be happy to pick up the development.
--
Ticket URL: <https://code.djangoproject.com/ticket/37155>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

Django

unread,
Jun 10, 2026, 6:22:35 PMJun 10
to django-...@googlegroups.com
#37155: Allow templatetag `querystring` to start from an empty state
-------------------------------------+-------------------------------------
Reporter: Sjoerd Job Postmus | Owner: (none)
Type: New feature | Status: closed
Component: Template system | Version: 6.0
Severity: Normal | Resolution:
| needsnewfeatureprocess
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by Natalia Bidart):

* resolution: => needsnewfeatureprocess
* status: new => closed

Comment:

Thanks for the report and the detailed write-up. The use case is
understandable, but this is a new feature rather than a bug, and the bar
for extending built-in template tags is high, especially when the same
result is achievable at the project level with very little code. A custom
template tag wrapping `querystring` without the `request.GET` default is
trivial to write using `simple_tag`:

{{{#!python
from django.template.defaulttags import querystring

@register.simple_tag(takes_context=True)
def clean_querystring(context, **kwargs):
return querystring(context, {}, **kwargs)
}}}

This reuses `querystring` entirely and can be tailored to each project's
naming and behavior preferences. Marking as `needsnewfeatureprocess`, if
there is broader community interest, please shepherd this through the new
feature ideas GitHub project per the contributing guidelines
(https://docs.djangoproject.com/en/dev/internals/contributing/bugs-and-
features/).
--
Ticket URL: <https://code.djangoproject.com/ticket/37155#comment:1>
Reply all
Reply to author
Forward
0 new messages