robchur wrote:

Users tend to pick a skin and stick to it, this seems like a bit more effort for no concrete gain in most cases.

ais523 wrote:

Also note that when a user messes up their custom JavaScript in such a way that they can't edit, using useskin= to select a different skin (e.g. myskin) to revert their monobook.js (or whatever other skin) is one way to solve the problem. If Special:Mypage/common.js became widely used, this recourse, probably the simplest in the situation, would become unavailable and something like a script=no parameter would have to be added to index.php.

(In reply to comment #2)

Also note that when a user messes up their custom JavaScript in such a way that
they can't edit, using useskin= to select a different skin (e.g. myskin) to
revert their monobook.js (or whatever other skin) is one way to solve the
problem. If Special:Mypage/common.js became widely used, this recourse,
probably the simplest in the situation, would become unavailable and something
like a script=no parameter would have to be added to index.php.

Nothing easier than turning off the JS support in browser temporarily. No need for any other params in index.php because of this.

ais523 wrote:

(In reply to comment #3)

(In reply to comment #2)

Also note that when a user messes up their custom JavaScript in such a way that
they can't edit, using useskin= to select a different skin (e.g. myskin) to
revert their monobook.js (or whatever other skin) is one way to solve the
problem. If Special:Mypage/common.js became widely used, this recourse,
probably the simplest in the situation, would become unavailable and something
like a script=no parameter would have to be added to index.php.

Nothing easier than turning off the JS support in browser temporarily. No need
for any other params in index.php because of this.

...except when you're in an internet cafe or somewhere like that where you don't have the permissions on your own computer to change the JS support level. (And yes, I have written user scripts under such circumstances before.)

(In reply to comment #4)

Nothing easier than turning off the JS support in browser temporarily. No need
for any other params in index.php because of this.

...except when you're in an internet cafe or somewhere like that where you
don't have the permissions on your own computer to change the JS support level.
(And yes, I have written user scripts under such circumstances before.)

How many people do critical operations on other places than on those where they have the influence on settings?

Besides the back button usually works as well.

Anyway, I don't think that heavily sporadic cases like this should have an influence on solving of this.

robchur wrote:

(In reply to comment #5)

How many people do critical operations on other places than on those where they
have the influence on settings?

I don't think it's a good idea to start making assumptions about where our users access web sites from.

ayg wrote:

(In reply to comment #5)

How many people do critical operations on other places than on those where they
have the influence on settings?

From what I've heard, probably most in some regions of the world. But I agree that this isn't a big problem, since it's a fairly unlikely case (user is writing custom script *and* from an Internet café or whatever *and* they screw up so horribly that they can't even revert) that at worst could be solved by contacting a sysop or whatever. The feature is sound. It would be conceivably useful to have "nocss" and "nojs" parameters in the URL, but that's not really related.

I like the idea [[Special:Mypage/common.css]] and [[Special:Mypage/common.js]]. There are scripts like pngfix (now in common.css of en.wiki) that are not yet in other projects, so I'd like to put them in a site-wide personal .js file. But the skin-specific user files should not be decrapated.

(In reply to comment #1)

Users tend to pick a skin and stick to it, this seems like a bit more effort
for no concrete gain in most cases.

That's biased from the point of Wikimedia. True, most Wikipedia users stick with one skin, namely monobook.
However, other wiki do install extra skins and there are numbers of users who may actually use more than one of those skins.
Most notably is Wikia, currently the skin use there is a mix of Monobook, Quartz, and Monaco. Especially for the users who deal with working on css and js in other skins it's common for someone to switch between skins, and even use different skins in different places.
Of course they have a global.js and global.css, but this is just an example. It's perfectly possible for other wiki groups to install multiple skins and end up with users who do make use of multiple skins.

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

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

chinchi29 wrote:

Is it much trouble to save your personalized *.js/*.css for each skin, instead of making a "common.js/css"? For me, this is unnecessary.

It's more trouble then having one common set of files; we have seven skins now.

chinchi29 wrote:

You're right, but just as #2 said a wrong common.css/js file may completely mess up the page; even if it could make things simpler, who is constantly changing his skin? or who (somebody that change the default one) doesn't know that most personal scripts/skins are designed for the monobook, or even if they work for the other skins, it's obvious that the file to modify is not Special:Mypage/monobook.js/css but the skin they have defined (ex. Special:Mypage/myskin.js/css)

Adding yet another two requests for every logged-in visitor (plus the headers for these files in every page view) does not seem like a good idea to me. MediaWiki is already heavy in that area as it is.

If people really want to share CSS, can't they can put it in a third place and use a CSS @import directive with &action=raw to load it? Not sure of the JS equivalent.

herd wrote:

Not sure of the JS equivalent.

The JS equivalent would be importScript('Pagename'); ... or importScriptURI('url'); for an off-site page.

ayg wrote:

(In reply to comment #15)

Adding yet another two requests for every logged-in visitor (plus the headers
for these files in every page view) does not seem like a good idea to me.

It wouldn't have to be a separate request, just roll it into the existing autogenerated stuff. We already only do one request for Monobook.js + Common.js:

http://en.wikipedia.org/w/index.php?title=-&action=raw&smaxage=0&gen=js&useskin=monobook

I don't think this deserves WONTFIX. It's not very high priority, but it may as well be done, for consistency if nothing else.

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

Seems add two lines in the site MediaWiki:Common.js will solve this:

importScript('User:' + wgUserName + '/common.js');
importStylesheet('User:' + wgUserName + '/common.css');

(In reply to comment #19)

Seems add two lines in the site MediaWiki:Common.js will solve this:

importScript('User:' + wgUserName + '/common.js');
importStylesheet('User:' + wgUserName + '/common.css');

Remember that importScript is asynchronous and is subject to temporal displacement etc.

(In reply to comment #20)

(In reply to comment #19)

Seems add two lines in the site MediaWiki:Common.js will solve this:

importScript('User:' + wgUserName + '/common.js');
importStylesheet('User:' + wgUserName + '/common.css');

Remember that importScript is asynchronous and is subject to temporal
displacement etc.

And that'd better be wrapped in if( wgUserName ) or you'll introduce a script injection vector for all anon users where someone can edit [[User:/common.js]] and globally attack every visitor to the site with js enabled.

+1 In the past a crosswiki user simply added personal setting to monobook.js/css (automated per bot). But more and more wikis are switching its skin to vector.
So this feature is very useful because there isn't a global default skin anymore.

Done in r63300.

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