Stop using django.contrib.sites

[stefanor]

It's annoying, and we never put more than one conference in an install.

Let's just go with CONFERENCE_NAME in settings, and get rid of our use of the sites framework.

[hodgestar]

Isn't sites required for generating absolute URLs?

[stefanor]

Right. It isn't in normal cases, but it is in things that happen outside an http request/response cycle (e.g. batch emails)

[hodgestar]

Would static site generation need this?

I'm not against removing django.contrib.sites -- it is an annoying extra step during set up -- just trying to think about things we'd need to fix.

[drnlm]

The static site generation doesn't need django.contrib.sites out the box - it tries to generate relative links everywhere. Some of our renderers may use it (I haven't checked), but those should be easy to fix.

We have at least the following bits that currently require django.contrib.sites:

• The registration emails - most of these should be simple to change.
• Schedule uses the WAFERCONFERENCE constants in several places, which are set from the site values. We'll need to check that we don't also use sites directly anywhere in the schedule as well.
• The contrib.redirects package, which has been useful to PyConZA a couple of time, requires sites support to be enabled. This is looks the hardest to fix, and we'll probably have to reimplement some bits to make it work.