Last modified: 2011-11-29 20:53:56 UTC
During the Licensing Update Vote we needed to use the CentralNotice to reference the local page Special:SecurePoll on whichever wiki the user happened to be on. A reference of the form href="/wiki/Special:SecurePoll" worked on all the primary sites but it was broken on secure.wikimedia.org because of the special url syntax used there. This problem was never resolved during the vote, so CentralNotices shown on secure were always broken. Since SecurePoll is intended to be used into the indefinite future, it would be useful to have a way to correctly specify such links.
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.
(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?
(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.
