Does {{localurl:}} work for this? From reading the code and seeing how the extension is used on the secure server, it seems to me it should, but I haven't actually tested it.

(Ps. I suggested the same thing before at http://meta.wikimedia.org/wiki/Talk:Licensing_update/Bugs#Wiki_does_not_exist but got no definite answer then.)

(In reply to comment #1)

Does {{localurl:}} work for this? From reading the code and seeing how the
extension is used on the secure server, it seems to me it should, but I haven't
actually tested it.

I have the recollection that someone said they tested it and localurl did not work. But I certainly didn't try it myself and could be misremembering.

I asked Brion about this on IRC. He said {{localurl:}} wouldn't work, though he noted you could just use non-relative URLs.

Non-relative is fine most of the time, but as noted above, SecurePoll requires a localized reference which is how we got into trouble in the first place.

bugs wrote:

(In reply to comment #3)

I asked Brion about this on IRC. He said {{localurl:}} wouldn't work, though he
noted you could just use non-relative URLs.

I'm not completely sure that will work with the notices, I know they've been iffy about wikitext before (ie. they wouldn't let us use {{GRAMMAR:}} in the fundraising translations). Have you tested it, by any chance?

bugs wrote:

(In reply to comment #5)

I'm not completely sure that will work with the notices, I know they've been
iffy about wikitext before (ie. they wouldn't let us use {{GRAMMAR:}} in the
fundraising translations). Have you tested it, by any chance?

Ignore me, this is what happens when you comment on bugs in the middle of the night. ;-) I ignored the "n't" on MZMcBride's post.

• Bug 18131 has been marked as a duplicate of this bug. ***

{{localurl}} won't work in CentralNotice banners since they don't actually live on the local wiki, but on meta, and are pulled dynamically via a JSONP request. {{SITENAME}} wouldn't work either, except that it's specifically hacked in.

One workaround would be to use Javascript in the banner to test for wgServer="https://secure.wikimedia.org" and adjust the URL accordingly.

(In reply to comment #8)

{{localurl}} won't work in CentralNotice banners since they don't actually live
on the local wiki, but on meta, and are pulled dynamically via a JSONP request.
{{SITENAME}} wouldn't work either, except that it's specifically hacked in.

One workaround would be to use Javascript in the banner to test for
wgServer="https://secure.wikimedia.org" and adjust the URL accordingly.

I'm not sure how this is a WONTFIX. "WONTFIX" means "we're never, ever going to fix this, so stop asking." It seems reasonable that if Wikimedia is going to offer a secure server and if Wikimedia is going to add banners to every page, it should include links that don't needlessly leave the secure server.

An alternate suggestion might be to disable the banners entirely on the secure server. ;-) Even implementing this (sillier) solution wouldn't resolve this bug properly, though. I'm not sure why or how a determination has been made that it's never going to be fixed.

It's likely that this bug will eventually be fixed by a change in the secure server architecture (which will eliminate the weird URL scheme), so I'll mark it as LATER instead. If you feel like it's important to fix this (rather than work around it) in the meantime, feel free to reopen.

(In reply to comment #10)

It's likely that this bug will eventually be fixed by a change in the secure
server architecture (which will eliminate the weird URL scheme), so I'll mark
it as LATER instead. If you feel like it's important to fix this (rather than
work around it) in the meantime, feel free to reopen.

I got a bit confused about this bug's scope. I created a test banner here to test link syntax: http://meta.wikimedia.org/w/index.php?title=Special:NoticeTemplate/view&template=Bug18977test

It can be previewed live here: http://en.wikipedia.org/w/index.php?title=MediaWiki:Sitenotice&banner=Bug18977test

This test re-reminded me how limited the banner parser is. I'm not sure what issue exactly Robert was hitting, so I'll leave it to him to re-open this bug as necessary.

This isn't an issue with the newer https://en.wikipedia.org/ etc.

secure.wikimedia.org isn't 100% dead yet, but unless there are specific banners that are broken I'd recommend closing this out.