Opened 5 years ago

Closed 5 years ago

Last modified 4 years ago

#30825 closed Bug (worksforme)

Confusing message on the default Django home page mentioning the debug settings

Reported by: Therry van Neerven Owned by: KESHAV KUMAR
Component: Uncategorized Version: 2.2
Severity: Normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: yes UI/UX: yes

Description (last modified by Therry van Neerven)

When having no home page configured and when running the configuration with DEBUG=False the following message is shown:

You are seeing this page because DEBUG=True is in your settings file and you have not configured any URLs.

(Check the attachment for a screenshot)

This message is confusing as I'm running Django with DEBUG=False.
Also I have configured URLs, but they are not at the root of the project.

I believe that this message should be improved and stating that a the user should configure a route to replace the default page.

Update: I noticed that for this specific view the engine is forced to be in debug [source]
I still believe that the message should be changed in order to communicate correctly what's going on.

Attachments (1)

django-home-page-debug-message.png (41.8 KB ) - added by Therry van Neerven 5 years ago.
default home page

Download all attachments as: .zip

Change History (8)

by Therry van Neerven, 5 years ago

default home page

comment:1 by Therry van Neerven, 5 years ago

Description: modified (diff)

comment:2 by Therry van Neerven, 5 years ago

Description: modified (diff)

comment:3 by KESHAV KUMAR, 5 years ago

Owner: changed from nobody to KESHAV KUMAR
Status: newassigned

comment:4 by Carlton Gibson, 5 years ago

Resolution: worksforme
Status: assignedclosed

The debug view is not shown when DEBUG=False. Instead a generic 404 is show.

Unless you can provide reproduce steps, this isn't something we need to fix.

  1. django-admin startproject ticket_30825
  2. cd ticket_30825/
  3. Edit settings.py with
    DEBUG = False
    ALLOWED_HOSTS = ['*']
  1. ./manage.py runserver
  2. curl -i http://127.0.0.1:8000
HTTP/1.1 404 Not Found
Date: Wed, 02 Oct 2019 14:59:27 GMT
Server: WSGIServer/0.2 CPython/3.7.3
Content-Type: text/html
X-Frame-Options: DENY
Content-Length: 179
X-Content-Type-Options: nosniff


<!doctype html>
<html lang="en">
<head>
  <title>Not Found</title>
</head>
<body>
  <h1>Not Found</h1><p>The requested resource was not found on this server.</p>
</body>
</html>

Last edited 5 years ago by Carlton Gibson (previous) (diff)

in reply to:  4 comment:5 by Therry van Neerven, 5 years ago

Replying to Carlton Gibson:

The debug view is not shown when DEBUG=False. Instead a generic 404 is show.

Unless you can provide reproduce steps, this isn't something we need to fix.

I've checked our project and I found out that the issue was caused by the configuration of the default_urlconf at the root url:

from django.contrib import admin
from django.urls import path
from django.views.debug import default_urlconf

urlpatterns = [
    path('', default_urlconf),
    path('admin/', admin.site.urls),
]

The problem is caused by the fact that the Template engine is different for this view:

# Minimal Django templates engine to render the error templates
# regardless of the project's TEMPLATES setting. Templates are
# read directly from the filesystem so that the error handler
# works even if the template loader is broken.
DEBUG_ENGINE = Engine(
    debug=True,
    libraries={'i18n': 'django.templatetags.i18n'},
)

I'm in favor of considering this a configuration error from the user's side. However if a better message can be provided that would be nice.

comment:6 by Carlton Gibson, 5 years ago

OK, so it's morning, and perhaps I need another coffee, but, I'm struggling to think of any reasonable circumstances in which this ends up in your urls.py:

from django.views.debug import default_urlconf

urlpatterns = [
    path('', default_urlconf),
    # ...
]

For me, this is so far out of expected practice that:

  • You'd need to be beyond beginner to even be able to end up here, and
  • So rare as to not merit additional code paths adding an better error message.

Nonetheless, do you have a particular patch in mind?

in reply to:  6 comment:7 by Therry van Neerven, 4 years ago

Replying to Carlton Gibson:

For me, this is so far out of expected practice that:

  • You'd need to be beyond beginner to even be able to end up here, and
  • So rare as to not merit additional code paths adding an better error message.

Nonetheless, do you have a particular patch in mind?

All the patches that I can think of introduce additional complexity.
Since this is an edge case I don't think it is is worthwhile to make changes to the current implementation.
For that reason I'm fine with leaving this bug closed unless more people are reporting that they end up in a similar situation.

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