Problem: Server Error 500. In the server log, all it mentions is a line that looks something like

"GET / HTTP/1.1" 500 27

Potential fix: There are two potential reasons for this error.

  • Ensure that ALLOWED_HOSTS is configured properly in the settings file. In the default settings file, there’s a line for ALLOWED_HOSTS=[]. In my case, I was deploying things locally, so I edited this line to be ALLOWED_HOSTS=['127.0.01','localhost']. If you’re deploying things on a specific domain, list that here. Others have suggested using ALLOWED_HOSTS=['*'], but this setting should really only be used for testing deployments, as it’s not a secure setting for production deployment scenarios.
  • Create a template for 500 errors. Note that the docs recommend you create a template that is very simple because you can never know for sure why the error was generated. In other words, you can’t rely on something that might potentially be broken; that’s why the sample one mentioned in the docs doesn’t do anything fancy and doesn’t use any template inheritance.

One quick note about creating a 500-error template: in my case, I wanted my 500 page, like my 404 page, to fit in with the same look & feel as the rest of the site. This meant utilizing template inheritance (i.e., {% extends "base.html" %}). Now, even though the docs say this is no-no, it ended up working out OK. At first, I ran into this error message:

OfflineGenerationError: You have offline compression enabled but key "SOMEKEYHERE" is missing from offline manifest. You may need to run "python manage.py compress"

Following the suggestion made here, I got things working again by using a custom class-based view. [Side note: it looks like offline generation loads the manifest once, and then remembers the result so that it doesn’t have to refetch it on every request. What this means is that once I got offline compression working (by using the custom class-based view), it’s possible to remove the code for the custom view (i.e., the calls in url.py and the class handler500.py) and things would still work out OK. Nonetheless, it’s probably best to just keep the code there.]

Problem: You’d like to see what your 404/500 error pages look like when DEBUG=FALSE
Potential fix: One easy hack to ‘trigger’ django to show 404/500 pages is to add the routes to your `url.py`:

from django.views.generic.base import TemplateView
if settings.DEBUG:
    urlpatterns += patterns('',
        (r'^500/$', TemplateView.as_view(template_name="404.html")),
        (r'^404/$', TemplateView.as_view(template_name="404.html")),
    )
</code>

If you want to see django’s default 500 error page, you can use this instead:

from django.views.defaults import server_error as server_error_view
if settings.DEBUG:
    urlpatterns += patterns('',
        (r'^500/$', server_error_view),
    )

Now you can just navigate to /500/ or /404/ to see the respective error pages.

This article has 1 comments

  1. chiyuan Reply

    typo @ You’d like to see what your 404/500 error pages look like when DEBUG=FALSE. should be DEBUG=True

Leave a Comment

Your email address will not be published. Required fields are marked *