Opened 9 years ago

Closed 8 years ago

#3335 closed (wontfix)

Flatpages with DEBUG=False requires 404.html

Reported by: Rob Hudson <treborhudson@…> Owned by: adrian
Component: Contrib apps Version: master
Severity: Keywords:
Cc: treborhudson@… Triage Stage: Design decision needed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:


While I think it is bad to not have a 404.html, I think this could be cleaner since it does work when DEBUG=False. This could lead to a broken site when it is deployed by simply changing the DEBUG setting, which I think is bad.

If flatpages and DEBUG=False and 404.html doesn't exist it throws the error:

Traceback (most recent call last):

  File "/opt/local/lib/python2.4/site-packages/django/core/servers/", line 272, in run
    self.result = application(self.environ, self.start_response)

  File "/opt/local/lib/python2.4/site-packages/django/core/servers/", line 614, in __call__
    return self.application(environ, start_response)

  File "/opt/local/lib/python2.4/site-packages/django/core/handlers/", line 189, in __call__
    response = self.get_response(request)

  File "/opt/local/lib/python2.4/site-packages/django/core/handlers/", line 103, in get_response
    return callback(request, **param_dict)

  File "/opt/local/lib/python2.4/site-packages/django/views/", line 78, in page_not_found
    t = loader.get_template(template_name)

  File "/opt/local/lib/python2.4/site-packages/django/template/", line 79, in get_template
    source, origin = find_template_source(template_name)

  File "/opt/local/lib/python2.4/site-packages/django/template/", line 72, in find_template_source
    raise TemplateDoesNotExist, name

TemplateDoesNotExist: 404.html

When DEBUG=False, get_response in core/handlers/ triggers the callback to the handler404 which is 'django.views.defaults.page_not_found' which eventually loads the template 404.html. If it doesn't exist, you get the error above.

When DEBUG=True, get_response loads the django.views.debug.technical_404_response.

I see two options for a fix (and one isn't really a "fix")...

  1. Change documentation to say that flatpages require that you have a 404.html template.
  1. Fix this so it works the same in both DEBUG states.

If #2 is the best option, this requires a design decision.

One fix could be to change get_response to know whether flatpages is enabled and switch the way it handles the call to page_not_found. But that couples the base handler to flatpages which is bad.

Another fix could be to change page_not_found to not try to load the 404.html template just yet if flatpages exists. But again, this couples flatpages to django/core when it is supposed to be a contrib app.

Not sure what the best answer is.

Change History (9)

comment:1 Changed 9 years ago by Simon G. <dev@…>

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Design decision needed

I'm +1 on defaulting to a safe 404 page if nothing exists (is this also the case for 500's?)

comment:2 Changed 9 years ago by SmileyChris

Regarding "safe" 404, see #760.

comment:3 Changed 9 years ago by treborhudson@…

I like the idea of a Django provided 404 and 500 template if one isn't provided by the user. That seems like a clean and simple solution.

comment:4 Changed 9 years ago by SmileyChris

Note, however, that #666 was closed with the note that we don't want to enforce a "Django look".

Personally I'm also keen on a simple string fall back for 404 and 500 (like #760 implies)

comment:5 Changed 9 years ago by Simon G. <dev@…>

To avoid a "Django-look" (although the Django look is certainly nothing bad!) You could just use something similar to the standard Apache errors:

	<title>404 Not Found</title>
	<h1>Not Found</h1>
	<p>The requested URL {{ request.path|escape }} was not found on this server.</p>

		<a href="">Django - The Web framework for perfectionists with deadlines.</a>
	<title>500 Internal Server Error</title>
	<h1>Internal Server Error</h1>
	<p>I'm sorry, that page is currently unavailable due to a server misconfiguration.</p>

	<p>The server administrator has been notified, and we apologise for any inconvenience.</p>

		<a href="">Django - The Web framework for perfectionists with deadlines.</a>

comment:6 Changed 9 years ago by Rob Hudson <treborhudson@…>

Let's say we added the above 404.html and 500.html templates. Where would they go? Something like django/http/templates/?

Would these get triggered if there was a 404 (or 500) and a TemplateDoesNotExist error gets thrown?

I'd be happy to help contribute a patch if these are good ideas.

comment:7 Changed 9 years ago by jacob

  • Resolution set to wontfix
  • Status changed from new to closed

Django's not going to ever include a default 404 or 500 template. If we do, people won't be forced to create their own, and an error will quickly reveal what software your server's running (think "Application Error (Rails)").

However, [4612] adds a comment to the line that will fail so that at least people will get a slightly better idea of where to go next.

comment:8 Changed 8 years ago by boxed

  • Resolution wontfix deleted
  • Status changed from closed to reopened

The last change of status to wont fix totally misses the point of the issue. The point is that the current code has radically different behavior in debug and release. There are two ways to fix this 1) make it display the error in debug mode or 2) make it display the flat page in non-debug mode. The comment as added by [4612] is a good thing, but clearly stops short. I got bitten by this because I turned off debug and didn't even think of checking my single flatpage. This clearly violates the principle of least surprise. If anything the behavior should be the reverse, making debug mode less lenient.

comment:9 Changed 8 years ago by ubernostrum

  • Resolution set to wontfix
  • Status changed from reopened to closed

Reiterating Jacob's comment. At best, we need to make sure that the use of 404.html is documented. The rest of the behavior isn't surprising at all if you've read the flatpages docs and see how they work.

Note: See TracTickets for help on using tickets.
Back to Top