Django v 1.8 is EOL

[gunchleoc]

Django version 1.8 has reached EOL.

Consider updating to Version 1.11, which is supported until April 01 2020. It will be the last version that supports Python 2.7.

See: https://www.djangoproject.com/download/

---

Imported from Launchpad using lp2gh.

• date created: 2018-04-01T10:24:21Z
• owner: franku
• the launchpad url was https://bugs.launchpad.net/bugs/1760400

[gunchleoc]

(by gunchleoc) Fingers crossed that this will go easier than the last big Django update.

[gunchleoc]

(by franku) Lets see what happens. The last update to 1.8 was a bit awkward because of the timezones. But in the end it worked.

I am always struggling with the tracking app: This is only used for showing the logged in users but it can show much more. So it is very big but most of it is useless... and it is always problematic on updates and unmaintained. I want to get rid of it! Maybe something like that would fit: https://stackoverflow.com/a/45787181

[gunchleoc]

(by gunchleoc) That particular solution is importing something from django.utils.deprecation - do we have a case of nomen est omen here, where we will lose the functionality in the near future?

Having a big dependency for a small function is also not good though.

[gunchleoc]

(by franku) See: https://docs.djangoproject.com/en/2.0/topics/http/middleware/#django.utils.deprecation.MiddlewareMixin

Of course there is a danger of deprecation, as with any third party and modified app we use (e.g. pybb, wiki or djangoratings). But self maintaining a small file is better than maintaining a complete app with models and views, like tracking, imho.

[gunchleoc]

(by gunchleoc) Thanks for the link. I am wondering whether anything from the old MIDDLEWARE_CLASSES can be replaced by MIDDLEWARE stuff - only look into this if it's not more complicated than you want to deal with though!

[gunchleoc]

(by franku) One step at a time. I have to go through all release notes from Django 1.8 until 1.11. The new MIDDLEWARE setting was introduced in 1.10, but i didn't reached the release notes for 1.10 yet ;)

We are mostly using middleware provided by django, the only exception is pagination (which i have updated and is compatible with the new MIDDLEWARE setting), and, tadaaa: tracking

But the release notes are very helpful and mostly point to paragraphs wich describe how to adjust old code. E.g. for the middleware: https://docs.djangoproject.com/en/1.11/releases/1.10/#new-style-middleware

[gunchleoc]

(by franku) Django v1.10 has removed some password hashers. This will affect users who have registered with an old hasher: They can't log in anymore. Two solutions:

1. On demand: Django can automatically convert passwords when a user with old hasher logs in: https://docs.djangoproject.com/en/1.11/topics/auth/passwords/#password-upgrading All needed for this is to add the old hasher to setting PASSWOR_HASHER

2. We can convert passwords without the need to login: https://docs.djangoproject.com/en/1.11/topics/auth/passwords/#password-upgrading-without-requiring-a-login

We have 3823 users using an old hasher.

I am unsure about which solution is the best for our needs. Most of the users who registered with an old hasher would likely never come back to our site.

Pros and cons: Solution 1:

• Not much work for us
• Needs a user to log out and login again

Solution 2:

• Clean solution, imho
• We can rely on the standard settings (no additional setting PASSWORD_HASHER)
• More work
• It may take a longer time to convert old passwords

Any suggestions?

[gunchleoc]

(by franku) I have implemented solution 1 for now. This is ok for our needs, imho.

The switch to 1.11 is close to ready. What is missing is the 'Currently Online users' thing... I will try to update tracking according the needed changes (just for fun :-) ). If it is too much work, i will search for another solution.

[gunchleoc]

(by gunchleoc) Less work sounds good :)

[gunchleoc]

(by franku) I got tracking to work again, but after some rethinking this morning i am convinced it is better to remove it. The main reason: It stores too many (useless) values. See https://bazaar.launchpad.net/~widelands-dev/widelands-website/trunk/view/head:/tracking/models.py#L36

Also the ip-address field is not IPv6 compatible (don't know if our server is IPv6 compatible yet, but i think it is).

There were also some errors in the logs which derived from tracking.

All in all it is better to remove it. The solution mentioned in #2 is much better imho: No Database transactions (using a cache) and it stores only the users id.

[gunchleoc]

(by gunchleoc) I'm always in favor of not collecting useless data, so +1 from me :)

[gunchleoc]

(by franku) I have implemented the middleware suggested in #2 and modified it a bit: Added a signal receiver to remove the users id when one definitely hits the logout button. Otherwise he will be shown as long as setting ONLINE_THRESHOLD is defined.

I think this ready now. I will merge it on the alpha site for testing in production maybe next weekend. I will announce it here if it is ready.

[gunchleoc]

(by gunchleoc) OK, thanks!

[gunchleoc]

(by franku) After solving some problems:

• updating pip and setuptools in the virtualenv
• deleted remaining *. pyc files

the alpha site is running now.

[gunchleoc]

(by franku) Reminder: If one is testing e-mailing on the alpha site remember that some are only send after running the management command './manage.py emit_notices' by hand. I will do that from time to time.