Last modified: 2011-11-29 20:53:56 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 18977 - Local links in CentralNotice broken on secure.wikimedia.org
Local links in CentralNotice broken on secure.wikimedia.org
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
CentralNotice (Other open bugs)
unspecified
All All
: Lowest normal (vote)
: ---
Assigned To: Ryan Kaldari
:
: 18131 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-28 03:01 UTC by Robert Rohde
Modified: 2011-11-29 20:53 UTC (History)
5 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Robert Rohde 2009-05-28 03:01:37 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.
Comment 1 Ilmari Karonen 2009-08-01 11:40:02 UTC
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.)
Comment 2 Robert Rohde 2009-08-03 20:50:00 UTC
(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.  
Comment 3 MZMcBride 2009-08-04 03:36:56 UTC
I asked Brion about this on IRC. He said {{localurl:}} wouldn't work, though he noted you could just use non-relative URLs.
Comment 4 Robert Rohde 2009-08-04 03:47:49 UTC
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.
Comment 5 Casey Brown 2009-08-04 04:36:09 UTC
(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?
Comment 6 Casey Brown 2009-08-04 05:04:01 UTC
(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.
Comment 7 Tomasz Finc 2010-06-07 22:05:44 UTC
*** Bug 18131 has been marked as a duplicate of this bug. ***
Comment 8 Ryan Kaldari 2010-09-30 01:40:47 UTC
{{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.
Comment 9 MZMcBride 2010-09-30 01:45:51 UTC
(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.
Comment 10 Ryan Kaldari 2010-09-30 02:00:28 UTC
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.
Comment 11 MZMcBride 2010-09-30 02:41:18 UTC
(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.
Comment 12 Brion Vibber 2011-11-29 20:53:17 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links