Context Navigation

Backwards-incompatible changes

As Django is still in pre-1.0 mode, we haven't yet committed to maintaining backwards compatibility in any APIs. Although we're keeping such changes to a minimum, Django developers should be acutely aware of these changes.

Of course, once we reach 1.0, we'll be strongly committed to backward compatibility.

This page lists all backwards-incompatible changes to Django so far.

Moved mod_python handler

As of [169], using django.core.handler as a mod_python handler is deprecated. Use django.core.handlers.modpython instead. We will be removing django.core.handler for 1.0.

Changed ordering syntax

As of [292], syntax used for order_by (in the database API) and ordering (in models) has changed.

Refactored meta.py

As of [378], django/core/meta.py has been converted to a package, django/core/meta/. If you're using a version of Django from before [378], make sure to delete django/core/meta.pyc and django/core/meta.pyo, if they exist. The existence of those files doesn't pose any known problems, but it's best to clean things up.

Changed edit_inline and edit_inline_type behavior

As of [440], using edit_inline_type in your models is deprecated, in favor of a less-redundant approach that uses edit_inline itself.

Example of old syntax:
edit_inline=True, edit_inline_type=meta.TABULAR

As of [469], the object_id field in django.models.auth.LogEntry is a TextField instead of an IntegerField. We made this change to accomodate non-integer primary keys.

If you're using a Django database installation from before [469] and you want to use non-integer primary keys on an object you edit in the admin site, you'll need to do an ALTER TABLE in your database.

Added support for anonymous sessions

As of [518], Django has support for anonymous sessions. If you're using a Django database installation from before [518] and you want to use the Django admin, anonymous sessions or auth-based sessions, you'll need to make a few updates to your database and settings files.

Change your settings files

Add "django.middleware.sessions.SessionMiddleware" to the MIDDLEWARE_CLASSES tuple in your admin settings file. Make sure it appears before "django.middleware.admin.AdminUserRequired". (The middleware classes are applied in order, and the admin middleware requires that the session middleware come first.)

If you want session support any other (i.e., non-admin) Django installation, change the MIDDLEWARE_CLASSES setting accordingly. The order (i.e., whether it comes before or after the other installed middleware classes) doesn't matter.

Edit your Django settings file (probably called settings/main.py) to make the following changes:

Add "django.contrib.admin" to INSTALLED_APPS. Order doesn't matter; it can be the first, last, whatever.

Remove "django.middleware.admin.AdminUserRequired" from MIDDLEWARE_CLASSES, if it's in there.

Add "django.middleware.sessions.SessionMiddleware" to MIDDLEWARE_CLASSES, if it's not already in there.

If you've created any custom admin templates, add the appropriate line from the admin TEMPLATE_DIRS setting to your "main" TEMPLATE_DIRS.

(Note that Django looks for "404.html" and "500.html" templates in your TEMPLATE_DIRS. Make sure you have these templates available.)

If you've created any custom admin templates, note that the template inheritance structure has changed. All admin templates are now within an admin subdirectory of the template directory. The following admin templates are directly affected by this change:

404 --> admin/404

500 --> admin/500

base --> admin/base

base_site --> admin/base_site

admin_object_history --> admin/object_history

delete_confirmation_generic --> admin/delete_confirmation

index --> admin/index

login --> admin/login

template_validator --> admin/template_validator

Add "django.core.template.loaders.app_directories.load_template_source" to TEMPLATE_LOADERS, after "django.core.template.loaders.filesystem.load_template_source". If you don't have the TEMPLATE_LOADERS setting, set it to this:

Refactored RSS framework

As of [1194], Django's RSS framework was refactored. This change should not affect most Django users, because the RSS framework was completely undocumented. The only users affected are people who reverse-engineered the framework, and WorldOnline.

Removed django/conf/urls/rss.py. The syndication system doesn't require its own URLconf anymore.

Moved django/views/rss/rss.py to django/contrib/syndication/views.py and refactored it so that feed() takes url and feed_dict instead of slug and param.

Renamed DefaultRssFeed to DefaultFeed in django/utils/feedgenerator.py.

RSS feeds are now specified as subclasses of django.contrib.syndication.feeds.Feed instead of django.core.rss.FeedConfiguration. Syntax is completely different.

RSS feeds are now registered in URLconfs rather than in "magic" settings modules whose names end with "_rss".

Templates for RSS titles and descriptions now live in a feeds directory, not an rss directory.

Changed field name and length for auth.User password_md5 field

As of [1327], the password_md5 field in the auth.User model, which is used for authentication in the Django admin, was renamed to password, and its length was changed from 32 to 128 to accomodate longer hashes and password metadata, such as which hash algorithm to use. This affects everybody who uses the Django authentication system -- including users of the Django admin.