Mercurial > public > pelican-blog

comparison content/Coding/014-upgrading-django1.4.rst @ 4:7ce6393e6d30

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Adding converted blog posts from old blog.
author Brian Neal <bgneal@gmail.com>
date Thu, 30 Jan 2014 21:45:03 -0600
parents
children
comparison
equal deleted inserted replaced
3:c3115da3ff73 4:7ce6393e6d30
1 Upgrading to Django 1.4
2 #######################
3
4 :date: 2012-04-15 14:50
5 :tags: Django
6 :slug: upgrading-to-django-1.4
7 :author: Brian Neal
8
9 `Django 1.4`_ came out recently, and I took a few hours to upgrade my first site
10 yesterday. I thought it would be useful for my own reference to write down what
11 I did. I hope it will be useful to others. I'd love to read what you had to do,
12 so if you went through this process and blogged about it, please leave a
13 comment. Please keep in mind these aren't hard and fast steps or a recipe to
14 follow, as my sites are probably nothing like yours and may use different
15 features of Django.
16
17 Preparation
18 -----------
19
20 The first thing I did was to read very carefully the `Django 1.4 release
21 notes`_. The Django team does a great job of documenting what has changed, so it
22 is well worth your time to read the release notes. It is also a good idea to at
23 least skim the `Django Deprecation Timeline`_. After reading these, you should
24 make a list of the things you want to change, add, or remove.
25
26 Tips
27 ----
28
29 After deciding what areas you want or need to change in your code, these tips
30 may be useful to help you implement the changes.
31
32 #. **Run with warnings turned on**. Use this command to run the development
33 server: ``$ python -Wall manage.py runserver``. Django makes use of `Python's
34 warning system`_ to flag features that are deprecated. By running Python with
35 the ``-Wall`` switch, you'll see these warnings in the development server
36 output.
37
38 #. **Use the debugger to track down warnings**. Not sure where a pesky warning
39 is coming from? Just open the Django source code in your editor and put a
40 ``import pdb; pdb.set_trace()`` line right above or below the warning. You
41 can then use the debugger's ``w`` command to get a stack trace and find out
42 exactly what code is leading to the warning. In my case I kept getting a few
43 warnings with no idea where they were coming from. I used this technique to
44 verify the warnings were coming from third party code and not my own. For
45 more information on using the debugger (and you really **should** know how to
46 use this invaluable tool), see the `Pdb documentation`_.
47
48 My upgrade experience
49 ---------------------
50
51 Here is a list of things that I did during my port. Again, you may not need to
52 do these, and the next site I upgrade may have a different list. All of these
53 changes (except for the first) are described in the `Django 1.4 release notes`_.
54
55 #. **Upgrade my Django debug toolbar**. As of this writing, the Django debug
56 toolbar I got from PyPI was not compatible with Django 1.4. I simply
57 uninstalled it and grabbed the development version from GitHub with
58 ``pip install git+https://github.com/django-debug-toolbar/django-debug-toolbar.git``.
59
60 #. **Remove the ADMIN_MEDIA_PREFIX setting**. The admin application in
61 Django 1.4 now relies on the ``staticfiles`` application (introduced in
62 Django 1.3) to handle the serving of static assets.
63
64 #. **Remove use of the {% admin_media_prefix %} template tag**. Related to the
65 above, this tag is now deprecated. I had a custom admin view that used this
66 template tag, and I simply replaced it with ``{{ STATIC_URL }}/admin``.
67
68 #. **Remove verify_exists on URLFields**. The ``verify_exists`` option to
69 the ``URLField`` has been removed for performance and security reasons. I had
70 always set this to ``False``; now I just had to remove it altogether.
71
72 #. **Add the require_debug_false filter to logging settings**. As explained in
73 the release notes, this change prevents admin error emails from being sent
74 while in ``DEBUG`` mode.
75
76 #. **django.conf.urls.defaults is deprecated**. I changed my imports in all
77 ``urls.py`` files to use ``django.conf.urls`` instead of
78 ``django.conf.urls.defaults`` to access ``include()``, ``patterns()``, and
79 ``url()``. The Django team had recently moved these functions and updated the
80 docs and tutorial to stop using the frowned upon ``from
81 django.conf.urls.defaults import *``.
82
83 #. **Enable the new clickjacking protection**. A nice new feature is some new
84 middleware that adds the ``X-Frame-Options`` header to all response headers.
85 This provides clickjacking_ protection in modern browsers.
86
87 #. **Add an admin password reset feature**. By adding a few new lines to your
88 ``urlconf`` you get a nifty new password reset feature for your admin.
89
90 #. **Update to the new manage.py**. This was the biggest change with the most
91 impact. The Django team has finally removed a long standing wart with its
92 ``manage.py`` utility. Previously, ``manage.py`` used to play games with your
93 ``PYTHONPATH`` which led to confusion when migrating to production. It could
94 also lead to having your settings imported twice. See the next section in
95 this blog entry for more on what I did here.
96
97 Reorganizing for the new manage.py
98 ----------------------------------
99
100 The change with the largest impact for me was reorganizing my directory
101 structure for the new ``manage.py`` command. Before this change, I had organized
102 my directory structure like this:
103
104 ::
105
106 mysite/
107 media/
108 static/
109 mysite/
110 myapp1/
111 __init__.py
112 models.py
113 views.py
114 urls.py
115 myapp2/
116 __init__.py
117 models.py
118 views.py
119 urls.py
120 settings/
121 __init__.py
122 base.py
123 local.py
124 production.py
125 test.py
126 apache/
127 myproject.wsgi
128 logs/
129 templates/
130 manage.py
131 urls.py
132 LICENSE
133 fabfile.py
134 requirements.txt
135
136 After replacing the contents of my old ``manage.py`` with the new content, I
137 then reorganized my directory structure to this:
138
139 ::
140
141 mysite/
142 media/
143 static/
144 myapp1/
145 __init__.py
146 models.py
147 views.py
148 urls.py
149 myapp2/
150 __init__.py
151 models.py
152 views.py
153 urls.py
154 myproject/
155 settings/
156 __init__.py
157 base.py
158 local.py
159 production.py
160 test.py
161 apache/
162 myproject.wsgi
163 logs/
164 templates/
165 urls.py
166 LICENSE
167 fabfile.py
168 manage.py
169 requirements.txt
170
171 It is a subtle change, but I like it. It now makes it clear that my project is
172 just an application itself, consisting of the top-level ``urls.py``, settings,
173 templates and logs. The ``manage.py`` file is now at the top level directory
174 also, which seems right.
175
176 I had always made my imports as ``from app.models import MyModel`` instead of
177 ``from myproject.app.models``, so I didn't have to update any imports.
178
179 Since I use the "settings as a package" scheme, I did have to update the imports
180 in my settings files. For example, in my ``local.py`` I had to change ``from
181 settings.base import *`` to ``myproject.settings.base import *``.
182
183 What I didn't do
184 ----------------
185
186 Django 1.4's largest new feature is probably its support for timezones. I
187 decided for this project not to take advantage of that. It would require a lot
188 of changes, and it isn't really worth it for this small site. I may use it on
189 the next site I convert to Django 1.4, and I will definitely be using it on new
190 projects.
191
192 Conclusion
193 ----------
194
195 The upgrade process went smoother and quicker than I thought thanks to the
196 excellent release notes and the Django team's use of Python warnings to flag
197 deprecated features.
198
199
200 .. _Django 1.4: https://www.djangoproject.com/weblog/2012/mar/23/14/
201 .. _Django 1.4 release notes: https://docs.djangoproject.com/en/1.4/releases/1.4/
202 .. _Django Deprecation Timeline: https://docs.djangoproject.com/en/1.4/internals/deprecation/
203 .. _Python's warning system: http://docs.python.org/library/warnings.html
204 .. _Pdb documentation: http://docs.python.org/library/pdb.html
205 .. _clickjacking: http://en.wikipedia.org/wiki/Clickjacking