Flatpage with URL of "/" ends up in a redirect loop.

[watusee]

Picture a site with a flatpage at the root. This root flatpage in the
admin tool has a "/" for the URL. The root flatpage gets into a
redirect loop. All other flatpages except the root flatpage work fine.
If Append_Slash is set to false, this perplexing behavior no longer
occurs and the root flatpage works just fine.

[Daniel Harris]

I've been using a site with a flatpage as it's root for quite some time. I went back to double check that I wasn't losing my mind and tried both APPEND_SLASH options. All works just fine for me.

[watusee]

Settings.py

[watusee]

urls.py

[watusee]

Should have mentioned earlier using Python 2.5 with Django 1.02. It happens with both the built-in server and on Web Faction using mod_python. I've attached the setting.py and urls.py to see if I'm doing something unusual or wrong.

Replying to dih0658:

I've been using a site with a flatpage as it's root for quite some time. I went back to double check that I wasn't losing my mind and tried both APPEND_SLASH options. All works just fine for me.

[dc]

The problem is in django.contrib.flatpages.url in line:

(r'^(?P<url>.*)$', 'flatpage'),

It makes

if not url.endswith('/') and settings.APPEND_SLASH:
    return HttpResponseRedirect("%s/" % request.path)

in flatpage view return redirect 302.

According to ​Porting Guide URLconf must be changed to

(r'^(?P<url>.*/)$', 'flatpage'),

This change fixes the problem.

[dc]

Another way is to remove

(r'', include('django.contrib.flatpages.urls'))

from your URLconf and keep only FlatpageFallbackMiddleware. This also fixes the problem.

[Malcolm Tredinnick]

Comment 3 is not correct. Flatpage URLs are not required to end in trailing slashes, so the proposed change there would break those URLs (the ones without a trailing slash).

The real problem is that identified in comment 4. There is no reason to include the flatpage URLs in urls.py. That isn't what the documentation says to do. Since flatpages operate by catching URLs that do not otherwise resolve, they aren't necessarily going to work if you include them explicitly.

If the original poster can confirm that removing that line from urls.py makes the problem go away, we can close this as not being a bug in Django (i.e. invalid). It's just a configuration error.

Nice debugging, dc. :-)

[dc]

Flatpage URLs are not required to end in trailing slashes

Yes, but because of

if not url.endswith('/') and settings.APPEND_SLASH:
    return HttpResponseRedirect("%s/" % request.path)

there is always /page -> /page/ redirect.

This lines were introduced in [8218] as a fix for #6213 and bug seems still there. So this ticket looks like some kind of #6213 duplicate.

[(none)]

Milestone post-1.0 deleted

[Jacob]

I agree with Malcolm; this is a configuration error.

[flaccid]

I am using (1, 1, 0, 'beta', 1) and this problem still occurs.
There is no justification above why this is a configuration problem. I have attempted to use all the before-mentioned url patterns, APPEND_SLASH on or off, as well as falling back to middleware. There is still, always a redirect loop in my version.
People have reported that it 'works for me' using flat pages and the URL pattern (r, include('django.contrib.flatpages.urls')),
That is good for them, but i am doing the same thing, no extra configuration, tested with a fresh project, implementing the exact same examples from the docs and 'Practical Django Projects' and there is always a redirect loop.
jacob - what is this configuration error you speak of and please detail the correct configuration?

I include 'django.contrib.flatpages' in INSTALLED_APPS and apply (r, include('django.contrib.flatpages.urls')), in urls.py (or any of the alternate url patterns mentioned above) with a page added via admin under URL '/' and I will always get a redirect loop.

Please do not close this ticket again blindly.

[flaccid]

Replying to flaccid:
apologies forgot to escape the code, of course that reads

(r'', include('django.contrib.flatpages.urls')),

[Daniel Harris]

Replying to flaccid:

Replying to flaccid:
apologies forgot to escape the code, of course that reads

(r'', include('django.contrib.flatpages.urls')),

I believe Malcom's comments above explain (and fix) the problem. For flatpages you shouldn't be including anything in your urls.py. The flatpages app catches exceptions for pages that do not exist and then look them up in the DB before actually throwing a page not found.

[flaccid]

Replying to Daniel Harris:

Replying to flaccid:

Replying to flaccid:
apologies forgot to escape the code, of course that reads

(r'', include('django.contrib.flatpages.urls')),

I believe Malcom's comments above explain (and fix) the problem. For flatpages you shouldn't be including anything in your urls.py. The flatpages app catches exceptions for pages that do not exist and then look them up in the DB before actually throwing a page not found.

Unfortunately not. I have also tested that on many projects. It throws a HTTP 500 for me with the following traceback example:

[Mon Jul 06 22:35:16 2009] [error] [client 192.168.0.102] mod_wsgi (pid=34592): Exception occurred processing WSGI script '/www/django-projects/foo/apache/foo.wsgi'., referer: http://foo.bar/
[Mon Jul 06 22:35:16 2009] [error] [client 192.168.0.102] Traceback (most recent call last):, referer: http://foo.bar/
[Mon Jul 06 22:35:16 2009] [error] [client 192.168.0.102]   File "/usr/local/lib/python2.6/site-packages/django/core/handlers/wsgi.py", line 241, in __call__, referer: http://foo.bar/
[Mon Jul 06 22:35:16 2009] [error] [client 192.168.0.102]     response = self.get_response(request), referer: http://foo.bar/
[Mon Jul 06 22:35:16 2009] [error] [client 192.168.0.102]   File "/usr/local/lib/python2.6/site-packages/django/core/handlers/base.py", line 122, in get_response, referer: http://foo.bar/
[Mon Jul 06 22:35:16 2009] [error] [client 192.168.0.102]     return self.handle_uncaught_exception(request, resolver, sys.exc_info()), referer: http://foo.bar/
[Mon Jul 06 22:35:16 2009] [error] [client 192.168.0.102]   File "/usr/local/lib/python2.6/site-packages/django/core/handlers/base.py", line 166, in handle_uncaught_exception, referer: http://foo.bar/
[Mon Jul 06 22:35:16 2009] [error] [client 192.168.0.102]     return callback(request, **param_dict), referer: http://foo.bar/
[Mon Jul 06 22:35:16 2009] [error] [client 192.168.0.102]   File "/usr/local/lib/python2.6/site-packages/django/views/defaults.py", line 23, in server_error, referer: http://foo.bar/
[Mon Jul 06 22:35:16 2009] [error] [client 192.168.0.102]     t = loader.get_template(template_name) # You need to create a 500.html template., referer: http://foo.bar/
[Mon Jul 06 22:35:16 2009] [error] [client 192.168.0.102]   File "/usr/local/lib/python2.6/site-packages/django/template/loader.py", line 81, in get_template, referer: http://foo.bar/
[Mon Jul 06 22:35:16 2009] [error] [client 192.168.0.102]     source, origin = find_template_source(template_name), referer: http://foo.bar/
[Mon Jul 06 22:35:16 2009] [error] [client 192.168.0.102]   File "/usr/local/lib/python2.6/site-packages/django/template/loader.py", line 74, in find_template_source, referer: http://foo.bar/
[Mon Jul 06 22:35:16 2009] [error] [client 192.168.0.102]     raise TemplateDoesNotExist, name, referer: http://foo.bar/
[Mon Jul 06 22:35:16 2009] [error] [client 192.168.0.102] TemplateDoesNotExist: 500.html, referer: http://foo.bar/

[flaccid]

Works with or without the error templates although the docs do say they are required (which doesn't make logical sense to me since they won't be rendered if there is a flatpage available).

After a restart in this instance of the django web server, it is working without 500 and 404 error page templates. If anyone else gets in this situation, I suggest (thanks to the assistance of Danial Harris also) to stop your django web server, syncdb and start it again. I originally did syncdb when I originally implemented flatpages and FlatpageFallbackMiddleware however for some reason this was not suffice. I assume restarting the server was for some reason required - perhaps caching issue with the pyc files.. not sure.