Mercurial > public > pelican-blog
view content/Coding/027-upgrading-django1.6.rst @ 13:bcfe2a2c8358
Take advantages of new pelican-bootstrap3 features.
Show date & tags on index.
Show twitter widget.
The Bootstrap readable theme was updated. I didn't like the new
version as much so I saved it as 'readable-bgn' in my pelican-bootstrap3
repo.
Added a setting PATH = 'content' to prevent weird errors when using
'fab regenerate', etc. Got this by googling.
author | Brian Neal <bgneal@gmail.com> |
---|---|
date | Mon, 10 Feb 2014 20:03:21 -0600 |
parents | 49bebfa6f9d3 |
children |
line wrap: on
line source
Upgrading to Django 1.6 ####################### :date: 2013-12-29 18:00 :tags: Django :slug: upgrading-to-django-1.6 :author: Brian Neal :summary: `Django`_ 1.6 came out recently, which was soon followed by 1.6.1, and it looks like 1.6.2 is on the way. I finally got around to upgrading two of my largest sites. I thought I would make a list of what I changed at a high level for my own reference. Perhaps someone else may find it useful as well. Getting started =============== `Django`_ 1.6 came out recently, which was soon followed by 1.6.1, and it looks like 1.6.2 is on the way. I finally got around to upgrading two of my largest sites. I thought I would make a list of what I changed at a high level for my own reference. Perhaps someone else may find it useful as well. In any event, I highly recommend you read the excellent `release notes`_ and `deprecation timeline`_. The changes in 1.6 didn't seem groundbreaking, but they were numerous. I spent a lot of time reading through the notes and trying to decide if the issues affected me or not. I recommend you run with warnings turned on:: $ python -Wall manage.py runserver This will help you flag down issues in your code. If you aren't sure where a warning is coming from, you can turn warnings into exceptions and get a traceback (see the Python docs on the warnings_ library). Another trick is to put a pdb_ breakpoint in the Django code before or after the warning, then you can examine the call stack with the ``w`` command. Upgrade Issues ============== Here are the issues that I ran into. Of course you may have a very different experience depending on what features of Django you used and the details of your site. #. The location of the ``XViewMiddleware`` changed. I had to update my ``MIDDLEWARE_CLASSES`` setting as a result. #. Various ``get_query_set`` to ``get_queryset`` changes. The Django developers have ironed out some naming inconsistencies in method names on both model managers and ``ModelAdmin`` classes. #. In template / form processing, the ``label_tag`` now includes the ``label_suffix``. I noticed this when I saw that I had two colons on a form field's label. #. One very nice change that I am please to see is that Django now does test discovery just like the unittest_ module in the standard library. To take advantage of this I renamed all my test modules from ``view_tests.py`` to ``test_views.py``, for example. This also let me get rid of ``import`` statements in various ``__init__.py`` files in test subdirectories. In other words, you no longer have to have silly lines like ``from view_tests import *`` in your test packages' ``__init__.py`` files. #. Django now supports database connection persistence. To take advantage of this you need to set the CONN_MAX_AGE_ setting to a non-zero value. #. The ``CACHE_MIDDLEWARE_ANONYMOUS_ONLY`` setting is now deprecated and can be removed. For various reasons explained in the notes this never really worked right anyway. #. Updated to version 1.0 of the django-debug-toolbar_. The version I was using would not work in Django 1.6. It is so good to see that this project is being actively maintained again. There are several new panels and neat features, check it out! #. You now get a warning if you have a ``ModelForm`` without an ``exclude`` or ``fields`` meta option. This is rather nice as I have been bit by this in the past when a form suddenly started showing a newly added field that it should not have. I added a ``fields`` option to a ``ModelForm`` as a result. Unfortunately some third party applications I am using have this problem as well. #. The ``cycle`` tag has new XSS_ protection. To make use of it now, you have to add a ``{% load cycle from future %}`` tag into your templates. #. The ``django.contrib.auth`` password reset function is now using base 64 encoding of the ``User`` primary key. The details are `here <https://docs.djangoproject.com/en/1.6/releases/1.6/#django-contrib-auth-password-reset-uses-base-64-encoding-of-user-pk>`_. This affected me because I am using a custom password reset URL, and thus I needed to update my URL pattern for both the new parameter name and the regular expression for base 64. I missed this originally and I started getting 404's on my password reset confirmation URLs. And yes, this is something I should have a test for! What I didn't do ================ Many of the warnings that I got came from third party modules that I have not updated in a long time, including Celery_ and Haystack_. I am going to have to schedule some time to update to the latest versions of these apps. Hopefully the warnings will be fixed in the newer versions, but if not I can write tickets or possibly submit patches / pull requests. This is the price of progress I suppose. I also use a couple of smaller third party applications that seem to be no longer maintained. These apps are now generating some warnings. I'll have to fork them and fix these myself. Luckily these projects are on GitHub so this should not be a problem. Finally I am still facing the problem of what to do about the deprecation of the ``AUTH_PROFILE_MODULE`` and the ``get_profile`` method. This will be removed in Django 1.7. I've been doing some more reading about this and I'm less scared about this than I used to. I'll probably just change my profile model to have a one-to-one relationship with the provided ``User`` model. I'll have to do some more researching and thinking about this before Django 1.7. Conclusion ========== Once again the upgrade process went smoother and quicker than I thought thanks to the excellent release notes and the Django team's use of Python warnings to flag deprecated features. .. _Django: https://www.djangoproject.com/ .. _release notes: https://docs.djangoproject.com/en/1.6/releases/1.6/ .. _deprecation timeline: https://docs.djangoproject.com/en/1.6/internals/deprecation/ .. _warnings: http://docs.python.org/library/warnings.html .. _pdb: http://docs.python.org/library/pdb.html .. _unittest: http://docs.python.org/2/library/unittest.html .. _CONN_MAX_AGE: https://docs.djangoproject.com/en/1.6/ref/settings/#conn-max-age .. _XSS: http://en.wikipedia.org/wiki/Cross-site_scripting .. _configurable user model: https://docs.djangoproject.com/en/1.5/topics/auth/customizing/#auth-custom-user .. _django-debug-toolbar: https://pypi.python.org/pypi/django-debug-toolbar .. _Celery: http://www.celeryproject.org/ .. _Haystack: http://haystacksearch.org/