Last modified: 2012-08-01 08:22:45 UTC
In the URL above, which is on secure server, the links points to HTTP but should point to HTTPS.
*** Bug 31640 has been marked as a duplicate of this bug. ***
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 ?
*** Bug 32050 has been marked as a duplicate of this bug. ***
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.
This seems so have been solved since.
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)
https://gerrit.wikimedia.org/r/17117 https://gerrit.wikimedia.org/r/17118
(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.
