…ddleware and don't care about interfering in the exception flow (a 404 could possibly be transformed into a 500)
…is important to sync the CMS_TEMPLATES variables as sooner as possible in the request/response cycle, so that even on early middleware chain breaking, the error page will be displayed correctly with respect to the current site. This fix also ensures that we are able to show the CMS error page even if there is an early exception raised in the middleware chain
...so it won't end up referencing to a different object when tests asign to settings.__class__.CMS_TEMPLATES a different object. Warning: - a test in lunchbox/tests_admin.py that took advantage of the previous behaviour will fail unless LUN-1661 is integrated. The problem - The inital implementaion assumed settings.__class__.CMS_TEMPLATES would be initialized only once. - DBTemplatesMiddleware uses the CMS_TEMPLATES shorthand for settings.__class__.CMS_TEMPLATES. - When a test modifies settings.__class__.CMS_TEMPLATES, the CMS_TEMPLATES is NOT updated, it will reference the old object. - When another test creates Template.objects.all() = [ stuff ], calls self.client.get('/admin/') it expects the middleware to put those templates in settings.__class__.CMS_TEMPLATES.value - What actually happens is that the templates end up only in the CMS_TEMPLATES shorthand.
…eleted by another user, the user needs to be notified in a nice way (HTTP 404) that the site is not there anymore