MediaWiki talk:Common.js/Archive 4
vandal problem
Is there any way to make changes that would stop this working in the short term (ie untill they chnaged the code):
http://en.wikipedia.org/w/index.php?title=Special:Undelete&target=User%3AIsikop%2Fmonobook.js×tamp=20070128094554 Geni 11:06, 28 January 2007 (UTC)
- I don't get what you mean. The user has been blocked already, so he/she can't edit anyway. —Mets501 (talk) 15:15, 28 January 2007 (UTC)
- We are seeing a number of accounts to use the code to vandalise. IS it posible to make small changes to this page so the code wont work until we come up with a longer term fix.Geni 17:26, 28 January 2007 (UTC)
- Seems unlikely without too many damaging side effects. How bad is this problem? If it's really really bad then we can think harder... —Mets501 (talk) 17:33, 28 January 2007 (UTC)
- not to bad yet.Geni 17:55, 28 January 2007 (UTC)
- Seems unlikely without too many damaging side effects. How bad is this problem? If it's really really bad then we can think harder... —Mets501 (talk) 17:33, 28 January 2007 (UTC)
- We are seeing a number of accounts to use the code to vandalise. IS it posible to make small changes to this page so the code wont work until we come up with a longer term fix.Geni 17:26, 28 January 2007 (UTC)
- Any changes we could make here would be fairly easy for the vandal to work around. It would probably be more effective to get the anti-vandalism bots to automatically revert such edits and report the users making them. It's not as if detecting them should be hard, given that we have the source for the script that makes them. —Ilmari Karonen (talk) 00:23, 1 March 2007 (UTC)
Access key for project page: why change it?
Why is the access key for a Wikipedia: namespace article now A instead of C as it is in all other namespaces? This is inconsistent and irritating. Can this please be changed back? Grouse 00:46, 2 March 2007 (UTC)
- Done. Since several weeks MediaWiki ships with default accesskeys so they no longer need to be defined here (except for links not part of the default interface.) Those defaults seem to be not fully consistent with the old accesskeys. —Ruud 00:13, 3 March 2007 (UTC)
- Thanks Ruud! For the explanation and the fix. Grouse 16:19, 3 March 2007 (UTC)
escape() and replace() in importScript function
I read this December discussion about import module but I still don't see why escape() is there in the first place. Can you please give me an example when it's really needed? As far as I can see, it doesn't work for 2-byte Unicode characters anyway, so in ru:MediaWiki:Common.js we had to remove it so far. Same question for replace(): everything seems to work fine without it, even with spaces in the script path. — Alex Smotrov 20:48, 3 March 2007 (UTC)
- The only reason for
escape()
to be there is to avoid problems with ampersands and percent signs. You're right thatescape()
produces weird results with non-ASCII Unicode (e.g. "Б" becomes "%u0411", which makes Apache choke). It looks like the appropriate function may actually beencodeURIComponent()
. Using that function instead ofescape()
, "Б" is encoded as "%D0%91" instead of "%u0411", which Apache and MediaWiki interpret correctly as the UTF-8 encoding of "Б". (Tested on Galeon/Mozilla 1.7, Firefox 2.0, and IE 6.0) Mike Dillon 21:02, 3 March 2007 (UTC)
- Thank you for the answer. I've yet to see any real users with & or % (and they can always specify the correct way to call their modules in their documentation). But since our version of
importScript()
can import from other Wikipedias, I guess it's better to be consistent and I'll recommend our admins to useencodeURIComponent
as well. Stillpage.replace
was not and is not necessary unless there is slight perfomance difference for Mediawiki servers or we're simply willing to save 2 bytes in URL ( _ vs %20 ). — Alex Smotrov 00:11, 4 March 2007 (UTC)
- Thank you for the answer. I've yet to see any real users with & or % (and they can always specify the correct way to call their modules in their documentation). But since our version of
- I may avoid a HTTP redirect from "Page%20name" (from the escaped/URI-component encoded "Page name") to "Page_name". I'm not entirely sure yet which mechanism is used to rewrite those URLs, but the performance gain/loss of the replace is very likely insignificant. —Ruud 00:50, 4 March 2007 (UTC)
- You're correct that it avoids an HTTP redirect. I just tested it. Mike Dillon 17:28, 5 March 2007 (UTC)