…n per-site.

…'sites' field.

I've fixed the admin file to filter using the actual default manager, rather than rely on the conventional "objects".

…use.

Pull to get auto-hiding site filters on the change list pages.  Thanks Robert!

as the current object being edited.

…site

Conflicts:
	multisite/admin.py

This makes django.contrib.sites.tests pass.

This is so that you can have multiple SiteIDHooks, if you so
desire. The singleton should be enforced by settings.py, not by a
module-level global.

…ook.

In addition, remove the need to know about threadlocals:

    >>> from multisite import SiteID

…ame.

…'s cache.

This replaces middleware.HOST_CACHE which was a module-level
dictionary. These are undesirable because they're not shared between
processes and because they cannot be expired properly.

….SITE_ID

settings.SITE_ID must now resemble multisite.SiteID.

… view.

When request.get_host() does not resolve to a known Site,
django-multisite will now respond with an HTTP 404 Not Found.

If settings.MULTISITE_FALLBACK is defined, django-multisite will call
that view to decide how to continue.

Includes South migrations, for those using South.

…port.

…te.domain

* DynamicSiteMiddleware.get_site() -> AliasManager.resolve()
    AliasManager.resolve now returns an Alias object, not a Site
    object.

* DynamicSiteMiddleware._expand_netloc() -> AliasManager._expand_netloc()
    Implementation unchanged.

…rams.

This replaces the 'netloc' parameter, as it is more useful to parse it
beforehand.

…mes.

…DEBUG=True

… way.

--HG--
rename : README.markdown => README.rst

… SITE_ID.

…ework

…iteManager

…tion.

Add [email protected] as a maintainer.

…ite.com

…tion.

Because Alias objects are created in the post_save signal for Site,
creating or editing Site objects in the admin may cause validation
failures that need to be reported.

Instead of asking the database if a Site object has changed, cache the
original value and check it.

As well, pre-populate the SITE_CACHE when resolving aliases. Writing
to the cache too often is better than hitting the database.

Prepend multisite.middleware.CookieDomainMiddleware to
settings.MIDDLEWARE_CLASSES to handle cross-domain cookies.
    http://en.wikipedia.org/wiki/HTTP_cookie#Domain_and_Path

By default, Django 1.5 requires ALLOWED_HOSTS to be defined when DEBUG is
False. This lazy iterable object allows us to query our aliases for hosts.

We can also specify wild cards by setting `MULTISITE_EXTRA_HOSTS` if we so
desire. The hosts specified in this variable will be verified first so we
don't have to hit the database if we don't have to.

To use, put the following in your Django settings file:
  from multisite.hosts import ALLOWED_HOSTS as AH
  ALLOWED_HOSTS = AH

If you want to specify extra allowed hosts, add this line to your settings:
  MULTISITE_EXTRA_HOSTS = ['*.mydomain.com']

Re-did the template loaders modules to mimick Django's. This cached template
loader caches on a per-domain basis.

Kept a reference to the multisite template loader in template_loader.py for
compatibilty.

…s changed

in Django 1.6

In this release:
- Django 1.6 support
- ALLOWED_HOSTS iterable for Django 1.5+ populated with the sites defined
- Per-domain cached template loader

The get() method has the same semantics as BaseCache.get().

Use default key prefix if multisite key prefix is not set

Cache key prefix tests

Django 1.6 had already deprecated it, and it got completely removed for Django 1.8:

   https://docs.djangoproject.com/en/dev/releases/1.6/#get-query-set-and-similar-methods-renamed-to-get-queryset

   https://docs.djangoproject.com/en/dev/releases/1.8/#features-removed-in-1-8

rename get_query_set to get_query_set

Keeping the old South migrations under south_migrations is the recommended method:

    https://docs.djangoproject.com/en/1.8/topics/migrations/#libraries-third-party-apps

Added post-South migrations

Cleanup site override even if exception occurs