Deprecation warnings when used with Django 1.9

[jandd]

When used in a Django 1.9 project crispy-forms code produces some deprecation warnings:

python2.7/site-packages/crispy_forms/utils.py:157: RemovedInDjango110Warning: render() must be called with a dict, not a RequestContext.
  html = template.render(context)

python2.7/site-packages/crispy_forms/layout.py:199: RemovedInDjango110Warning: The  context_instance argument of render_to_string is deprecated.
  return render_to_string(template, {'input': self}, context)

python2.7/site-packages/django/template/loader.py:97: RemovedInDjango110Warning: render() must be called with a dict, not a RequestContext.
  return template.render(context, request)

I'm not sure whether this list is complete, but this is all I get in the test suite of one of my projects. I have not observed any wrong behavior in my application yet.

[kavdev]

Two more instances for you:

python3.4/site-packages/crispy_forms/bootstrap.py:90: RemovedInDjango110Warning: The context_instance argument of render_to_string is deprecated.
  return render_to_string(template, extra_context, context)

python3.4/site-packages/crispy_forms/templatetags/crispy_forms_tags.py:222: RemovedInDjango110Warning: render() must be called with a dict, not a Context.
  return template.render(c)

Related information (new in Django 1.8):

Template objects must provide a render() method whose signature differs slightly from the Django template language’s render().

Instead of:

from django.template import Context
from django.template.loader import get_template

template = get_template('hello.html')
html = template.render(Context({'name': 'world'}))

You should write:

from django.template.loader import get_template

template = get_template('hello.html')
html = template.render({'name': 'world'})

And instead of:

from django.template import RequestContext
from django.template.loader import get_template

template = get_template('hello.html')
html = template.render(RequestContext(request, {'name': 'world'}))

You should write:

from django.template.loader import get_template

template = get_template('hello.html')
html = template.render({'name': 'world'}, request)

Passing a Context or a RequestContext is still possible when the template is loaded by a DjangoTemplates backend but it’s deprecated and won’t be supported in Django 1.10.

If you’re loading a template while you’re rendering another template with the Django template language and you have access to the current context, for instance in the render() method of a template tag, you can use the current Engine directly. Instead of:

from django.template.loader import get_template
template = get_template('included.html')

You can write:

template = context.template.engine.get_template('included.html')

This will load the template with the current engine without triggering the multiple template engines machinery, which is usually the desired behavior. Unlike previous solutions, this returns a django.template.Template, like get_template() used to in Django 1.7 and earlier, avoiding all backwards-compatibility problems.

[kavdev]

Two more instances for you:

python3.4/site-packages/crispy_forms/bootstrap.py:90: RemovedInDjango110Warning: The context_instance argument of render_to_string is deprecated.
  return render_to_string(template, extra_context, context)

python3.4/site-packages/crispy_forms/templatetags/crispy_forms_tags.py:222: RemovedInDjango110Warning: render() must be called with a dict, not a Context.
  return template.render(c)

Related information (new in Django 1.8):

Template objects must provide a render() method whose signature differs slightly from the Django template language’s render().

Instead of:

from django.template import Context
from django.template.loader import get_template

template = get_template('hello.html')
html = template.render(Context({'name': 'world'}))

You should write:

from django.template.loader import get_template

template = get_template('hello.html')
html = template.render({'name': 'world'})

And instead of:

from django.template import RequestContext
from django.template.loader import get_template

template = get_template('hello.html')
html = template.render(RequestContext(request, {'name': 'world'}))

You should write:

from django.template.loader import get_template

template = get_template('hello.html')
html = template.render({'name': 'world'}, request)

Passing a Context or a RequestContext is still possible when the template is loaded by a DjangoTemplates backend but it’s deprecated and won’t be supported in Django 1.10.

If you’re loading a template while you’re rendering another template with the Django template language and you have access to the current context, for instance in the render() method of a template tag, you can use the current Engine directly. Instead of:

from django.template.loader import get_template
template = get_template('included.html')

You can write:

template = context.template.engine.get_template('included.html')

This will load the template with the current engine without triggering the multiple template engines machinery, which is usually the desired behavior. Unlike previous solutions, this returns a django.template.Template, like get_template() used to in Django 1.7 and earlier, avoiding all backwards-compatibility problems.

[kavdev]

I'm going to put in a pull request in a bit, but fair warning: keeping < 1.8 compatibility will result in some ugly code. (It actually isn't too bad)

[kavdev]

I'm going to put in a pull request in a bit, but fair warning: keeping < 1.8 compatibility will result in some ugly code. (It actually isn't too bad)

[carltongibson]

If anyone wants a Christmas project, I'd be happy to take a PR on these issues! 😃

[carltongibson]

If anyone wants a Christmas project, I'd be happy to take a PR on these issues! 😃

[kavdev]

@carltongibson: #554? :)

[kavdev]

@carltongibson: #554? :)

[carltongibson]

Already merged, but there are other warnings right?

[carltongibson]

Already merged, but there are other warnings right?

[kavdev]

Nope, got all of them. They are all part of the same deprecation. I take that back. Let me look into his second reported warning.

[kavdev]

Nope, got all of them. They are all part of the same deprecation. I take that back. Let me look into his second reported warning.

[carltongibson]

@kavdev OK. thanks for the input!

FYI I'm looking for a release the w/b 4th Jan

[carltongibson]

@kavdev OK. thanks for the input!

FYI I'm looking for a release the w/b 4th Jan

[kavdev]

@carltongibson: Sounds good. #555

[kavdev]

@carltongibson: Sounds good. #555

[carltongibson]

Good work @kavdev. Thanks.

[carltongibson]

Good work @kavdev. Thanks.

[jandd]

@kavdev thanks a lot

[jandd]

@kavdev thanks a lot