Hi all,
I would like to ask for deployment of new version of Gadgets extension. It would be great to get rid of MediaWiki:Common.js by splitting it into separate gadgets, enabled for everyone by default. Any registered user will be able to disable functionality he/she does not like. What is more, it will simplify loading additional dependencies - now it is done by importScript etc. and allow to take advantage of Resource Loader.
Regards, Ildefons Stułbia
2011/6/7 Ildefons Stułbia ildefons.stulbia@gmail.com:
Hi all,
I would like to ask for deployment of new version of Gadgets extension. It would be great to get rid of MediaWiki:Common.js by splitting it into separate gadgets, enabled for everyone by default. Any registered user will be able to disable functionality he/she does not like. What is more, it will simplify loading additional dependencies - now it is done by importScript etc. and allow to take advantage of Resource Loader.
As far as I know, some version of Gadgets with ResourceLoader support is already live, although more recent fixes may not be included. Max or Krinkle can probably shed more light on this.
Roan Kattouw (Catrope)
On 07.06.2011, 17:52 Roan wrote:
2011/6/7 Ildefons Stułbia ildefons.stulbia@gmail.com:
Hi all,
I would like to ask for deployment of new version of Gadgets extension. It would be great to get rid of MediaWiki:Common.js by splitting it into separate gadgets, enabled for everyone by default. Any registered user will be able to disable functionality he/she does not like. What is more, it will simplify loading additional dependencies - now it is done by importScript etc. and allow to take advantage of Resource Loader.
As far as I know, some version of Gadgets with ResourceLoader support is already live, although more recent fixes may not be included. Max or Krinkle can probably shed more light on this.
Restrictions by permission, gadgets by default and API module aren't deployed yet. There is some unreviewed stuff at [1], I believe that trunk is sane enough for deployment once someone reviewed it.
[1] http://www.mediawiki.org/w/index.php?title=Special:Code/MediaWiki&path=%...
2011/6/7 Ildefons Stułbia ildefons.stulbia@gmail.com:
I would like to ask for deployment of new version of Gadgets extension. It would be great to get rid of MediaWiki:Common.js by splitting it into separate gadgets, enabled for everyone by default.
Well I'm not sure getting rid of Common.js is a good idea. But moving optional features to Gadgets isn't a bad idea.
-Chad
There's usually some code (general utility fn's, some legacy remappings etc.) in common.js that could break a lot of stuff if missing. +1 on moving optional stuff to gadgets
Leo On Tuesday, June 7, 2011 at 6:23 PM, Chad wrote:
2011/6/7 Ildefons Stułbia ildefons.stulbia@gmail.com:
I would like to ask for deployment of new version of Gadgets extension. It would be great to get rid of MediaWiki:Common.js by splitting it into separate gadgets, enabled for everyone by default.
Well I'm not sure getting rid of Common.js is a good idea. But moving optional features to Gadgets isn't a bad idea.
-Chad
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Default gadgets would solve an issue I am facing at the moment :)
So +1 to deployment of updates.
Tom
On 7 June 2011 22:25, Leo Koppelkamm diebuche@gmail.com wrote:
There's usually some code (general utility fn's, some legacy remappings etc.) in common.js that could break a lot of stuff if missing. +1 on moving optional stuff to gadgets
Leo On Tuesday, June 7, 2011 at 6:23 PM, Chad wrote:
2011/6/7 Ildefons Stułbia ildefons.stulbia@gmail.com:
I would like to ask for deployment of new version of Gadgets extension. It would be great to get rid of MediaWiki:Common.js by splitting it into separate gadgets, enabled for everyone by default.
Well I'm not sure getting rid of Common.js is a good idea. But moving optional features to Gadgets isn't a bad idea.
-Chad
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
2011/6/7 Leo Koppelkamm diebuche@gmail.com:
There's usually some code (general utility fn's, some legacy remappings etc.) in common.js that could break a lot of stuff if missing. +1 on moving optional stuff to gadgets
It depends on project. General utility functions should be available as modules, which can be loaded when there is such need (as a dependency to a gadget or by user/script explicitly). It makes easier to port gadget to other projects and maintain them, when its dependencies are well defined, so all changes can be easily tracked. Separate modules can be directly imported, which is impossible with overbloated MediaWiki:Common.js.
Regards, Ildefons Stułbia
2011/6/8 Ildefons Stułbia ildefons.stulbia@gmail.com:
2011/6/7 Leo Koppelkamm diebuche@gmail.com:
There's usually some code (general utility fn's, some legacy remappings etc.) in common.js that could break a lot of stuff if missing. +1 on moving optional stuff to gadgets
It depends on project. General utility functions should be available as modules, which can be loaded when there is such need (as a dependency to a gadget or by user/script explicitly). It makes easier to port gadget to other projects and maintain them, when its dependencies are well defined, so all changes can be easily tracked. Separate modules can be directly imported, which is impossible with overbloated MediaWiki:Common.js.
Yes, it does depend on the project, but I'm pretty sure that in most projects there are some chunks of js in Common.js that simply should not be disabled.
2011/6/8 Strainu strainu10@gmail.com:
Yes, it does depend on the project, but I'm pretty sure that in most projects there are some chunks of js in Common.js that simply should not be disabled.
In my opinion any custom ui feature should be optional, because it will never satisfy all users. It will also simplify developing and testing new versions of a gadget, by giving users an ability to turn off old version and turn on the new one. User having trouble with interfering scripts will be able to find out which ones by selectively disabling gadgets. Getting rid of MediaWiki:Common.js may not be feasible for all projects, in the end it is all up to sysops how much freedom they are willing to grant to contributors and viewers.
Regards, Ildefons Stułbia
Subject was: Update Gadgets extension on WMF wikis
This part of the thread is hereby forked to discuss MediaWiki:Common.js. I do not believe MediaWiki:Common.js should be deleted (atleast not yet), I'm merely curious what usecases people have for it which may or may not be useful to be taken into account during the upcoming revision of ResourceLoader and Gadgets.
Ildefons Stułbia wrote:
2011/6/7 Leo Koppelkamm diebuche@gmail.com:
There's usually some code (general utility fn's, some legacy remappings etc.) in common.js that could break a lot of stuff if missing. +1 on moving optional stuff to gadgets
It depends on project. General utility functions should be available as modules, which can be loaded when there is such need (as a dependency to a gadget or by user/script explicitly). It makes easier to port gadget to other projects and maintain them, when its dependencies are well defined, so all changes can be easily tracked. Separate modules can be directly imported, which is impossible with overbloated MediaWiki:Common.js.
Regards, Ildefons Stułbia
Indeed.
Regardless of what it's most common purpose has become (and nobody blames anybody for any of that, becaus wikis simple do what they must, with the tools they're given).. most things that are in Common.js should not be.
I think only a few things (if at all) should eventually stay in MediaWiki:Common.js. I'm having a hard time coming up with examples, but basically only stuff that is truly specific to that particular wiki and not related to end-users in any way.
For example custom config variables (wgFooBar) or central enhancements such as * scripts to move custom icons to the top of the page next to the title * some kind of interaction on the Main Page that is dependant
But then again, I can imagine the top-icon-script being a gadget that would be imported to our central wiki as a "global gadget" that local wikis can enable/disable and, in most cases, set to "default": "on". And something that does awesome things to the main page ? Probably something that is useful and could be made more generic for use in other wikis.
So in more cases than one might think, gadgets are or will be better suited for almost anything.
For example javascript libraries or jquery plugins should be stored as gadget modules that are indicated as "hidden" (or "private", the name hasn't been decided yet), which other gadgets can register as a dependancy.
ie. Gadget-foo (dependancies: somelib, jquery.foobar, gadget-loremipsum)
Question: Do you think MediaWiki:Common.js has future-proof usecases given the current plans ? If so, please share them in this thread.
Again, nobody is threatening the existance of MediaWiki:Common.js, even if it would just be for legacy reasons (because millions of wikis are using it), it will not be removed any time in near or far future.
Thanks, – Krinkle
On Wed, Jun 8, 2011 at 12:16 PM, Krinkle krinklemail@gmail.com wrote:
Subject was: Update Gadgets extension on WMF wikis
This part of the thread is hereby forked to discuss MediaWiki:Common.js. I do not believe MediaWiki:Common.js should be deleted (atleast not yet), I'm merely curious what usecases people have for it which may or may not be useful to be taken into account during the upcoming revision of ResourceLoader and Gadgets.
In general, modular gadgets will be a better way in the future to create, maintain, share, and re-use client-side code components, as it will provide better infrastructure for doing those things versus manually cut-and-pasting a few bits of code.
At the moment, we're only partway there; sharing things from site to site is still awkward, and there's not a good management interface for site admins to work with.
Obviously MediaWiki:Common.js won't be removed in the short term (and may stay around for compat for a long long time).
-- brion
On Wed, Jun 8, 2011 at 16:16, Krinkle krinklemail@gmail.com wrote:
I think only a few things (if at all) should eventually stay in MediaWiki:Common.js. I'm having a hard time coming up with examples, but basically only stuff that is truly specific to that particular wiki and not related to end-users in any way.
For example custom config variables (wgFooBar) or central enhancements such as
- scripts to move custom icons to the top of the page next to the title
- some kind of interaction on the Main Page that is dependant
On some Wikibooks projects (en, it, pt) for example, it was added a variable
wgBookName[1], which is used e.g. to import book specific gadgets[2] (at least while MediaWiki is not able to provide per-book stylesheets[3]).
But then again, I can imagine the top-icon-script being a gadget that
would be imported to our central wiki as a "global gadget" that local wikis can enable/disable and, in most cases, set to "default": "on". And something that does awesome things to the main page ? Probably something that is useful and could be made more generic for use in other wikis.
So in more cases than one might think, gadgets are or will be better suited for almost anything.
There is also the script wich process the withJS and withCSS url parameters, which are used in various wikiprojects but doesn't seems to be adequate for global gadgets (what would be the point of letting the users to disable this?)
For example javascript libraries or jquery plugins should be stored as gadget modules that are indicated as "hidden" (or "private", the name hasn't been decided yet), which other gadgets can register as a dependancy.
ie. Gadget-foo (dependancies: somelib, jquery.foobar, gadget-loremipsum)
Should this be made locally by the local admins in MediaWiki:SpecificPages.js, or the users should request on Bugzilla the addition of new plugins to MediaWiki (such as jQuery.hotkeys[7])?
Question:
Do you think MediaWiki:Common.js has future-proof usecases given the current plans ? If so, please share them in this thread.
Still talking about Wikibooks, there are scripts such as the one used to add a link to the sidebar providing access to a random bug (which is a workaround to another open bug[5]). Such an script could be useful as a global gadget, but only for wikis where there is a heavy use of subpages for (manual) meta-organization[6] of the content of the books (mainly Wikibooks and Wikisources).
Regards, Helder
[1] https://secure.wikimedia.org/wikibooks/en/wiki/MediaWiki:Common.js [2] https://secure.wikimedia.org/wikibooks/en/wiki/MediaWiki:Common.js/Perbook.j... [3] https://bugzilla.wikimedia.org/show_bug.cgi?id=15075 [4] https://secure.wikimedia.org/wikibooks/en/wiki/MediaWiki:Common.js/RandomBoo... [5] https://bugzilla.wikimedia.org/show_bug.cgi?id=16655 [6] https://bugzilla.wikimedia.org/show_bug.cgi?id=15071 [7] https://bugzilla.wikimedia.org/show_bug.cgi?id=27493
On Wed, Jun 8, 2011 at 18:08, Helder helder.wiki@gmail.com wrote:
Still talking about Wikibooks, there are scripts such as the one used to add a link to the sidebar providing access to a random bug (which is a workaround to another open bug[5]).
I meant "providing access to a random **book**".
Helder
wikitech-l@lists.wikimedia.org