T34230: Provide a JavaScript variable for the "redirected from" page title added the ability to get wgRedirectedFrom, but it works only if the redirect page has been accessed via /wiki/Redirect_page (Target_page then contains "wgRedirectedFrom":"Redirect_page"). If it has been accessed via /w/index.php?title=Redirect_page, it is not there (Target_page does not contain even empty variable)
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | He7d3r | T123060 Error: module already implemented: user.options on ptwiki | |||
| Resolved | Krinkle | T123062 mw.util.getUrl should produce working URLs for titles ending in "?" | |||
| Resolved | None | T123276 URL parameters do not work with pages that have "?" in their names | |||
| Resolved | None | T128380 Redirect with a question mark '?' in the title treats everything following it as URL query part when updating the URL | |||
| Restricted Task | |||||
| Duplicate | None | T153275 URL to pagenames with special characters fail | |||
| Resolved | None | T201072 [[?oldid=851713451]] is a valid link in the new preview, but not when the page is saved | |||
| Resolved | None | T132629 Data passed to HHVM ($_SERVER variables) is a mixed bag of already-decoded and non-decoded nonsense | |||
| Resolved | Danny_B | T139271 wgRedirectedFrom not populated/exposed if redirect accessed via index.php?title=Redirect_page |
Event Timeline
Are you seeing this on a Wikimedia site, or on your own wiki? If Wikimedia, this is probably a duplicate of T132629.
Marking that one as parent for now as it is not 100% sure. Safer and more reliable than simply duping.
I can't reproduce this on Wikimedia wiki.
Note that plain page views via index.php?title= are impossible if that wiki supports /wiki/ since MediaWiki will (http)redirect to the canonical url.
E.g. https://en.wikipedia.org/w/index.php?title=Einstein will redirect to https://en.wikipedia.org/wiki/Einstein, which will then correctly render the "Albert Einstein" article with a "redirected from" note.
You can still access it as query string if you add more query parameters. But those seem to be working fine.
view-source:https://en.wikipedia.org/w/index.php?title=Einstein&foo=1 and view-source:https://en.wikipedia.org/wiki/Einstein both respond with the "Albert Einstein" article and include "wgRedirectedFrom":"Einstein".
https://cs.wikipedia.org/w/index.php?title=USS_Cabot_(AVT-3)
redirects to
https://cs.wikipedia.org/wiki/USS_Cabot_(AVT-3)
which redirects to
https://cs.wikipedia.org/wiki/USS_Cabot_(CVL-28)
which does not contain "wgRedirectedFrom":"USS_Cabot_(AVT-3)"
@Danny_B Are you sure you were looking at the source code of the redirect and not the target? When looking at the source code of the regular "USS_Cabot_(CVL-28)" article, there is of course no redirect-related code from anywhere since that's just the regular article. No redirect context of any kind.
Also, https://cs.wikipedia.org/wiki/USS_Cabot_(AVT-3) does not redirect. It responds directly with the other article (just like MediaWiki has always done):
<title>USS Cabot (CVL-28) - Wikipedie</title> <script> ...[],"wgRedirectedFrom":"USS_Cabot_(AVT-3)" ..."wgInternalRedirectTargetUrl":"/wiki/USS_Cabot_(CVL-28)" ..</script> .. <span class="mw-redirectedfrom"> (Redirected from <a .. class="mw-redirect" ..>USS Cabot (AVT-3)</a> .....
Once the page is loaded, mediawiki.action.view.redirect.js changes the browser address bar to wgInternalRedirectTargetUrl (this is not a redirect). - See c49bd9cb14a9af6, T37045.
Huh, interesting. When I use the "View source" option in Chrome, I also don't see any 'wgRedirectedFrom', but I think that is Chrome lying to us – it apparently reloads the page to show the source, and it reloads it from the final URL, and not the one you originally visited. If you do mw.config.get('wgRedirectedFrom') in the JS console, you get the right result. I think there is no bug here (other than possibly the one in Chrome, or whatever browser you're using).
Yes, that's the issue actually. We just found the cause after some IRC chat and debugging.
The deal is, that URL gets changed to the target page and when you ask browser to view source (ie. Ctrl-U in Firefox) it loads the address which it has in address bar again, hence why in this case it loads directly the target page, not via redirecting one.
The deal is, that MW changes the history state on page load, which causes the behavior above.
This doesn't have a solution suitable for everybody unfortunately (well, unless there would be some preference to suspend history state changes, but we know how it is with preferences...).
Using
history.replaceState( null, document.title, window.location.pathname.replace( /\/[^/]*$/, "/" + mw.config.get("wgRedirectedFrom") ) );
on page load (ie. via Greasemonkey) returns the URL of the original title (the redirecting page) to the address bar and then hitting Ctrl-U (view source) works perfectly.