In a django template, a call to {{ var }} will silently fail if var is undefined. That makes templates hard to debug. Is there a setting I can switch so django will throw an exception in this case?
The only hint at a solution I've found online is http://groups.google.com/group/google-appengine/browse_thread/thread/86a5b12ff868038d and that sounds awfully hacky.
Django<=1.9
Set TEMPLATE_STRING_IF_INVALID = 'DEBUG WARNING: undefined template variable [%s] not found' in your settings.py.
See docs:
https://docs.djangoproject.com/en/1.9/ref/settings/#template-string-if-invalid
Django>=1.10
Set string_if_invalid = 'DEBUG WARNING: undefined template variable [%s] not found' template option in your settings.py.
See docs: https://docs.djangoproject.com/en/2.0/topics/templates/#module-django.template.backends.django
Also read:
http://docs.djangoproject.com/en/dev/ref/templates/api/#invalid-template-variables
This hack from djangosnippets will raise an exception when an undefined variable is encountered in a template.
# settings.py
class InvalidVarException(object):
def __mod__(self, missing):
try:
missing_str = unicode(missing)
except:
missing_str = 'Failed to create string representation'
raise Exception('Unknown template variable %r %s' % (missing, missing_str))
def __contains__(self, search):
if search == '%s':
return True
return False
TEMPLATE_DEBUG = True
TEMPLATE_STRING_IF_INVALID = InvalidVarException()
Consider using the django-shouty-templates app: https://pypi.org/project/django-shouty-templates/
This app applies a monkeypatch which forces Django’s template language to error far more loudly about invalid assumptions. Specifically:
chef would raise an exception if the variable were called sous_chef.
chef.can_add_cakes would raise an exception if can_add_cakes was not a valid attribute/property/method of chef
It ain’t compile time safety, but it’s better than silently swallowing errors because you forgot something!
I use this pytest-django config:
[pytest]
FAIL_INVALID_TEMPLATE_VARS = True
This way I get an exception if I run the tests.
That's part of the design. It allows you to provide defaults and switch based on whether or not a variable exists in the context. It also allows templates to be very flexible and promotes re-usability of templates instead of a strict "each view must have it's own template" approach.
More to the point, templates are not really supposed to be "debugged". The idea is to put as much of your logic as possible outside the template, in the views or models. If you want to figure out why a variable that's supposed to be passed to the context isn't, the place to debug that is in your view. Just drop import pdb;pdb.set_trace() somewhere before your view returns and poke around.
Related
How can I make Django (1.11) ignore missing variables in template during rendering? I need to render the same template with different data in multiple steps. I need to use the Django template engine for all the features that it includes and I can't modify the templates.
Instead of replacing them with an empty string:
>>> from django.template import Template, Context, TemplateSyntaxError
>>> c = Context({'foo': 'hello'})
>>> t = Template('{{foo}} {{bar}}')
>>> t.render(c)
'hello '
I would like it to just leave them as is
>>> t.render(c)
'hello {{bar}}'
I think string_if_invalid will work for you: https://docs.djangoproject.com/en/1.11/ref/templates/api/#how-invalid-variables-are-handled
Your settings should add something like this:
TEMPLATES = [
{
...
'OPTIONS': {
...
'string_if_invalid': '{{%s}}',
...
},
},
]
You may need to escape the curly braces, but I would be surprised if it didn't do that for you when replacing the string in.
Note that from the docs say:
If string_if_invalid contains a '%s', the format marker will be replaced with the name of the invalid variable.
ALSO note that the docs say:
For debug purposes only!
While string_if_invalid can be a useful debugging tool, it is a bad idea to turn it on as a ‘development default’.
Many templates, including those in the Admin site, rely upon the silence of the template system when a non-existent variable is encountered. If you assign a value other than '' to string_if_invalid, you will experience rendering problems with these templates and sites.
Generally, string_if_invalid should only be enabled in order to debug a specific template problem, then cleared once debugging is complete.
EDIT: The doc's warning is making me a bit wary about using this. Give the above a try for debugging, but I wouldn't rely on it for a production system.
You might want to look into writing a custom template tag: https://docs.djangoproject.com/en/2.1/howto/custom-template-tags/#django.template.Library.simple_tag
It would be defined like this:
#register.simple_tag(takes_context=True)
def preserve_invalid(context, var_name):
return context.get(var_name, '{{%s}}' % var_name)
and used like this:
{% preserve_invalid "some_var" %}
I'm trying to utilize django's row-level-locking by using the select_for_update utility. As per the documentation, this can only be used when inside of a transaction.atomic block. The side-effect of using a transaction.atomic block is that if my code throws an exception, all the database changes get rolled-back. My use case is such that I'd actually like to keep the database changes, and allow the exception to propagate. This leaves me with code looking like this:
with transaction.atomic():
user = User.objects.select_for_update.get(id=1234)
try:
user.do_something()
except Exception as e:
exception = e
else:
exception = None
if exception is not None:
raise exception
This feels like a total anti-pattern and I'm sure I must be missing something. I'm aware I could probably roll-my-own solution by manually using transaction.set_autocommit to manage the transaction, but I'd have thought that there would be a simpler way to get this functionality. Is there a built in way to achieve what I want?
I ended up going with something that looks like this:
from django.db import transaction
class ErrorTolerantTransaction(transaction.Atomic):
def __exit__(self, exc_type, exc_value, traceback):
return super().__exit__(None, None, None)
def error_tolerant_transaction(using=None, savepoint=True):
"""
Wraps a code block in an 'error tolerant' transaction block to allow the use of
select_for_update but without the effect of automatic rollback on exception.
Can be invoked as either a decorator or context manager.
"""
if callable(using):
return ErrorTolerantTransaction('default', savepoint)(using)
return ErrorTolerantTransaction(using, savepoint)
I can now put an error_tolerant_transaction in place of transaction.atomic and exceptions can be raised without a forced rollback. Of course database-related exceptions (i.e. IntegrityError) will still cause a rollback, but that's expected behavior given that we're using a transaction. As a bonus, this solution is compatible with transaction.atomic, meaning it can be nested inside an atomic block and vice-versa.
I have a simple function in Django 1.4 that results in a mail being sent. This is put in a try/except, just in case the mailing service might be down (which is an external dependency).
Now, I would like to test this exception. I thought this would be simple, by overriding some email settings (like settings.EMAIL_HOST or settings.EMAIL_BACKEND) but Django test framework does not cause send_mail() to throw an error even if the backend is configured with jibberish...
So the question is: How do I make send_mail() throw an error in my test case?
Thanks!
Answer:
import mock
class MyTestCase(TestCase):
#mock.patch('path.to.your.project.views.send_mail', mock.Mock(side_effect=Exception('Boom!')))
def test_changed_send_mail(self):
I'm not a testing expert, but I think you should use a send_mail mock that raise the exception you want to test.
Probably you could take a look at this stackoverflow question to know more about mocking in Django.
Yes, the test suite does not set up the email system. Unfortunately, I don't know of any way t o test the email system.
You shouldn't really be testing send_mail functions as it is a built in. That said, you can validate the data being passed into send_mail by another function. If you know the domain of expected inputs, you can verify and throw (raise) an exception of your own.
https://docs.djangoproject.com/en/1.4/topics/email/#the-emailmessage-class
This is the more django'y way to send email:
# attempt to send out a welcome email
try :
t = loader.get_template('email_templates/membership/register.html')
c = Context({
'user' : user,
'site' : Site.objects.get(id=settings.SITE_ID)
})
msg = EmailMessage('Welcome to Site', t.render(c), settings.EMAIL_HOST_USER, to=[user.email,])
msg.content_subtype = "html"
msg.send()
except :
messages.info(request, _(u'Our email servers are encountering technical issues, you may not recieve a welcome email.'))
in my settings.py:
import os
EMAIL_HOST_USER = os.environ['SENDGRID_USERNAME']
EMAIL_HOST= 'smtp.sendgrid.net'
EMAIL_PORT = 587
EMAIL_USE_TLS = True
EMAIL_HOST_PASSWORD = os.environ['SENDGRID_PASSWORD']
note: SENDGRID_USERNAME and SENDGRID_PASSWORD are added as env variables by a heroku addon, you may have the actual credentials embedded in your settings file which is fine.
so why isnt your email throwing exceptions? https://docs.djangoproject.com/en/1.4/topics/email/#django.core.mail.get_connection
The fail_silently argument controls how the backend should handle errors. If fail_silently is True, exceptions during the email sending process will be silently ignored.
The patch documentation at http://www.voidspace.org.uk/python/mock/patch.html#where-to-patch explains in detail how to go about this.
I noted that the answer indeed was in the question but to help others understand where the catch is, the link above will prove to be quite insightful.
If you want to patch an object reference in class b.py, ensure that your patch call mocks the object reference in b.py rather than in a.py from where the object is imported. This can be a stumbling block for java developers who are getting used to the whole idea of functions being 1st class citizens.
How can I ask Django to tell me when it encounters, for example, an undefined variable error while it's rendering templates?
I've tried the obvious DEBUG = True and TEMPLATE_DEBUG = True, but they don't help.
Put this in your debug settings:
class InvalidString(str):
def __mod__(self, other):
from django.template.base import TemplateSyntaxError
raise TemplateSyntaxError(
"Undefined variable or unknown value for: \"%s\"" % other)
TEMPLATE_STRING_IF_INVALID = InvalidString("%s")
This should raise an error when the template engine sees or finds an undefined value.
According to the django documentation,
undefined variables are treated as ''(empty string) by default. While in if for regroup, it's None.
If you are going to identify the variable undefined, change TEMPLATE_STRING_IF_INVALID in settings.
'%s' makes the invalid variable to be rendered as its variable name, in this way, u can identify easily.
how-invalid-variables-are-handled
Finding template variables that didn't exist in the context was important to me as several times bugs made it into production because views had changed but templates had not.
I used this technique, implemented in manage.py, to achieve the effect of breaking tests when template variables not found in the context were used. Note that this technique works with for loops and if statements and not just {{ variables }}.
import sys
# sometimes it's OK if a variable is undefined:
allowed_undefined_variables = [
'variable_1',
'variable_2',
]
if 'test' in sys.argv:
import django.template.base as template_base
old_resolve = template_base.Variable.resolve
def new_resolve(self, context):
try:
value = old_resolve(self, context)
except template_base.VariableDoesNotExist as e:
# if it's not a variable that's allowed to not exist then raise a
# base Exception so Nodes can't catch it (which will make the test
# fail)
if self.var not in allowed_undefined_variables:
raise Exception(e)
# re-raise the original and let the individual Nodes deal with it
# however they'd like
raise e
return value
template_base.Variable.resolve = new_resolve
How to log a warning on undefined variable in a template
It seems that Django relies on undefined variables being a simple empty string. So instead of changing this behaviour or making it throw an exception, let's keep it the same but have it log a warning instead!
In your settings.py file:
TEMPLATES = [
{
'BACKEND': 'django.template.backends.django.DjangoTemplates',
# ...
'OPTIONS': {
# ...
'string_if_invalid': InvalidStringShowWarning("%s"),
},
}
]
(string_if_invalid replaces TEMPLATE_STRING_IF_INVALID in newer Django versions.)
And further up, you'll need to define the InvalidStringShowWarning class, making it behave while logging a warning:
class InvalidStringShowWarning(str):
def __mod__(self, other):
import logging
logger = logging.getLogger(__name__)
logger.warning("In template, undefined variable or unknown value for: '%s'" % (other,))
return ""
def __bool__(self): # if using Python 2, use __nonzero__ instead
# make the template tag `default` use its fallback value
return False
You should be able to see the warning in the output of python manage.py runserver.
I believe that's a major oversight on Django's part and the primary reason I prefer not to use their default template engine. The sad truth is that, at least for now (Django 1.9), you can't achieve this effect reliably.
You can make Django raise an exception when {{ undefined_variable }} is encountered - by using "the hack" described in slacy's answer.
You can't make Django raise the same exception on {% if undefined_variable %} or {% for x in undefined_variable %} etc. "The hack" doesn't work in such cases.
Even in cases in which you can, it is strongly discouraged by Django authors to use this technique in production environment. Unless you're sure you don't use Django's built-in templates in your app, you should use "the hack" only in DEBUG mode.
However, if you're stuck with Django's templates for now, I would recommend to use slacy's answer, just make sure you're in DEBUG mode.
Read up on how invalid variable are handled in templates. Basically, just set TEMPLATE_STRING_IF_INVALID to something in your settings.py.
TEMPLATE_STRING_IF_INVALID = "He's dead Jim! [%s]"
I am use next:
import logging
from django.utils.html import format_html
from django.utils.safestring import mark_safe
class InvalidTemplateVariable(str):
"""
Class for override output that the Django template system
determinated as invalid (e.g. misspelled) variables.
"""
# styles for display message in HTML`s pages
styles = mark_safe('style="color: red; font-weight: bold;"')
def __mod__(self, variable):
"""Overide a standart output here."""
# access to current settings
from django.conf import settings
# display the message on page in make log it only on stage development
if settings.DEBUG is True:
# format message with captured variable
msg = 'Attention! A variable "{}" does not exists.'.format(variable)
# get logger and make
logger = self.get_logger()
logger.warning(msg)
# mark text as non-escaped in HTML
return format_html('<i {}>{}</i>', self.styles, msg)
# on production it will be not displayed
return ''
def get_logger(self):
"""Create own logger with advanced error`s details."""
logger = logging.getLogger(self.__class__.__name__)
logger.setLevel(logging.DEBUG)
handler = logging.StreamHandler()
handler.setLevel(logging.DEBUG)
formatter = logging.Formatter('%(asctime)s - %(name)s - %(levelname)s - %(message)s')
handler.setFormatter(formatter)
logger.addHandler(handler)
return logger
Usage in settings file (by default it settings.py):
TEMPLATES = [
{
......
'OPTIONS': {
.....................
'string_if_invalid': InvalidTemplateVariable('%s'),
.....................
},
},
]
or directly
TEMPLATES[0]['OPTIONS']['string_if_invalid'] = InvalidTemplateVariable('%s')
A result if DEBUG = True:
On page
In console
> System check identified 1 issue (0 silenced). October 03, 2016 -
> 12:21:40 Django version 1.10.1, using settings 'settings.development'
> Starting development server at http://127.0.0.1:8000/ Quit the server
> with CONTROL-C. 2016-10-03 12:21:44,472 - InvalidTemplateVariable -
> WARNING - Attention! A variable "form.media" does not exists.
You can use the pytest-django setting FAIL_INVALID_TEMPLATE_VARS
The invaild vars get checked if pytest executes the code.
[pytest]
DJANGO_SETTINGS_MODULE = mysite.settings
FAIL_INVALID_TEMPLATE_VARS = True
If there is a undefined variable in templates, django won't tell you.
You can print this variable in view.
I would like to know how to show personalized errors with the get_object_or_404 method. I don't want the normal Http404 pages, but I want to display a custom message with the message: the result is none.
Thanks :)
The get_object_or_404() is essentially a simple 5-line function. Unless you have some specific reason for using it, just do:
try:
instance = YourModel.objects.get(pk=something)
except YourModel.DoesNotExist:
return render_to_response('a_template_with_your_error_message.html')
If for whatever reason you have to use get_object_or_404(), you can try putting it in a try: ... except Http404: ... block, but I honestly can't think of a plausible reason for that.
As stated by michael, when using get_object_or_404 you cannot customize the message given on http 404. The message provided in DEBUG does offer information about the exception however: "No MyModel matches the given query."
Check out the doc on this. There are three arguments: Model, *args, and **kwargs. The last two are used to build an argument for either get() or filter() on the Model.
The reason I wrote, however, is to address the question of why we would want to use a helper function such as get_object_or_404() instead of, for example, catching it with an exception like Model.DoesNotExist.
The later solution couples the view layer to the model layer. In an effort to relax this coupling we can take advantage of the controlled coupling offered in the django.shortcuts module[1].
And why exactly aren't you using your server's capeability to do just that?
get_object_or_404() is redirecting to the default 404 page right?
If you are on debug mode you won't see it but when deployed django will just refer to the server's 404 html page.
That can't be done with that shortcut. It will only raise a Http404 exception. Your best bet is a try catch if you want full control. Eg.
try:
obj = Model.objects.get(pk = foo)
except:
return HttpResponseRedirect('/no/foo/for/you')
#or
return render_to_response ...