In the URL above, which is on secure server, the links points to HTTP but should point to HTTPS.
Version: unspecified
Severity: normal
URL: https://commons.wikimedia.org/w/index.php?title=Special%3AGlobalUsage&limit=50&target=LUSITANA+WLM+2011+d.svg
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | None | T21270 Relative URIs in interwiki links table break interwiki transclusion | |||
| Resolved | None | T20664 Relative URIs in interwiki links table causes failed redirects | |||
| Resolved | None | T22342 Support for protocol-relative URLs | |||
| Resolved | None | T33644 GlobalUsage should use protocol-relative links |
Uses WikiMap:makeForeignLink() and WikiMap::getForeignURL, which uses the getURL()/getCanonical() variant for these links.
We could switch getForeignUrl to make use of getFullURL which would give back a protocol relative url.
Impact points for getForeignURL are:
/AbuseFilter/special/SpecialAbuseLog.php
/GlobalUsage/ApiQueryGlobalUsage.php
For makeForeignLink():
/AbuseFilter/special/SpecialAbuseLog.php
/GlobalUsage/ApiQueryGlobalUsage.php
Alternative is to add new static helper functions, to match the ones Roan added for the wiki references...
Oh, and foreignUserLink():
./AbuseFilter/special/SpecialAbuseLog.php
./CentralAuth/specials/SpecialCentralAuth.php
./CentralAuth/specials/SpecialMergeAccount.php
While i'm making notes, it uses makeExternalLink atm. Perhaps making a proper interwiki link, with the extiw class, should be used here ?
Is there a fix imminent? Otherwise we may need to consider (temporarily) the return of the url fix that pre-exists at Commons.
The problem with solving issues like these, is that few devs have this type of setup at home, so it's difficult to check if what you did is good.
Personally i think it should be fine to switch WikiMap:getForeingURL to use protocol relatives urls.
Then we add a WikiMap:getCanonicalUrl() and possibly use it for
ApiQueryGlobalUsage and I think we should be just fine in that case, but i'm hesitant to commit something like that without confirmation by another developer.
Where?
I doesn't works here:
https://www.mediawiki.org/w/index.php?title=Special%3AGlobalUsage&limit=5&target=Example.jpg
Ah I got fooled by commons' script that ensures secure links.... https://commons.wikimedia.org/w/index.php?title=Special%3AGlobalUsage&limit=5&target=Example.jpg
(rephrase bug to not be specific to the Special page - we may want to look at the API module as well)
(In reply to comment #11)
https://gerrit.wikimedia.org/r/17117
https://gerrit.wikimedia.org/r/17118
Can you explain how using the current protocol fixes the bug? Or is the bug titled incorrect. It appears you did the exact opposite of the bug summary.
Sometimes the url has to be complete, in which canonical and/or current protocol makes sense. But when retrieving urls for usage in user interface, protocol-relative makes sense, that's what they're for.
Okay so it seems the commit-msg was lacking details and the code wasn't very descriptive either.
Protocol-relative urls are now returned everywhere and the other commit enforces the current protocol in the one place it shouldn't be relative.
Can we markt this FIXED?
Sorry Krinkle, I swapped the logic of cause and effect around, which made for a less than clear commit message if you didn't know what it was about indeed...
This can be marked fixed now.