Last modified: 2014-04-05 18:44:31 UTC
When I visit <https://wikimedia.de/wiki/Hauptseite>, there are a few resources coming in via HTTP, causing my Web browser to throw warnings. <img alt="" src="http://upload.wikimedia.org/wikipedia/commons/thumb/6/66/Wikidata-logo-en.svg/170px-Wikidata-logo-en.svg.png" width="170" height="120" /> <img alt="Wikipedianer auf Exkursion im Kirchenarchiv Kaufbeuren. Foto: Benutzerin:Elya, CC-BY-SA 3.0" src="http://upload.wikimedia.org/wikipedia/commons/thumb/0/09/GLAM-Aktivisten_im_Kirchenarchiv_Kaufbeuren_04.JPG/170px-GLAM-Aktivisten_im_Kirchenarchiv_Kaufbeuren_04.JPG" width="170" height="128" /> <img alt="Logo von Wikivoyage" src="http://upload.wikimedia.org/wikipedia/commons/thumb/1/1b/Wikivoyage-logo-en-TTO-attempt.svg/170px-Wikivoyage-logo-en-TTO-attempt.svg.png" width="170" height="180" /> [a bunch of other images ...] <img src="http://i.creativecommons.org/l/by-sa/3.0/88x31.png" alt="Attribution-Share Alike 3.0 Unported" width="88" height="31" /> <img src="http://secure.wikimedia.de/piwik/piwik.php?idsite=2" style="border:0" alt=""/> This is probably the not the best place to report this issue, but I couldn't find a better place and I figured some of the German Wikimedians can be copied on this bug report and can forward this issue as necessary and appropriate.
This isn't the right place for this. WMF doesn't host the wikimedia.de wiki. I note Daniel is CC'd on this bug
I have passed on responsibility for this a while ago, but i'll try to poke the relevant people, and help them fix it (I'm pretty sure this was my mistake). Adding Silke Meyer (who is technically responsible) and Kai Nissen (who has been managing the site). @Sam: WMDE doesn't have a bug tracker for stuff like this, perhaps we could just get a product here? I'll re-open the bug with the new assignee; if you feel it's really in the way here, close it again. We'll figure out another solution, then.
p858snake: What is "upstream" here??? (In reply to comment #2) > @Sam: WMDE doesn't have a bug tracker for stuff like this, perhaps we could > just get a product here? Please file a separate ticket to discuss this.
The protocol type that has been used to get the file info from commons.wikimedia.org gets cached by the parser cache. This will happen vice versa, if the parser caches when requesting with https. I customized the ForeignAPIRepo for commons to always use the secure protocol when requesting the commons API, but changing ForeignAPIRepo::getThumbUrl() to strip the protocol and make the src attribute protocol-relative seems to be the solution here. I will provide a patch this weekend. @MZMcBride: The other images that are not provided by commons were also changed to protocol-relative.
Related URL: https://gerrit.wikimedia.org/r/61390 (Gerrit Change Id40186d10019a77f8b827a6a67982d40f3e97f11)
Patch needs rework.
(In reply to comment #6) > Patch needs rework. More than that, Anomie said "Your analysis of the problem in the commit summary is not correct". This bug is indeed misleading and is a duplicate of something the reporter already reported previously and that I had already clarified as bug 48133. *** This bug has been marked as a duplicate of bug 48133 ***
Change 61390 abandoned by Siebrand: (bug 47653) Processing foreign API files protocol-relative Reason: I'm abandoning this patch set as it's been open for a long time without any outlook at the open issues being resolved. If the submitter or anyone else would like to work on it again, this patch set can be re-activated by clicking "Restore Change". Please only do this if you are actually going to work on it immediately. https://gerrit.wikimedia.org/r/61390
