#1675 closed defect (worksforme)
application-specific templatetags aren't loaded
Reported by: | shs | Owned by: | Adrian Holovaty |
---|---|---|---|
Component: | Template system | Version: | |
Severity: | normal | Keywords: | templatetags load INSTALLED_APPS |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | yes | UI/UX: | yes |
Description
The documentation for custom templatetags http://www.djangoproject.com/documentation/templates_python/#extending-the-template-system states that you can add a templatetags module to your app. If I understand the doc correctly, a {% load xyz %} tag will look for the library in myapp/templatetags/xyz.py and load it. The implementation doesn't do that, however, it only looks in django.templatetags and none of the application directories.
There are some old tickets on this, such as ticket:288 and ticket:86, but these have been closed as invalid. Not sure why, though, because the documentation still says it should work and it seems like a useful feature.
Attachments (1)
Change History (10)
by , 19 years ago
Attachment: | ticket_1675.diff added |
---|
comment:1 by , 19 years ago
It works exactly as documented for me (except that 'from django.core import template
' is now 'from django import template
' in m-r. I presume that the code that implements this is in django/templatetags/__init__.py
comment:2 by , 19 years ago
Resolution: | → worksforme |
---|---|
Status: | new → closed |
comment:3 by , 19 years ago
Resolution: | worksforme |
---|---|
Status: | closed → reopened |
On a fresh checkout of m-r, using identical imports to the built-in templatetag library, I'm getting the same error -- Django is only looking in 'django.templatetags' and not in any of the installed apps.
comment:4 by , 19 years ago
On further examination, the admin templatetags get loaded just fine, but templatetags in my own apps don't. Need to dig into it further.
comment:5 by , 19 years ago
My problem turned out to be completely unrelated; tag libraries do work as advertised, so long as you create them according to the docs (I had a subtle problem that I didn't catch until I was knee-deep in the template system).
But... exploring this brought some un-removed magic to my attention. For details, see this thread on django-developers: http://groups.google.com/group/django-developers/browse_thread/thread/f9aec919b1449539/6b5b90659b4186ce#6b5b90659b4186ce
comment:6 by , 19 years ago
Resolution: | → worksforme |
---|---|
Status: | reopened → closed |
Closing this because it works as documented.
comment:7 by , 13 years ago
Easy pickings: | unset |
---|---|
UI/UX: | unset |
In case anyone is still paying attention, my experience is that it appears to only look in the admin dirs until you restart the server. When I created a module using the dev server, it didn't find the templatetags module UNTIL I had restarted the dev server. Not sure what your policy is on this, but I think it should be either fixed or clearly stated in the documentation at the location where tag module creation is described.
comment:8 by , 13 years ago
Easy pickings: | set |
---|---|
UI/UX: | set |
comment:9 by , 13 years ago
agh - just saw that this is an incredibly old bug - I'll post elsewhere for django 1.3
fix for magic-removal branch. This implementation uses the settings.INSTALLED_APPS list to generate the search path for custom template tags