Add prefix redirects

text/034-redirects-admin-changes.md

@@ -1,45 +1,96 @@
-# RFC: Redirects admin changes
+# RFC: Redirects changes
 
-# Adding new redirects automatically
-## On page move
+## Models changes
 
-We will add a new checkbox to the page move UI which asks the user if they would like to create a redirect from the old location to the new one.
+### Prefix redirects
 
-![](https://d2mxuefqeaa7sj.cloudfront.net/s_C6D086527C63F45E9EA73587C2533A89CBE7313C89FA1DC0882B73424CAB09BB_1552329395110_Screenshot_2019-03-11+Wagtail+-+Move+Blog1.png)
+We will add a new type of redirect that matches on prefixes rather than full URLs. The rest of the URL path that's not part of the redirect's ``old_path`` field will be appended to the destination path.
+
+For example, say we have the following prefix redirect:
+
+ - ``/articles`` to ``/news``
+
+When a user then requests, ``/articles/the-article/`` this will be matched by the prefix redirect and the user will be redirected to ``/news/the-article/``.
+
+To allow creating redirects of this type, a new "Match prefix" checkbox/boolean field will be added to redirects.
+
+#### Choosing the most specific redirect
+
+If multiple prefix redirects and/or a single redirect matches the same URL, the most specific redirect is used.
 
+For example, say we have the following redirects:
 
-If they check this, and the page has subpages, they will be shown another checkbox asking them if they want to create recursive redirects for every descendant page.
+ - prefix redirect from ``/articles`` to ``/news``
+ - prefix redirect from ``/articles/events`` to ``/events``
+ - direct redirect from ``/articles/events/christmas`` to ``/christmas``
 
-![](https://d2mxuefqeaa7sj.cloudfront.net/s_C6D086527C63F45E9EA73587C2533A89CBE7313C89FA1DC0882B73424CAB09BB_1552329038086_Screenshot_2019-03-11+Wagtail+-+Move+Blog2.png)
+Requests will be redirected as follows:
 
-## On page slug change
+ - ``/articles/events/christmas/`` to ``/christmas/``
+ - ``/articles/events/other-event/`` to ``/events/other-event/``
+ - ``/articles/the-article/`` to ``/news/the-article/``
+
+## Admin changes
+
+### Adding new redirects automatically
+
+#### On page move
+
+We will add a new checkbox to the page move UI which asks the user if they would like to create a redirect from the old location to the new one.
+
+![](https://d2mxuefqeaa7sj.cloudfront.net/s_C6D086527C63F45E9EA73587C2533A89CBE7313C89FA1DC0882B73424CAB09BB_1552329395110_Screenshot_2019-03-11+Wagtail+-+Move+Blog1.png)
+
+If this is checked, a redirect to the page will be created from the previous URL of the page. If the page has any children, this redirect will be a prefix redirect.
+
+#### On page slug change
 
 When a page’s slug is changed, a checkbox will appear underneath the slug field asking the user if they would like to create a redirect from the old slug.
 
-If they check this box and their page has subpages, they will be given another checkbox asking them if they would like to create recursive redirects for every descendant page as well.
+If this is checked when the page is published with the new slug, a redirect to the page will be created from the previous URL of the page. If the page has any children, this redirect will be a prefix redirect.
 
-## When unpublishing or deleting a page
+**Q: What if the page is saved as draft? The redirect cannot be created yet but the user who publishes it may not be aware that there is a checkbox on the promote tab.**
+
+#### When unpublishing or deleting a page
 
 When unpublishing or deleting a page, the user can add a redirect from that page’s URL to another page. If they create one, they will be given the option to repoint existing redirects at the new page, delete the existing redirects, or (when not deleting) do nothing.
 
-## Deleting redirects when pages are created in their place
+### Redirect management
 
-Whenever a page is created, moved, or re-slugged in a way that causes it or one of its descendants to clash with a redirect. That or those redirects should be deleted. The user should always be given a warning if this is going to happen, with an option of overriding it if they want to keep them.
+#### Searching for prefix redirects
 
-# Redirect management
-## Management from the page explorer interface
-![](https://d2mxuefqeaa7sj.cloudfront.net/s_C6D086527C63F45E9EA73587C2533A89CBE7313C89FA1DC0882B73424CAB09BB_1552329309392_Screenshot_2019-03-11+Wagtail+-+Exploring+Welcome+to+the+Wagtail+Bakery+1.png)
+The search will return any prefix redirect that matched the searched path. If multiple redirects match, the results will be displayed in order of specificity with most specific first.
 
+#### Management from the page explorer interface
+
+![](https://d2mxuefqeaa7sj.cloudfront.net/s_C6D086527C63F45E9EA73587C2533A89CBE7313C89FA1DC0882B73424CAB09BB_1552329309392_Screenshot_2019-03-11+Wagtail+-+Exploring+Welcome+to+the+Wagtail+Bakery+1.png)
 
 We will add a “redirects” icon at the top right of the page explorer. This will indicate the number of redirects where their “from path” is from within this section. Clicking this will link the user to the redirect management which would be filtered to show only redirects from this section. This button will only be visible to users who have permission to manage redirects.
 
 We will also add a new “Add redirect here” button in the “more” menu. This takes the user to the add redirect UI with the prefix pre-filled (and undeletable).
 
 An alternative to this would be to create a “RedirectPage” type which is a page type that acts as a redirect when served, but these aren’t as flexible and are more heavier to handle in the database than redirects are.
 
-## Bulk actions
+#### Bulk actions
 
 Removing many redirects at once is quite tedious. This will be more of a problem when we start adding new ways to add redirects.
 
 We should improve the redirect search to allow filtering by prefix, and add a bulk delete action which can use checkboxes by each row or all redirects that match the current query.
 
+## Drawbacks
+
+### Redirect chains and loops
+
+It's possible with both prefix and direct redirects to create "redirect chains" where one redirect just leads to another redirect. These are much more likely to happen after we introduce the automatic creation of prefix redirects. For example:
+
+Say we have a section within a section: ``/articles/events``
+
+If the user renames ``articles`` to ``news``, then moves ``events`` out into its own section, this will create two prefix redirects:
+
+ - ``/articles`` to ``/news``
+ - ``/news/events`` to ``/events``
+
+A request to ``/articles/events/christmas/`` would be redirected to ``/news/events/christmas/`` then redirected again to ``/events/christmas/``.
+
+No attempt will be made to resolve redirect chains/loops on the server-side as this depends on the knowledge that the each step of the redirect chain will result in a 404. While we can figure out if a URL points to a Wagtail page, it's impossible to know for sure that the redirect URL will result in a 404, as there may be URLs configured in the web server that Wagtail does not know about.
+
+The same goes for redirect loops, we will rely on web browsers to limit the number of redirects the user receives to break out of any loops.