Eric Shepherd [:sheppy] Reporter
	Description • 7 years ago

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".

	Florian Scholz (Open Web Docs)
	Comment 1 • 7 years ago

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

	John Whitlock [:jwhitlock] Assignee
	Comment 2 • 7 years ago

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

	John Whitlock [:jwhitlock] Assignee
	Comment 3 • 6 years ago

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

	John Whitlock [:jwhitlock] Assignee
	Comment 4 • 5 years ago

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.

	[github robot]
	Comment 5 • 5 years ago

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

	ExE Boss
	Comment 6 • 5 years ago

(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.