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.

50

51

== Changed ordering syntax ==

52

53

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

54

55

Example of old ordering syntax:

56

{{{order_by=[('foo', 'ASC'), ('bar', 'DESC')]}}}

57

58

Example of new ordering syntax:

59

{{{order_by=['foo', '-bar']}}}

60

61

The old syntax is deprecated, and we'll stop supporting it for 1.0.

62

63

== Refactored meta.py ==

64

65

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.

66

67

== Changed edit_inline and edit_inline_type behavior ==

68

69

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

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.

82

83

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.

84

85

In PostgreSQL:

86

87

{{{

88

BEGIN;

89

ALTER TABLE auth_admin_log RENAME object_id TO object_id_old;

90

ALTER TABLE auth_admin_log ADD COLUMN object_id TEXT;

91

UPDATE auth_admin_log SET object_id = object_id_old;

92

ALTER TABLE auth_admin_log DROP COLUMN object_id_old;

93

COMMIT;

94

}}}

95

96

In MySQL:

97

98

{{{

99

ALTER TABLE auth_admin_log MODIFY object_id TEXT;

100

}}}

101

102

== Added support for anonymous sessions ==

103

104

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.

105

106

=== Change your settings files ===

107

108

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.)

109

110

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 settings file(s) to remove {{{AUTH_SESSION_COOKIE}}} and {{{REGISTRATION_COOKIE_DOMAIN}}}, if they exist.

146

147

== Changed model syntax ==

148

149

As of [549], Django's model syntax has changed. If you're using models that use old (pre-[549]) syntax, you'll need to convert them according to the instructions on ModelSyntaxChangeInstructions.

150

151

== Moved template loader module ==

152

153

As of [867], {{{django.core.template_loader}}} is deprecated. Use {{{django.core.template.loader}}} instead.

154

155

== Refactored the admin app not to require its own settings file ==

156

157

As of [948], the admin has been refactored, to make things simpler and tighter -- both conceptually and in code layout.

158

159

=== What changed ===

160

161

* The admin no longer requires its own settings file. The "main" site and admin site can run on the same Django installation.

162

* All the admin code moved to {{{django/contrib/admin}}}.

163

* The admin requires {{{"django.contrib.admin"}}} in {{{INSTALLED_APPS}}}, and it requires the {{{app_directories}}} [http://www.djangoproject.com/documentation/templates_python/#loader-types template loader].

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

208

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

209

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

210

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

211

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

212

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

213

* 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:

214

* 404 --> admin/404

215

* 500 --> admin/500

216

* base --> admin/base

217

* base_site --> admin/base_site

218

* admin_object_history --> admin/object_history

219

* delete_confirmation_generic --> admin/delete_confirmation

220

* index --> admin/index

221

* login --> admin/login

222

* template_validator --> admin/template_validator

223

* 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:

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.

344

345

See the new [http://www.djangoproject.com/documentation/syndication/ syndication docs]. For completeness, here's what changed:

346

347

* Created {{{django/contrib/syndication}}}.

348

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

349

* 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}}}.

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

352

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

353

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

354

355

== Changed field name and length for auth.User password_md5 field ==

356

357

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.

Templates that are included in another template using {{{{% include %}}}} or {{{{% ssi %}}}}, or extend a template using {{{{% extends %}}}}, must explicitly {{{{% load %}}}} all libraries they need for their tags and filters. Some templates may have worked in the past due to previous requests registering tags : this will no longer work.

As of [1470], Django URLconfs support non-named groups in URLconf regular expressions. This means you no longer have to specify the name of each group.

520

521

For example, this old syntax:

522

{{{

523

(r'^(?P<item_id>\d{1,3})/$', 'foo.item_detail'),

524

}}}

525

526

Can be shortened to this syntax:

527

{{{

528

(r'^(\d{1,3})/$', 'foo.item_detail'),

529

}}}

530

531

The algorithm it follows is: If there are any named groups, it will use those, ignoring all non-named groups. Otherwise, it will pass all non-named groups as positional arguments. In both cases, it will pass any {{{extra_kwargs}}} as keyword arguments.

532

533

The old syntax (named groups) still works. Use that in cases where you can't (or don't want to) couple the order of URL parameters with the order of your view function arguments.

534

535

There are two small backwards-incompatibilities about this change:

536

537

* If you've written custom middleware that implements {{{process_view()}}}, you'll need to change it so it takes {{{view_args}}} and {{{view_kwargs}}} arguments instead of {{{param_dict}}}:

538

539

{{{

540

def process_view(self, request, view_func, view_args, view_kwargs)

541

}}}

542

543

* On the off chance you have legacy URLconfs that have NO captured items but DO use capturing parenthesis (which until now would have had no effect), you'll need to either change your view code to accept the captured values, or uncapture them.

544

545

== Changed behavior of MultiValueDict.items() ==

546

547

In [1504], the {{{MultiValueDict}}} (and {{{QueryDict}}}) {{{items()}}} method was changed to return the *last* member of each list rather than the full list.

As of [1508], the {{{_or}}} parameter no longer works. Use the new {{{complex}}} parameter. This likely doesn't affect anybody except World Online, because {{{_or}}} has been undocumented and vehemently discouraged on the mailing list.

576

577

== Removed the magic ==

578

579

As of [2809], the [wiki:RemovingTheMagic magic-removal branch] has been merged. There's a LONG list of backwards-incompatible changes, and they're all documented on the RemovingTheMagic wiki page.