What feature should be changed? Please provide the URL of the feature if possible. ================================================================================== Redirects are used when pages are moved, so that links to the old location are sent to the new location. They might also have been created manually in the past, and some may have been ported from previous wiki engines such as DekiWiki. A redirect is implemented as a Document with a particular content pattern in the current revision: REDIRECT <a class="redirect" href="destination">destination</a> This is detected by the document view and turned into a 302 MOVED PERMANENTLY redirect. A boolean Document.is_redirect should reflect if a document is a redirect. This design has caused many issues in Kuma. Bugs with "redirect" in the title [1] are a subset of the issues. I believe a redesign is needed. A summary of my proposed design: 1) A new DocumentRedirect model associate a document location (locale + slug) with a destination Document. This is used in page moves. 2) The new redirects app is used for non-document redirects and external redirects 3) Existing redirects are migrated to DocumentRedirects or redirect app patterns. The remaining Documents only represent pages. [1] https://bugzilla.mozilla.org/buglist.cgi?list_id=13582714&short_desc=redirect&resolution=---&query_format=advanced&short_desc_type=allwordssubstr&product=Mozilla%20Developer%20Network What problems would this solve? =============================== Creating a better redirect implementation could potentially solve many issues with Kuma. The Document.is_redirect flag must be maintained, and can get out of sync with the Document state. A DocumentRedirect requires three data items: a locale, a slug, and a destination document ID. The same redirect implemented as a Document requires all the fields of a Document, plus a Revision to hold the redirect content. This is a waste of database resources. There are currently 62202 redirects, and 54777 "pages", so the savings could be significant. View logic has to filter out redirects when dealing with redirects, but it doesn't always happen. There are existing bugs, such as bug 1274874, where redirects appear in "Review needed" lists. When a page is moved twice, the user gets two 302s when requesting the original page. With the DocumentRedirect, there would be a single 302, no matter how many times the page is moved. There are many existing redirects that appear to be from previous wiki engines. For example, bug 863344 describes a redirect to: /docs/en/Extensions/Thunderbird/HowTos/Common_Thunderbird_Use_Cases/Open_Folder This is no longer a valid URL. There are many hacks in URL handling to try to make URLs like these get to valid pages, and it is possible we're inflicting this pain on ourselves 80% of the time. Who would use this? =================== MDN users would be less likely to hit a problematic redirect. Staff would spend less time investigating and fixing them. What would users see? ===================== Single redirects for page moves. Less or no redirects to deleted documents. What would users do? What would happen as a result? =================================================== Users shouldn't notice any changes, other than never hitting problematic redirects, and maybe a slight speed-up due to a smaller Document table. Staff spends an average of about a day a month repairing broken redirects, and could spend that time on other issues. Is there anything else we should know? ====================================== Search engines may be penalizing us for bad redirects that lead to 404 pages.

MDN Web Docs' bug reporting has now moved to GitHub. From now on, please file content bugs at https://github.com/mdn/sprints/issues/ and platform bugs at https://github.com/mdn/kuma/issues/.