Last modified: 2011-03-13 23:52:04 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 10183 - Add personal Common.css & Common.js
Add personal Common.css & Common.js
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
User preferences (Other open bugs)
unspecified
All All
: Normal enhancement with 3 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 13903 17258 20355 25027 (view as bug list)
Depends on:
Blocks: javascript css 8463
  Show dependency treegraph
 
Reported: 2007-06-07 11:50 UTC by Danny B.
Modified: 2011-03-13 23:52 UTC (History)
14 users (show)

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


Attachments

Description Danny B. 2007-06-07 11:50:18 UTC
Please add per-user Common.css and Common.js ([[User:Foo/Common.(css|js)]]) support, so user can edit his shared stuff on one place.

Also as a side-effect all skin-based JSs can be marked obsolete (as global skin-based scripts were).

Thanks.
Comment 1 Rob Church 2007-06-07 13:48:21 UTC
Users tend to pick a skin and stick to it, this seems like a bit more effort for no concrete gain in most cases.
Comment 2 ais523 2007-06-07 14:30:07 UTC
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.
Comment 3 Danny B. 2007-06-07 14:37:37 UTC
(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.
Comment 4 ais523 2007-06-07 16:59:45 UTC
(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.)
Comment 5 Danny B. 2007-06-07 17:37:15 UTC
(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.
Comment 6 Rob Church 2007-06-07 18:14:39 UTC
(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.
Comment 7 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-06-07 23:18:50 UTC
(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.
Comment 8 Erwin Dokter 2007-09-11 14:26:15 UTC
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.
Comment 9 Daniel Friesen 2008-03-10 04:45:15 UTC
(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.
Comment 10 Alexandre Emsenhuber [IAlex] 2008-04-30 19:50:24 UTC
*** Bug 13903 has been marked as a duplicate of this bug. ***
Comment 11 Chad H. 2009-01-30 19:14:14 UTC
*** Bug 17258 has been marked as a duplicate of this bug. ***
Comment 12 Bryan Baron 2009-06-21 19:12:06 UTC
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.
Comment 13 Erwin Dokter 2009-06-21 23:13:41 UTC
It's more trouble then having one common set of files; we have seven skins now.
Comment 14 Bryan Baron 2009-06-22 00:44:59 UTC
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)
Comment 15 Laurence 'GreenReaper' Parry 2009-06-22 01:00:18 UTC
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.
Comment 16 Splarka 2009-06-22 01:06:11 UTC
> Not sure of the JS equivalent.
The JS equivalent would be importScript('Pagename'); ... or importScriptURI('url'); for an off-site page.
Comment 17 Aryeh Gregor (not reading bugmail, please e-mail directly) 2009-07-29 22:13:32 UTC
(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.
Comment 18 Platonides 2009-08-22 18:39:52 UTC
*** Bug 20355 has been marked as a duplicate of this bug. ***
Comment 19 Jimmy Xu 2009-08-22 18:45:59 UTC
Seems add two lines in the site MediaWiki:Common.js will solve this:

importScript('User:' + wgUserName + '/common.js');
importStylesheet('User:' + wgUserName + '/common.css');
Comment 20 Carl Fürstenberg 2009-08-22 21:51:56 UTC
(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.
Comment 21 Daniel Friesen 2009-08-23 03:14:15 UTC
(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.
Comment 22 merl 2009-11-08 04:54:19 UTC
+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.
Comment 23 Ilmari Karonen 2010-03-05 22:43:28 UTC
Done in r63300.
Comment 24 db [inactive,noenotif] 2010-09-03 18:04:32 UTC
*** Bug 25027 has been marked as a duplicate of this bug. ***

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


Navigation
Links