#21303 closed New feature (wontfix)
Allow custom link text for urlize filter
Reported by: | Danilo Bargen | Owned by: | nobody |
---|---|---|---|
Component: | Template system | Version: | dev |
Severity: | Normal | Keywords: | urlize, defaultfilters |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | yes | UI/UX: | no |
Description
My templates usually contain a lot of the following pattern:
<a href="{{ object.url }}">{{ object.name }}</a>
It would be great if there were an optional link_text
argument to the urlize filter:
{{ object.url|urlize:object.name }}
I added a pull request for this here: https://github.com/django/django/pull/1792
The pull request contains the implementation and tests. If you agree to include this in Django, I'll add a commit to this pull request that updates the documentation.
Change History (5)
comment:1 by , 11 years ago
comment:2 by , 11 years ago
Thanks for your comment.
I'm pretty sure that this is by far the most common use case for urlize
customizations. But you might have a point there, because usually when creating URLs with a custom text, you don't want rel="nofollow"
to be there.
Sometimes I miss Jinja's template filters with multiple arguments...
comment:3 by , 11 years ago
I'm also -1 on the idea.
The addition proposed here only makes sense when "urlizing" a single URL but that's not what urlize
is designed for.
Its purpose is to find all the URLs inside a big chunk of text and convert them into clickable <a>
tags.
I think that's reason enough to mark this as wontfix
.
Please reopen this ticket if you have ideas on how to address the criticism raised here.
Thanks.
comment:4 by , 11 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
While this works for your use case, I can imagine someone else may want to customize
urlize
and pass it arguments for a different purpose. For this reason, I think it's better for projects to have their own customized versions ofurlize
rather than for us to include a particular implementation in core. Will leave this open for a bit before making a "won't fix" call to see if anyone else wants to chime in.