As brought to my attention by Max, through a post on his talk page: https://meta.wikimedia.org/wiki/User_talk:MZMcBride#HTTPS_switch
== The problem ==
Basically, some user defined JS out there has "http://" hard coded, and when you request insecure (non-https) resources during a secure session you get errors in many modern browsers.
This is a heads up that this user created code might need some special attention before and after the switch over.
== How to fix ==
The best option is to use "protocol relative" urls, these are urls that start with "//someurl" instead of "http://" or "https://" or "gopher://" etc.
Here's a blog post about when we started using protocol relative urls in MediaWiki and at WMF: https://blog.wikimedia.org/2011/07/19/protocol-relative-urls-enabled-on-test...
I've put up basic instructions on the HTTPS page on metawiki: https://meta.wikimedia.org/wiki/HTTPS#Help.21_My_code_is_broken.21
Thanks for getting this out to the appropriate channels!
Greg
cc'ing Wikibots-l@lists.wikimedia.org because there might be some overlap of affected people on that list.
Greg Grossmeier, 21/08/2013 05:21:
As brought to my attention by Max, through a post on his talk page: https://meta.wikimedia.org/wiki/User_talk:MZMcBride#HTTPS_switch
Note that in 2008 I already fixed a few thousands CentralNotice banners and other Meta scripts by bot and Hoo made a few thousands fix and review edits on all wikis except ru.wiki, pt.wiki and en.wikt, so most of the work should be done if people have not added cruft in the last year. https://meta.wikimedia.org/wiki/Stewards%27_noticeboard/Archives/2012-04#Fixing_HTTPS_on_Wikimedia_wikis
Nemo
wikitech-ambassadors@lists.wikimedia.org