Redirects: 'target page route' with non-RoutablePageMixin pages causes server error

Issue Summary

https://github.com/wagtail/wagtail/pull/7827 introduced the ‘target page route’ option to the create redirect form. This option is meant to be used in conjunction with ‘Redirect to a page’, it allows editors to choose a page that inherits from RoutablePageMixin and specify a route on the RoutablePage to redirect to.

Now for the issue: it is possible to choose a page that does not inherit from RoutablePageMixin and specify a ‘target route page’. When the created redirect is visited, a server error like this is raised:

AttributeError at /test/
'MyPage' object has no attribute 'resolve_subpage'

I foresee this will be very confusing for editors. ‘Why is my redirect not working?’.

Possible solutions

1. My preferred solution would be to completely hide the ‘target route page’ field and only show it if a page that is a RoutablePage is chosen. I feel like it is better to hide it as it serves a very specific purpose and might be a bit confusing for editors as to what the field is used for.

2. The easy solution: just ignore ‘target route page’ if the page is not a RoutablePage, would probably involve checking https://github.com/wagtail/wagtail/blob/main/wagtail/contrib/redirects/models.py#L62 if the page has a resolve_subpage attribute before trying to use it…

Steps to Reproduce

1. Set up the bakerydemo project (https://github.com/wagtail/bakerydemo/)
2. Upgrade Wagtail to 2.16rc1 using pip install wagtail==2.16rc1 and run migrations (./manage.py migrate).
3. Launch the django dev server and navigate to http://127.0.0.1:8000/admin/redirects/
4. Create a new redirect and choose the following options:

• Redirect from: ‘/test’
• Redirect to a page: ‘About’ (this is not a routable page!)
• Target page route: ‘/causes-server-errors’ (or anything you’d like really, it doesn’t matter)

1. Save redirect and navigate to http://localhost:8000/test/
2. You should now be seeing the following error:

Traceback (most recent call last):
  File "/Users/storm/projects/wagtail/bakerydemo/venv/lib/python3.9/site-packages/django/core/handlers/exception.py", line 47, in inner
    response = get_response(request)
  File "/Users/storm/projects/wagtail/bakerydemo/venv/lib/python3.9/site-packages/django/utils/deprecation.py", line 119, in __call__
    response = self.process_response(request, response)
  File "/Users/storm/projects/wagtail/bakerydemo/venv/lib/python3.9/site-packages/wagtail/contrib/redirects/middleware.py", line 57, in process_response
    if redirect.link is None:
  File "/Users/storm/projects/wagtail/bakerydemo/venv/lib/python3.9/site-packages/wagtail/contrib/redirects/models.py", line 62, in link
    page.resolve_subpage(self.redirect_page_route_path)
AttributeError: 'StandardPage' object has no attribute 'resolve_subpage'

• I have confirmed that this issue can be reproduced as described on a fresh Wagtail project: yes

Technical details

• Python version: Python 3.9.10
• Django version: 3.2.11
• Wagtail version: 2.16rc1
• Browser version: Chrome 97

[ababic]

Thanks for the input @gasman … have updated #7896 to hide the field for now.

[gasman]

The problem with leaving the field in place on the form is that it’s basically impossible to explain to a non-developer what it’s for - we don’t want to normalise the practice of editor-facing UI having “mystery settings that no-one understands, just leave it blank and move on.”

I can’t think of any situation where a user would want to manually edit this field, and can’t think of a situation where noticing the ‘secret’ behaviour would cause confusion either - it would be more like “this redirect says that blog/archive/2017 should redirect to articles/archive, but actually it redirects to articles/archive/2017. I guess that’s good though.”