Note
Dedicated to Malcolm Tredinnick
On March 17, 2013, the Django project and the free software community lost a very dear friend and developer.
Malcolm was a long-time contributor to Django, a model community member, a brilliant mind, and a friend. His contributions to Django — and to many other open source projects — are nearly impossible to enumerate. Many on the core Django team had their first patches reviewed by him; his mentorship enriched us. His consideration, patience, and dedication will always be an inspiration to us.
This release of Django is for Malcolm.
– The Django Developers
November 6, 2013
Welcome to Django 1.6!
These release notes cover the new features, as well as some backwards incompatible changes you’ll want to be aware of when upgrading from Django 1.5 or older versions. We’ve also dropped some features, which are detailed in our deprecation plan, and we’ve begun the deprecation process for some features.
Django 1.6, like Django 1.5, requires Python 2.6.5 or above. Python 3 is also officially supported. We highly recommend the latest minor release for each supported Python series (2.6.X, 2.7.X, 3.2.X, and 3.3.X).
Django 1.6 will be the final release series to support Python 2.6; beginning with Django 1.7, the minimum supported Python version will be 2.7.
Python 3.4 is not supported, but support will be added in Django 1.7.
The default templates used by startproject and startapp have been simplified and modernized. The admin is now enabled by default in new projects; the sites framework no longer is. clickjacking prevention is now on and the database defaults to SQLite.
If the default templates don’t suit your tastes, you can use custom project and app templates.
Django’s transaction management was overhauled. Database-level autocommit is now turned on by default. This makes transaction handling more explicit and should improve performance. The existing APIs were deprecated, and new APIs were introduced, as described in the transaction management docs.
Please review carefully the list of known backwards-incompatibilities to determine if you need to make changes in your code.
Django now supports reusing the same database connection for several requests. This avoids the overhead of re-establishing a connection at the beginning of each request. For backwards compatibility, this feature is disabled by default. See Persistent connections for details.
Django 1.6 ships with a new test runner that allows more flexibility in the location of tests. The previous runner (django.test.simple.DjangoTestSuiteRunner) found tests only in the models.py and tests.py modules of a Python package in INSTALLED_APPS.
The new runner (django.test.runner.DiscoverRunner) uses the test discovery features built into unittest2 (the version of unittest in the Python 2.7+ standard library, and bundled with Django). With test discovery, tests can be located in any module whose name matches the pattern test*.py.
In addition, the test labels provided to ./manage.py test to nominate specific tests to run must now be full Python dotted paths (or directory paths), rather than applabel.TestCase.test_method_name pseudo-paths. This allows running tests located anywhere in your codebase, rather than only in INSTALLED_APPS. For more details, see Testing in Django.
This change is backwards-incompatible; see the backwards-incompatibility notes.
The support for time zones introduced in Django 1.4 didn’t work well with QuerySet.dates(): aggregation was always performed in UTC. This limitation was lifted in Django 1.6. Use QuerySet.datetimes() to perform time zone aware aggregation on a DateTimeField.
Django 1.6 adds support for savepoints in SQLite, with some limitations.
A new django.db.models.BinaryField model field allows storage of raw binary data in the database.
GeoDjango now provides form fields and widgets for its geo-specialized fields. They are OpenLayers-based by default, but they can be customized to use any other JS framework.
A check management command was added, enabling you to verify if your current configuration (currently oriented at settings) is compatible with the current version of Django.
The Model.save() method now tries to directly UPDATE the database if the instance has a primary key value. Previously SELECT was performed to determine if UPDATE or INSERT were needed. The new algorithm needs only one query for updating an existing row while the old algorithm needed two. See Model.save() for more details.
In some rare cases the database doesn’t report that a matching row was found when doing an UPDATE. An example is the PostgreSQL ON UPDATE trigger which returns NULL. In such cases it is possible to set django.db.models.Options.select_on_save flag to force saving to use the old algorithm.
Warning
In addition to the changes outlined in this section, be sure to review the deprecation plan for any features that have been removed. If you haven’t updated your code within the deprecation timeline for a given feature, its removal may appear as a backwards incompatible change.
Database-level autocommit is enabled by default in Django 1.6. While this doesn’t change the general spirit of Django’s transaction management, there are a few known backwards-incompatibilities, described in the transaction management docs. You should review your code to determine if you’re affected.
The changes in transaction management may result in additional statements to create, release or rollback savepoints. This is more likely to happen with SQLite, since it didn’t support savepoints until this release.
If tests using assertNumQueries() fail because of a higher number of queries than expected, check that the extra queries are related to savepoints, and adjust the expected number of queries accordingly.
In order to maintain greater consistency with Python’s unittest module, the new test runner (django.test.runner.DiscoverRunner) does not automatically support some types of tests that were supported by the previous runner:
Django bundles a modified version of the doctest module from the Python standard library (in django.test._doctest) and includes some additional doctest utilities. These utilities are deprecated and will be removed in Django 1.8; doctest suites should be updated to work with the standard library’s doctest module (or converted to unittest-compatible tests).
If you wish to delay updates to your test suite, you can set your TEST_RUNNER setting to django.test.simple.DjangoTestSuiteRunner to fully restore the old test behavior. DjangoTestSuiteRunner is deprecated but will not be removed from Django until version 1.8.
This is for developers working on the GeoDjango application itself and related to the item above about changes in the test runners:
The django.contrib.gis.tests.GeoDjangoTestSuiteRunner test runner has been removed and the standalone GeoDjango tests execution setup it implemented isn’t supported anymore. To run the GeoDjango tests simply use the new DiscoverRunner and specify the django.contrib.gis app.
The introduction of the new test runner has also slightly changed the way that test models are imported. As a result, any test that overrides AUTH_USER_MODEL to test behavior with one of Django’s test user models ( CustomUser and ExtensionUser) must now explicitly import the User model in your test module:
from django.contrib.auth.tests.custom_user import CustomUser
@override_settings(AUTH_USER_MODEL='auth.CustomUser')
class CustomUserFeatureTests(TestCase):
def test_something(self):
# Test code here ...
This import forces the custom user model to be registered. Without this import, the test will be unable to swap in the custom user model, and you will get an error reporting:
ImproperlyConfigured: AUTH_USER_MODEL refers to model 'auth.CustomUser' that has not been installed
Django 1.6 introduces time zone support for day, month, and week_day lookups when USE_TZ is True. These lookups were previously performed in UTC regardless of the current time zone.
This requires time zone definitions in the database. If you’re using SQLite, you must install pytz. If you’re using MySQL, you must install pytz and load the time zone tables with mysql_tzinfo_to_sql.
When the time zone support added in Django 1.4 was active, QuerySet.dates() lookups returned unexpected results, because the aggregation was performed in UTC. To fix this, Django 1.6 introduces a new API, QuerySet.datetimes(). This requires a few changes in your code.
QuerySet.dates() now returns a list of date. It used to return a list of datetime.
QuerySet.datetimes() returns a list of datetime.
QuerySet.dates() raises an error if it’s used on DateTimeField when time zone support is active. Use QuerySet.datetimes() instead.
The date_hierarchy feature of the admin now relies on QuerySet.datetimes() when it’s used on a DateTimeField.
This requires time zone definitions in the database when USE_TZ is True. Learn more.
For the same reason, accessing date_list in the context of a date-based generic view requires time zone definitions in the database when the view is based on a DateTimeField and USE_TZ is True. Learn more.
Django 1.6 introduces hour, minute, and second lookups on DateTimeField. If you had model fields called hour, minute, or second, the new lookups will clash with you field names. Append an explicit exact lookup if this is an issue.
When a BooleanField doesn’t have an explicit default, the implicit default value is None. In previous version of Django, it was False, but that didn’t represent accurately the lack of a value.
Code that relies on the default value being False may raise an exception when saving new model instances to the database, because None isn’t an acceptable value for a BooleanField. You should either specify default=False in the field definition, or ensure the field is set to True or False before saving the object.
Extraction of translatable literals from templates with the makemessages command now correctly detects i18n constructs when they are located after a {# / #}-type comment on the same line. E.g.:
{# A comment #}{% trans "This literal was incorrectly ignored. Not anymore" %}
Comments for translators in templates specified using {# / #} need to be at the end of a line. If they are not, the comments are ignored and makemessages will generate a warning. For example:
{# Translators: This is ignored #}{% trans "Translate me" %}
{{ title }}{# Translators: Extracted and associated with 'Welcome' below #}
<h1>{% trans "Welcome" %}</h1>
When reversing URLs, Django didn’t apply urlquote() to arguments before interpolating them in URL patterns. This bug is fixed in Django 1.6. If you worked around this bug by applying URL quoting before passing arguments to reverse(), this may result in double-quoting. If this happens, simply remove the URL quoting from your code. You will also have to replace special characters in URLs used in assertRedirects() with their encoded versions.
The comments app now uses a GenericIPAddressField for storing commenters’ IP addresses, to support comments submitted from IPv6 addresses. Until now, it stored them in an IPAddressField, which is only meant to support IPv4. When saving a comment made from an IPv6 address, the address would be silently truncated on MySQL databases, and raise an exception on Oracle. You will need to change the column type in your database to benefit from this change.
For MySQL, execute this query on your project’s database:
ALTER TABLE django_comments MODIFY ip_address VARCHAR(39);
For Oracle, execute this query:
ALTER TABLE DJANGO_COMMENTS MODIFY (ip_address VARCHAR2(39));
If you do not apply this change, the behavior is unchanged: on MySQL, IPv6 addresses are silently truncated; on Oracle, an exception is generated. No database change is needed for SQLite or PostgreSQL databases.
When you are running raw SQL queries through the cursor.execute method, the rule about doubling percent literals (%) inside the query has been unified. Past behavior depended on the database backend. Now, across all backends, you only need to double literal percent characters if you are also providing replacement parameters. For example:
# No parameters, no percent doubling
cursor.execute("SELECT foo FROM bar WHERE baz = '30%'")
# Parameters passed, non-placeholders have to be doubled
cursor.execute("SELECT foo FROM bar WHERE baz = '30%%' and id = %s", [self.id])
SQLite users need to check and update such queries.
HTML rendering of model form fields corresponding to ManyToManyField model fields used to get the hard-coded sentence:
Hold down “Control”, or “Command” on a Mac, to select more than one.
(or its translation to the active locale) imposed as the help legend shown along them if neither model nor form help_text attributes were specified by the user (or this string was appended to any help_text that was provided).
Since this happened at the model layer, there was no way to prevent the text from appearing in cases where it wasn’t applicable such as form fields that implement user interactions that don’t involve a keyboard and/or a mouse.
Starting with Django 1.6, as an ad-hoc temporary backward-compatibility provision, the logic to add the “Hold down...” sentence has been moved to the model form field layer and modified to add the text only when the associated widget is SelectMultiple or selected subclasses.
The change can affect you in a backward incompatible way if you employ custom model form fields and/or widgets for ManyToManyField model fields whose UIs do rely on the automatic provision of the mentioned hard-coded sentence. These form field implementations need to adapt to the new scenario by providing their own handling of the help_text attribute.
Applications that use Django model form facilities together with Django built-in form fields and widgets aren’t affected but need to be aware of what’s described in Munging of help text of model form fields for ManyToManyField fields below.
The QuerySet iteration was changed to immediately convert all fetched rows to Model objects. In Django 1.5 and earlier the fetched rows were converted to Model objects in chunks of 100.
Existing code will work, but the amount of rows converted to objects might change in certain use cases. Such usages include partially looping over a queryset or any usage which ends up doing __bool__ or __contains__.
Notably most database backends did fetch all the rows in one go already in 1.5.
It is still possible to convert the fetched rows to Model objects lazily by using the iterator() method.
This is consistent with how methods like Form.as_p and Form.as_ul render labels.
If you manually render label_tag in your templates:
{{ form.my_field.label_tag }}: {{ form.my_field }}
you’ll want to remove the colon (or whatever other separator you may be using) to avoid duplicating it when upgrading to Django 1.6. The following template in Django 1.6 will render identically to the above template in Django 1.5, except that the colon will appear inside the <label> element.
{{ form.my_field.label_tag }} {{ form.my_field }}
will render something like:
<label for="id_my_field">My Field:</label> <input id="id_my_field" type="text" name="my_field" />
If you want to keep the current behavior of rendering label_tag without the label_suffix, instantiate the form label_suffix=''. You can also customize the label_suffix on a per-field basis using the new label_suffix parameter on label_tag().
To achieve preserving and restoring list view filters, admin views now pass around the _changelist_filters GET parameter. It’s important that you account for that change if you have custom admin templates or if your tests rely on the previous URLs. If you want to revert to the original behavior you can set the preserve_filters attribute to False.
Past versions of Django used base 36 encoding of the User primary key in the password reset views and URLs (django.contrib.auth.views.password_reset_confirm()). Base 36 encoding is sufficient if the user primary key is an integer, however, with the introduction of custom user models in Django 1.5, that assumption may no longer be true.
django.contrib.auth.views.password_reset_confirm() has been modified to take a uidb64 parameter instead of uidb36. If you are reversing this view, for example in a custom password_reset_email.html template, be sure to update your code.
A temporary shim for django.contrib.auth.views.password_reset_confirm() that will allow password reset links generated prior to Django 1.6 to continue to work has been added to provide backwards compatibility; this will be removed in Django 1.7. Thus, as long as your site has been running Django 1.6 for more than PASSWORD_RESET_TIMEOUT_DAYS, this change will have no effect. If not (for example, if you upgrade directly from Django 1.5 to Django 1.7), then any password reset links generated before you upgrade to Django 1.7 or later won’t work after the upgrade.
In addition, if you have any custom password reset URLs, you will need to update them by replacing uidb36 with uidb64 and the dash that follows that pattern with a slash. Also add _\- to the list of characters that may match the uidb64 pattern.
For example:
url(r'^reset/(?P<uidb36>[0-9A-Za-z]+)-(?P<token>.+)/$',
'django.contrib.auth.views.password_reset_confirm',
name='password_reset_confirm'),
becomes:
url(r'^reset/(?P<uidb64>[0-9A-Za-z_\-]+)/(?P<token>.+)/$',
'django.contrib.auth.views.password_reset_confirm',
name='password_reset_confirm'),
You may also want to add the shim to support the old style reset links. Using the example above, you would modify the existing url by replacing django.contrib.auth.views.password_reset_confirm with django.contrib.auth.views.password_reset_confirm_uidb36 and also remove the name argument so it doesn’t conflict with the new url:
url(r'^reset/(?P<uidb36>[0-9A-Za-z]+)-(?P<token>.+)/$',
'django.contrib.auth.views.password_reset_confirm_uidb36'),
You can remove this url pattern after your app has been deployed with Django 1.6 for PASSWORD_RESET_TIMEOUT_DAYS.
Historically, django.contrib.sessions used pickle to serialize session data before storing it in the backend. If you’re using the signed cookie session backend and SECRET_KEY is known by an attacker (there isn’t an inherent vulnerability in Django that would cause it to leak), the attacker could insert a string into his session which, when unpickled, executes arbitrary code on the server. The technique for doing so is simple and easily available on the internet. Although the cookie session storage signs the cookie-stored data to prevent tampering, a SECRET_KEY leak immediately escalates to a remote code execution vulnerability.
This attack can be mitigated by serializing session data using JSON rather than pickle. To facilitate this, Django 1.5.3 introduced a new setting, SESSION_SERIALIZER, to customize the session serialization format. For backwards compatibility, this setting defaulted to using pickle in Django 1.5.3, but we’ve changed the default to JSON in 1.6. If you upgrade and switch from pickle to JSON, sessions created before the upgrade will be lost. While JSON serialization does not support all Python objects like pickle does, we highly recommend using JSON-serialized sessions. Be aware of the following when checking your code to determine if JSON serialization will work for your application:
See the Session serialization documentation for more details.
Django 1.6 contains many changes to the ORM. These changes fall mostly in three categories:
These changes can result in some compatibility problems. For example, some queries will now generate different table aliases. This can affect QuerySet.extra(). In addition some queries will now produce different results. An example is exclude(condition) where the condition is a complex one (referencing multijoins inside Q objects). In many cases the affected queries didn’t produce correct results in Django 1.5 but do now. Unfortunately there are also cases that produce different results, but neither Django 1.5 nor 1.6 produce correct results.
Finally, there have been many changes to the ORM internal APIs.
The django.db.models.query.EmptyQuerySet can’t be instantiated any more - it is only usable as a marker class for checking if none() has been called: isinstance(qs.none(), EmptyQuerySet)
If your CSS/Javascript code used to access HTML input widgets by type, you should review it as type='text' widgets might be now output as type='email', type='url' or type='number' depending on their corresponding field type.
Form field’s error_messages that contain a placeholder should now always use a named placeholder ("Value '%(value)s' is too big" instead of "Value '%s' is too big"). See the corresponding field documentation for details about the names of the placeholders. The changes in 1.6 particularly affect DecimalField and ModelMultipleChoiceField.
Some error_messages for IntegerField, EmailField, IPAddressField, GenericIPAddressField, and SlugField have been suppressed because they duplicated error messages already provided by validators tied to the fields.
Due to a change in the form validation workflow, TypedChoiceField coerce method should always return a value present in the choices field attribute. That limitation should be lift again in Django 1.7.
There have been changes in the way timeouts are handled in cache backends. Explicitly passing in timeout=None no longer results in using the default timeout. It will now set a non-expiring timeout. Passing 0 into the memcache backend no longer uses the default timeout, and now will set-and-expire-immediately the value.
The django.contrib.flatpages app used to set custom HTTP headers for debugging purposes. This functionality was not documented and made caching ineffective so it has been removed, along with its generic implementation, previously available in django.core.xheaders.
The XViewMiddleware has been moved from django.middleware.doc to django.contrib.admindocs.middleware because it is an implementation detail of admindocs, proven not to be reusable in general.
GenericIPAddressField will now only allow blank values if null values are also allowed. Creating a GenericIPAddressField where blank is allowed but null is not will trigger a model validation error because blank values are always stored as null. Previously, storing a blank value in a field which did not allow null would cause a database exception at runtime.
If a NoReverseMatch exception is raised from a method when rendering a template, it is not silenced. For example, {{ obj.view_href }} will cause template rendering to fail if view_href() raises NoReverseMatch. There is no change to the {% url %} tag, it causes template rendering to fail like always when NoReverseMatch is raised.
django.test.client.Client.logout() now calls django.contrib.auth.logout() which will send the user_logged_out() signal.
Authentication views are now reversed by name, not their locations in django.contrib.auth.views. If you are using the views without a name, you should update your urlpatterns to use url() with the name parameter. For example:
(r'^reset/done/$', 'django.contrib.auth.views.password_reset_complete')
becomes:
url(r'^reset/done/$', 'django.contrib.auth.views.password_reset_complete', name='password_reset_complete')
RedirectView now has a pattern_name attribute which allows it to choose the target by reversing the URL.
In Django 1.4 and 1.5, a blank string was unintentionally not considered to be a valid password. This meant set_password() would save a blank password as an unusable password like set_unusable_password() does, and thus check_password() always returned False for blank passwords. This has been corrected in this release: blank passwords are now valid.
The admin changelist_view previously accepted a pop GET parameter to signify it was to be displayed in a popup. This parameter has been renamed to _popup to be consistent with the rest of the admin views. You should update your custom templates if they use the previous parameter name.
validate_email() now accepts email addresses with localhost as the domain.
The --keep-pot option was added to makemessages to prevent django from deleting the temporary .pot file it generates before creating the .po file.
The undocumented django.core.servers.basehttp.WSGIServerException has been removed. Use socket.error provided by the standard library instead. This change was also released in Django 1.5.5.
The signature of django.views.generic.base.RedirectView.get_redirect_url() has changed and now accepts positional arguments as well (*args, **kwargs). Any unnamed captured group will now be passed to get_redirect_url() which may result in a TypeError if you don’t update the signature of your custom method.
Transaction management was completely overhauled in Django 1.6, and the current APIs are deprecated:
The reasons for this change and the upgrade path are described in the transactions documentation.
Django’s comment framework has been deprecated and is no longer supported. It will be available in Django 1.6 and 1.7, and removed in Django 1.8. Most users will be better served with a custom solution, or a hosted product like Disqus.
The code formerly known as django.contrib.comments is still available in an external repository.
The end of upstream support periods was reached in December 2011 for PostgreSQL 8.2 and in February 2013 for 8.3. As a consequence, Django 1.6 sets 8.4 as the minimum PostgreSQL version it officially supports.
You’re strongly encouraged to use the most recent version of PostgreSQL available, because of performance improvements and to take advantage of the native streaming replication available in PostgreSQL 9.x.
The template system generally escapes all variables to avoid XSS attacks. However, due to an accident of history, the cycle and firstof tags render their arguments as-is.
Django 1.6 starts a process to correct this inconsistency. The future template library provides alternate implementations of cycle and firstof that autoescape their inputs. If you’re using these tags, you’re encouraged to include the following line at the top of your templates to enable the new behavior:
{% load cycle from future %}
or:
{% load firstof from future %}
The tags implementing the old behavior have been deprecated, and in Django 1.8, the old behavior will be replaced with the new behavior. To ensure compatibility with future versions of Django, existing templates should be modified to use the future versions.
If necessary, you can temporarily disable auto-escaping with mark_safe() or {% autoescape off %}.
CacheMiddleware and UpdateCacheMiddleware used to provide a way to cache requests only if they weren’t made by a logged-in user. This mechanism was largely ineffective because the middleware correctly takes into account the Vary: Cookie HTTP header, and this header is being set on a variety of occasions, such as:
This makes the cache effectively work on a per-session basis regardless of the CACHE_MIDDLEWARE_ANONYMOUS_ONLY setting.
CommonMiddleware used to provide basic reporting of broken links by email when SEND_BROKEN_LINK_EMAILS is set to True.
Because of intractable ordering problems between CommonMiddleware and LocaleMiddleware, this feature was split out into a new middleware: BrokenLinkEmailsMiddleware.
If you’re relying on this feature, you should add 'django.middleware.common.BrokenLinkEmailsMiddleware' to your MIDDLEWARE_CLASSES setting and remove SEND_BROKEN_LINK_EMAILS from your settings.
If you defined your own form widgets and defined the _has_changed method on a widget, you should now define this method on the form field itself.
Model._meta.module_name was renamed to model_name. Despite being a private API, it will go through a regular deprecation path.
Model._meta.get_(add|change|delete)_permission methods were deprecated. Even if they were not part of the public API they’ll also go through a regular deprecation path. You can replace them with django.contrib.auth.get_permission_codename('action', Model._meta) where 'action' is 'add', 'change', or 'delete'.
Methods that return a QuerySet such as Manager.get_query_set or ModelAdmin.queryset have been renamed to get_queryset.
If you are writing a library that implements, for example, a Manager.get_query_set method, and you need to support old Django versions, you should rename the method and conditionally add an alias with the old name:
class CustomManager(models.Manager):
def get_queryset(self):
pass # ...
if django.VERSION < (1, 6):
get_query_set = get_queryset
# For Django >= 1.6, models.Manager provides a get_query_set fallback
# that emits a warning when used.
If you are writing a library that needs to call the get_queryset method and must support old Django versions, you should write:
get_queryset = (some_manager.get_query_set
if hasattr(some_manager, 'get_query_set')
else some_manager.get_queryset)
return get_queryset() # etc
In the general case of a custom manager that both implements its own get_queryset method and calls that method, and needs to work with older Django versions, and libraries that have not been updated yet, it is useful to define a get_queryset_compat method as below and use it internally to your manager:
class YourCustomManager(models.Manager):
def get_queryset(self):
return YourCustomQuerySet() # for example
if django.VERSION < (1, 6):
get_query_set = get_queryset
def active(self): # for example
return self.get_queryset_compat().filter(active=True)
def get_queryset_compat(self):
get_queryset = (self.get_query_set
if hasattr(self, 'get_query_set')
else self.get_queryset)
return get_queryset()
This helps to minimize the changes that are needed, but also works correctly in the case of subclasses (such as RelatedManagers from Django 1.5) which might override either get_query_set or get_queryset.
The shortcut view was moved from django.views.defaults to django.contrib.contenttypes.views shortly after the 1.0 release, but the old location was never deprecated. This oversight was corrected in Django 1.6 and you should now use the new location.
The URLconf django.conf.urls.shortcut was also deprecated. If you’re including it in an URLconf, simply replace:
(r'^prefix/', include('django.conf.urls.shortcut')),
with:
(r'^prefix/(?P<content_type_id>\d+)/(?P<object_id>.*)/$', 'django.contrib.contenttypes.views.shortcut'),
Previously, if you wanted a ModelForm to use all fields on the model, you could simply omit the Meta.fields attribute, and all fields would be used.
This can lead to security problems where fields are added to the model and, unintentionally, automatically become editable by end users. In some cases, particular with boolean fields, it is possible for this problem to be completely invisible. This is a form of Mass assignment vulnerability.
For this reason, this behavior is deprecated, and using the Meta.exclude option is strongly discouraged. Instead, all fields that are intended for inclusion in the form should be listed explicitly in the fields attribute.
If this security concern really does not apply in your case, there is a shortcut to explicitly indicate that all fields should be used - use the special value "__all__" for the fields attribute:
class MyModelForm(ModelForm):
class Meta:
fields = "__all__"
model = MyModel
If you have custom ModelForms that only need to be used in the admin, there is another option. The admin has its own methods for defining fields (fieldsets etc.), and so adding a list of fields to the ModelForm is redundant. Instead, simply omit the Meta inner class of the ModelForm, or omit the Meta.model attribute. Since the ModelAdmin subclass knows which model it is for, it can add the necessary attributes to derive a functioning ModelForm. This behavior also works for earlier Django versions.
The generic views CreateView and UpdateView, and anything else derived from ModelFormMixin, are vulnerable to the security problem described in the section above, because they can automatically create a ModelForm that uses all fields for a model.
For this reason, if you use these views for editing models, you must also supply the fields attribute (new in Django 1.6), which is a list of model fields and works in the same way as the ModelForm Meta.fields attribute. Alternatively, you can set the form_class attribute to a ModelForm that explicitly defines the fields to be used. Defining an UpdateView or CreateView subclass to be used with a model but without an explicit list of fields is deprecated.
All special handling of the help_text attribute of ManyToManyField model fields performed by standard model or model form fields as described in Help text of model form fields for ManyToManyField fields above is deprecated and will be removed in Django 1.8.
Help text of these fields will need to be handled either by applications, custom form fields or widgets, just like happens with the rest of the model field types.
Jul 20, 2015