Current language is no longer saved to session by LocaleMiddleware
on every response (the behavior introduced in #14825).
Instead language stored in session is reintroduced into new session
after logout.
Forward port of c558a43fd6 to master.
Thanks Curtis Malony and Florian Apolloner.
Squashed commit of the following:
commit 3380495e93
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Sat Nov 23 14:18:07 2013 +0100
Looked up the template_fragments cache at runtime.
commit 905a74f52b
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Sat Nov 23 14:19:48 2013 +0100
Removed all uses of create_cache.
Refactored the cache tests significantly.
Made it safe to override the CACHES setting.
commit 35e289fe92
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Sat Nov 23 12:23:57 2013 +0100
Removed create_cache function.
commit 8e274f747a
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Sat Nov 23 12:04:52 2013 +0100
Updated docs to describe a simplified cache backend API.
commit ee7eb0f73e
Author: Curtis Maloney <curtis@tinbrain.net>
Date: Sat Oct 19 09:49:24 2013 +1100
Fixed#21012 -- Thread-local caches, like databases.
The old 'django_language' variable will still be read from in order
to migrate users. The backwards-compatability shim will be removed in
Django 1.8.
Thanks to jdunck for the report and stugots for the initial patch.
`HttpRequest.scheme` is `https` if `settings.SECURE_PROXY_SSL_HEADER` is
appropriately set and falls back to `HttpRequest._get_scheme()` (a hook
for subclasses to implement) otherwise.
`WSGIRequest._get_scheme()` makes use of the `wsgi.url_scheme` WSGI
environ variable to determine the request scheme.
`HttpRequest.is_secure()` simply checks if `HttpRequest.scheme` is
`https`.
This provides a way to check the current scheme in templates, for example.
It also allows us to deal with other schemes.
Thanks nslater for the suggestion.
Replaced them with per-database options, for proper multi-db support.
Also toned down the recommendation to tie transactions to HTTP requests.
Thanks Jeremy for sharing his experience.
enter_transaction_management() was nearly always followed by managed().
In three places it wasn't, but they will all be refactored eventually.
The "forced" keyword argument avoids introducing behavior changes until
then.
This is mostly backwards-compatible, except, of course, for managed
itself. There's a minor difference in _enter_transaction_management:
the top self.transaction_state now contains the new 'managed' state
rather than the previous one. Django doesn't access
self.transaction_state in _enter_transaction_management.