Extension talk:Gadgets/Archive

Default switch
How about a default switch that enables a gadget by default until the user removes the checkbox by himself? I envision a syntx like: * mygadget|mygadget.js|mygadget.css|on This would be very useful for gadgets that are enabled by default but people perhapes want to deactivate themselves, such as commons:MediaWiki:Extra-tabs.js. However this collides with current MdiaWiki:Common.js and MediaWiki:Monobook.js but switching all scripts on and off in one place would be a very nice thing. Arnomane 14:20, 13 September 2007 (UTC)
 * Hm.... maybe :) Don't have time to play with it right now, remind me if i forget. -- Duesentrieb ⇌ 21:59, 13 September 2007 (UTC)
 * I agree this feature would be very useful, please count this as a reminder ∴ AlexSm 00:42, 20 December 2007 (UTC)
 * Any progress? --Jonathan Kovaciny 17:56, 14 April 2008 (UTC)

css/js file name format
What is the point of requiring files to be in MediaWiki:Gadget-xxx format? Some of the user scripts are on a user subpage, and even for the rest it seems uncomfortable. It will result in css/js "redirects" containing only an @import/document.write loading the real script, which means browsers will need to download two files instead of one. --Tgr 21:48, 19 December 2007 (UTC)
 * You're supposed to copy the code into MediaWiki:Gadget-xxx.js page. This is done intentionally so only admins can alter the code, however I agree this is definitely not convenient for non-admin scripts authors ∴ AlexSm 00:42, 20 December 2007 (UTC)

css/js user subpages can also be edited by admins only, plus the one user who owns the subpage (and, being the script author, is probably trusted), so not much difference there. --Tgr 13:20, 24 December 2007 (UTC)
 * No this is not true for user sub pages in general, just for certain user sub pages. Most of the user scripts are written in a complex way not directly reusable as a single module (it's often a hard task to extract the single modules) and furthermore are often using several pages which often are writebale by everyone. Furthermore it is very useful for maintenance to have one common structure for all scripts (beside the security advantage that MediaWiki namespace is always only writable by admins). But anyways you can solve your problem easily with a "document.write", see de:MediaWiki:Gadget-WikiMiniAtlas.js (but know what you're doing!). Arnomane 01:23, 14 January 2008 (UTC)


 * 1) Tgr clearly said "css/js user subpages", not "user sub pages in general". 2) Actually most user scripts either use same author modules or do not use any. 3) Tgr already mentioned document.write solution, but in the most common case where other script is on the same project this results in definite loss of performance ∴ AlexSm 03:53, 14 January 2008 (UTC)

Usage stats
Another Gadgets disadvantage (compared to standard userscript) is that you don't know how many users enabled particular gadget. Would it be possible to fix this? ∴ AlexSm 00:42, 20 December 2007 (UTC)

Enable by default
How can you enable a gadget by default? I think something with $wgDefaultUserOptions, but that does not seem to work. SPQRobin 15:01, 25 December 2007 (UTC)


 * See the first comment on this page.
 * Anyway, using $wgDefaultUserOptions should work: For the gadget "foo", try $wgDefaultUserOptions['gadget-foo'] = true; that should work (for anons(!) and new users), but i have not tried it. -- Duesentrieb ⇌ 20:42, 25 December 2007 (UTC)


 * I just tried it, and it does not work. SPQRobin 16:36, 26 December 2007 (UTC)
 * Sorry, no idea why. -- Duesentrieb ⇌ 22:35, 5 January 2008 (UTC)
 * For me it is working. I am using MW 1.13alpha (r1) with Gadgets (Version r34525) --Bisato 09:35, 28 May 2008 (UTC)

Substantial addition
I was thinking about the abillity to make w:WP:TW as a gadget, but at the moment there are some things missing to make it work. → Aza Toth 22:53, 29 December 2007 (UTC)
 * 1) First it should be possible to add the whole twinkle as a bundle, but at the same time select and unselect individual modules.
 * 2) All modules will depend on a common library (morebits.js), but it should only be included once.
 * 3) As it won't work under IE, there should be possible to exclude the ability for IE user to use the gadget.
 * 4) There should be a nice way to handle preferences, including strings, booleans, arrays etc... It should be locality independent (i.e. be saved on the server).
 * 5) Some modules are only suitable for admins, so some checks there as well.
 * 6) Admins must be able to remove modules from users.

First of all: I'll not be doing any substantial coding any time soon. need to finish my diploma. Here are some thoughts anyway: HTH -- Duesentrieb ⇌ 22:34, 5 January 2008 (UTC)
 * 1) not sure how to do this nicely. why not simply offer the different function-sets, and let dependencies sort themselves out?
 * 2) common libraries are already only included once.
 * 3) browser detection is unreliable, and also, someone might edit preferences in one browser, and use another browser later. Gadgets should generally work on most browsers, and if they don't, there should simply be a warning in the description. And the gadget should be written to at least degrade gracefully (i.e. not get eratic on the "wrong" browser).
 * 4) a way to handle complex preferences and attach them here would be nice - but it's not trivial, and i'm not up to implementing it here. If someone does write it, it should be in a way that can be re-used by different extensions.
 * 5) yes, hiding gadgets depending on user/group permissions is already on the todo list
 * 6) blocking individual users from using individual gadgets seems overly complex, and also pointless (they can always be enabled by editing user JS manually). If we had a general facility for blocking individual users from using specific mediawiki features, the gadgets extension could be made to hook into that. But a gadget-specific solution seems a bad idea.

Gadget scripts loaded too early
Hey Duesentrieb! Is there a reason for the Gadget javascripts beeing loaded so early during in the page? We have some tools on commons which use functions and objects from Mediawiki:Common.js, unfortunately the gadget are loaded before common.js, breaking those tools. I could work around by queuing onLoad handlers for the initialisation of those scripts, but just moving the corresponding script tags below the common.js stuff would already solve the problem. --Dschwen 21:53, 5 January 2008 (UTC)


 * Sadly, I have no control over the order of inclusion. This is hardcoded in the MediaWiki core. Whene I wrote the extension, common.js was loaded before the gadget code, and user js was loaded before, also. This meant that users could not override gadget stuff, or easily customize it - I mentioned this in a caveat, the relevant bug report is 10184. This got "fixed" by simetrical 28455, but now, common.js is also loaded after the gadget stuff - which is, I completely agree with you, not right. Please re-open the bug report, or open a new one, and/or talk to Simetrical about this. I don't have time right now to mess with MediaWiki proper, especially with sensitive stuff like include order. -- Duesentrieb ⇌ 22:27, 5 January 2008 (UTC)


 * Re-opened the bugreport. --Dschwen 22:46, 5 January 2008 (UTC)


 * Gadget dependencies should be handled by listing them in the correct order in the Gadegets configaturation list
 * I would consider that Common.js is a gadget, however it is not made directly selectable as it realizes no function
 * However it could be listed by indenting it in the list, by taking into account the number of "*", or by listing it with an additional ":" just after the last "*" to indicate that it is not selectable directly in the USer preferences, or by adding one parameter in the config line (after another "|").
 * This would give something like:


 * Common.js
 * Some gadget 1 depending on Common.js
 * Some gadget 2 depending on Common.js
 * Some gadget3 not depending on Common.js
 * the order would be significant.
 * May be another solution could be used for dependant scripts shared by several projects, but for now, it's Common.js that is the only script shared, I think, so let's not generalize it too early. The basic concept should be finally to list javascript dependencies in a way similar to PHP's "require" statement. The configuration file would be read, some scripts would be selectable by users, some other not but selected indirectly by dependency only.
 * Note that more than half of "standard" gadgets simply don't work on Commons (lots of of Javascript errors when viewing Commons pages for images or categories), due to missing scripts or incorrect order, or missing/undefined variables. 90.45.238.184 12:30, 12 January 2008 (UTC)

Uh, using commons "library" scripts is already possible with Gadgets - this just doesn't work for Common.js, butcause that is jhandeled specially by mediawiki. -- Duesentrieb ⇌ 14:03, 12 January 2008 (UTC)

Section names
I have successfully installed the extension, I have successfully added a gadget, but all of my gadget sections and gadget names are things like . How do I fix this? --217.120.159.198 20:10, 17 February 2008 (UTC)
 * By Editing MediaWiki:gadget-section-Design - the section names refer to system messages, just like the gadget ids do. This way, the section names can be translated into different language. -- Duesentrieb ⇌ 21:18, 17 February 2008 (UTC)
 * Thanks, your help's appreciated. :) --217.120.159.198 21:41, 17 February 2008 (UTC)

I have added a new gadget (HotCats under "Wobdźěłanje") into w:hsb:MediaWiki:Gadgets-definition. I also added a page w:hsb:MediaWiki:Gadget-HotCats, but the text doesnt apeare on w:hsb:Specialnje:Gadgets. Wat can I do? The first gadget (WikEd) there works very well. Greetings --Tlustulimu 09:48, 29 May 2008 (UTC)
 * Looks like it's working to me. Mike.lifeguard 02:28, 1 June 2008 (UTC)

LastChangeDate
Hi, unfortunately the date doesn't seem to work: Potter Wiki. Did I do something wrong? Best regards, Karsten 84.171.145.107 17:18, 17 April 2008 (UTC)

Usage info
Is there a way to see how many users enabled a certain gadget? --Subfader 12:21, 22 June 2008 (UTC)

Error OutputPage::addWikiMsg
I installed Gadgets and create 2 gadgets corretly but when I load Special:Preferences show:

Fatal error: Call to undefined method OutputPage::addWikiMsg in /var/www/wiki/extensions/Gadgets/Gadgets.php on line 155

If I comment line 155 // $out->addWikiMsg( 'gadgets-prefstext' );

its works but puts  on gadgets section in h2 tag

Where is my mistake?


 * I also experience this problem with v1.11.0. You have to upgrade the MediaWiki software. Aviator 15:04, 6 September 2008 (UTC)

NOT WORKING - Need help Please
Hi,

I've followed these instructions to install this, but, it doesn't seem to work. When I put the "require one" line into local.settings.php and save it, I can no longer access our wiki (at all) - we just get a blank screen. When I comment the line out, our wiki works as it should/used to.

We are, obviously, not getting the Gadgets tab.

Is there something I could be doing wrong? It seems that when the 'gadgets.php' file gets called it crashes (but, I don't know where)...

Thanks in advance! Dan


 * Be sure to enter the  at the end of LocalSettings.php. If you use other extensions try changing their including order. Otherwise check Manual:Extensions --Subfader 20:31, 11 February 2009 (UTC)

Thanks - I'll have to check that out as I have NO extenstions installed currently. I'm just trying to get this gadgets piece up and running. I'll check out that link tomorrow AM and let you know how it works out. ~Dan

Integrate gadget settings into standard pref sections
For the standard user the gadgets are just a collection of extra settings. He doesn't / shouldn't bother if its a MediaWiki core feature or a user script (while user script is only half correct since it's still enabled by admin / sysops though). The user instead needs to ask himself whatthe heck Gadgets are and why they are not logically sorted under the other sections but srted into h2 sections on the page (see Wikipedia).

MediaWiki:Gadgets-definition should be able to let you list gadgets into the standard sections or create new sections for it.

E.g. "Make text fields (e.g. the edit form) use a sans-serif font instead of a monospace font." would be better placed in the #Editing section. Just my feelings. Example set-up of the Gadgets-definition:


 * 1) Editing
 * wikEd|wikEd.js
 * textareasansserif|textareasansserif.css


 * 1) Interface
 * exlinks|exlinks.js
 * purgeTab|purgeTab.js


 * 1) Misc

library-gadgets

 * JSL|JSL.js

The checkboxes for wikEd and textareasansserif would be added at the end of the Editing section Interface would be a new section at the end (but before the standard Misc imo) including the stated two Gadgets. At the end of the standard Misc section a new h2 would be added with JSL below. If no #section was defined in the Gadgets-definition, create #Gadgets as is handled atm.

Makes sense to me ;) --Subfader 22:31, 18 March 2009 (UTC)

Spaces before the '*' (in definition list)
Yeah, I just pent the better part of two hours trying to get this to work, and I finally realized that it was because I had a space before the asterisk in my definition list. Would it be possible to have the extension work when this happens? --w-dueck 23:56, 6 April 2009 (UTC)