1404669 - Browsing to a redirect page with "&redirect=no" is not doing a no-redirect

Status: RESOLVED FIXED

(developer.mozilla.org Graveyard :: Wiki pages, defect, P1)

Description

[Eric Shepherd [:sheppy]]

Sometime recently, something went wrong with handling of &redirect=no in the URLs. It's supposed to load up the redirect command in the window so you can look at it and possibly edit it. Instead, the target page is getting loaded instead. Sometimes the HTML source of the target is showing up, and sometimes it's the rendered content. Not sure what the difference is right now.

See https://developer.mozilla.org/en-US/docs/MDN/JavaScript?redirect=no for example. This is showing all the info about JavaScript instead of "REDIRECT xxxx".

Comment 1

[Florian Scholz (Open Web Docs)]

John, please add some comments here on what we need to do here this quarter.

Comment 2

[John Whitlock [:jwhitlock]]

I've looked into this, and it is unclear when this broke. My guess is that KumaScript now follows redirects when asking for the ?raw source, and so it renders the new target page, which would mean it broke around November 2016 (node.js update) or early 2017. It does not appear related to the AWS move.

There are some existing tests, but KumaScript rendering is disabled (with a 0 timeout), so the test still gets the REDIRECT version.

It should be a 1/2 day change to:

1. Refactor the old tests
2. Add a failing test that checks that KS rendering is not attempted
3. Update the view logic to skip KS rendering when redirect=no is included

Comment 3

[John Whitlock [:jwhitlock]]

There's an SEO implication to this bug. Since KumaScript follows the redirect for ?raw, the "rendered" version of a page is the content of the destination page, and adding ?redirect=no gives duplicate content. IRC user heycam found that a DuckDuckGo search for "coding style mozilla" [1] returns this URL:

https://developer.mozilla.org/en-US/docs/Mozilla_Coding_Style_Guide?redirect=no

which renders the page with an alternate title "Mozilla Coding Style Guide" but duplicates the content from the destination page:

https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style

I believe the fix to to add a "redirect=no" to the KumaScript request for the raw content [2]

[1] https://duckduckgo.com/?q=c%2B%2B+coding+style+mozilla
[2] https://github.com/mdn/kumascript/blob/7bd53909b07592caf3181b62e5e6bc68b7939d6d/lib/kumascript/conf.js#L40

Comment 4

[John Whitlock [:jwhitlock]]

This may also be causing an issue reported at https://github.com/mdn/kumascript/issues/1020, where the WebFM API appears on https://developer.mozilla.org/en-US/docs/Web/API, despite being moved to https://developer.mozilla.org/en-US/docs/Archive/B2G_OS/API/WebFM_API. Or, it could be another issue with the tagging system.

Comment 5

[[github robot]]

Commits pushed to master at https://github.com/mdn/kumascript

https://github.com/mdn/kumascript/commit/ddeae691557239cc42e7d56c2406bfd4fc9611e7
bug 1404669: optional cleanup

* the "template_url_template" setting has been
  obsolete for some time, so remove it
* update the "document_url_template" setting
  defaults to reflect the addition of "redirect=no"
  to its parameters

https://github.com/mdn/kumascript/commit/e368c0044e4cb1a6c66386e2d0d3ad14fc3fcc5e
Merge pull request #1032 from escattone/cleanup-1404669

bug 1404669: optional cleanup

Comment 6

[ExE Boss]

(In reply to John Whitlock [:jwhitlock] from comment #4)
> This may also be causing an issue reported at
> https://github.com/mdn/kumascript/issues/1020, where the WebFM API appears
> on https://developer.mozilla.org/en-US/docs/Web/API, despite being moved to
> https://developer.mozilla.org/en-US/docs/Archive/B2G_OS/API/WebFM_API.

The reason why WebFM, along with other non‑standard archived APIs appears on https://developer.mozilla.org/en-US/docs/Web/API is because of the fact that https://github.com/mdn/kumascript/blob/master/macros/ListGroups.ejs has no way to determine if the page has been moved and to where it has been moved.

Comment 7

[Ryan Johnson (:rjohnson)]

The fix for this has been deployed to stage and production, as well as for local development. See:

https://developer.allizom.org/en-US/docs/MDN/Promote?redirect=no
https://developer.mozilla.org/en-US/docs/MDN/Promote?redirect=no

I'm not sure why the commits to Kuma master weren't recorded here, so I'll show the PR's that were merged and deployed:

https://github.com/mdn/infra/pull/168
https://github.com/mozilla/kuma/pull/5172

Comment 8

[Ryan Johnson (:rjohnson)]

I re-opened this because although the fix has been deployed, most of the documents that are content-based redirects still must be re-rendered, and that has not yet been done.

Comment 9

[John Whitlock [:jwhitlock]]

I re-rendered just the redirects on staging. 62,334 documents in 15,981 seconds, with 36 errors. I looked at one page with render errors, which has content other than the redirect:

https://developer.allizom.org/en-US/docs/DOM/DOM_event_reference?redirect=no

This is a dumb corner case that I'll ignore until I can refactor redirects. The page redirects as expected:

https://developer.allizom.org/en-US/docs/DOM/DOM_event_reference

There's a lot of pages that need rendered on production, so I think it is easiest to do all documents, not just the redirects.

Comment 10

[John Whitlock [:jwhitlock]]

I re-rendered all 133,571 documents in production. Details at https://bugzilla.mozilla.org/show_bug.cgi?id=1365987#c5.

The page that kicked this off now shows the expected results (the text "REDIRECT" plus a link)

• https://developer.mozilla.org/en-US/docs/MDN/JavaScript?redirect=no

The coding-style page has similar results:

• https://developer.mozilla.org/en-US/docs/Mozilla_Coding_Style_Guide?redirect=no

A Duck Duck Go search for "coding style mozilla" links to the correct page. My guess is that DDG's scraper found the correct page, not that it reacted quickly to my re-render from 4 hours ago.

• https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style

Comment 11

[Ryan Johnson (:rjohnson)]

Thank you John Whitlock!