1

The guy here already asked about this and solved it by deleting 500.html and 404.html.

Same for me, when DEBUG is True everything works as expected: Wagtail redirects / to /en, on non-existing pages it gives 404 and so on.

Now when DEBUG is False when accessing / it returns 500 error without any error (only Internal Server Error: /, and I have LOGGING enabled, logfile has no errors either). If I delete 500.html and 404.html everything works, which is strange...

urls.py

urlpatterns = [
    # path('django-admin/', admin.site.urls),

    path('i18n/', include('django.conf.urls.i18n')),

    path('admin/', include(wagtailadmin_urls)),
    path('documents/', include(wagtaildocs_urls)),

    path('search/', search_views.search, name='search'),
]


urlpatterns += i18n_patterns(
    path("search/", search_views.search, name="search"),
    path("", include(wagtail_urls)),
)


if settings.DEBUG:
    from django.conf.urls.static import static
    from django.contrib.staticfiles.urls import staticfiles_urlpatterns

    # Serve static and media files from development server
    urlpatterns += staticfiles_urlpatterns()
    urlpatterns += static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)

In MIDDLEWARE there is 'wagtail.contrib.redirects.middleware.RedirectMiddleware',

Also I noticed that the issue is in 404.html, when using django templates, extends, block etc. Redirects dont work, if 404.html is plain html - redirects work...

In Wagtail's issues on github there is kind of similar issue - #6587. I have the same behavior when DEBUG = False - Wagtail works when accessing "exactly that URL", redirects won't work.

Deleting 404 and 500 error templates is not great in production. Is there any solution to this?

itekhi
  • 151
  • 1
  • 11

1 Answers1

3

I'd suggest investigating exactly which template tags cause the 404.html template to fail. My guess is that when you're pulling in a base template with {% extends %}, your base template is assuming the presence of variables such as page which aren't available when producing a 404 response.

In Wagtail, redirects are handled by a middleware which is activated when the normal page serving process returns a 404. If an error happens in the process of generating that 404 response, then the middleware won't identify it as a 404, and so redirects won't happen.

gasman
  • 23,691
  • 1
  • 38
  • 56
  • Oh, that will be a long way determing :D. Thanks a lot! – itekhi Nov 29 '20 at 23:30
  • is SELF variable available when rendering 404? – itekhi Nov 29 '20 at 23:37
  • No. `self` and `page` are both set to the Wagtail page instance that's handling the request, but for a 404, there is no such page. – gasman Dec 01 '20 at 00:18
  • Oh, that's sad. Thanks again! – itekhi Dec 01 '20 at 00:40
  • 1
    Thanks again! What was causing the error was [this](https://docs.wagtail.io/en/stable/advanced_topics/i18n.html#basic-example) exact segment of `base.html`. I wrapped it around with `{% if page %} {% endif %}` and everything is working now. I think this should be in the docs, because this was quite confusing! Cheers. – itekhi Dec 03 '20 at 03:06
  • 1
    Thanks for the suggestion! Have opened a PR to fix this now... https://github.com/wagtail/wagtail/pull/6609 – gasman Dec 03 '20 at 14:31