Page MenuHomePhabricator

GlobalUsage should use protocol-relative links
Closed, ResolvedPublic


In the URL above, which is on secure server, the links points to HTTP but should point to HTTPS.

Version: unspecified
Severity: normal



Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:54 PM
bzimport added a project: GlobalUsage.
bzimport set Reference to bz31644.
bzimport added a subscriber: Unknown Object (MLST).
  • 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:

For makeForeignLink():

Alternative is to add new static helper functions, to match the ones Roan added for the wiki references...

Oh, and foreignUserLink():

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.

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

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.

Gilles raised the priority of this task from Medium to Unbreak Now!.Dec 4 2014, 10:12 AM
Gilles moved this task from Untriaged to Done on the Multimedia board.
Gilles lowered the priority of this task from Unbreak Now! to Medium.Dec 4 2014, 11:21 AM