Extension talk:Gadgets

From MediaWiki.org

[edit] 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)

You can run a maintenance script to choose the user options. UserOptions.php For example if you want to enable HotCat gadget, run the command:

php userOptions.php gadget-HotCat --new 1 --old ''

The gadgets' options are called: gadget-$gname e.g. gadget-HotCat for MediaWiki:Gadget-HotCat.js

See also : extension:maintenanceShell --almaghi 07:13, 16 June 2009 (UTC)

Will this works only for existent users of also for new users (with account created before we run the script)? Helder 23:00, 15 September 2009 (UTC)

[edit] 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)

[edit] 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)

[edit] 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)

Use manual:UserOptions.php (with extension:MaintenanceShell if you lack of shell access).--almaghi 14:58, 18 June 2009 (UTC)

[edit] 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.

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.

_→AzaToth 22:53, 29 December 2007 (UTC)

First of all: I'll not be doing any substantial coding any time soon. need to finish my diploma. Here are some thoughts anyway:

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.

HTH -- Duesentrieb ⇌ 22:34, 5 January 2008 (UTC)

[edit] 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 Bugzilla:10184. This got "fixed" by simetrical rev: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)

[edit] 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 <gadget-section-Design>. 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)

[edit] 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)

[edit] Usage info

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

I'm still interested to see if/how my gadgets are used. --Subfader 22:49, 17 April 2009 (UTC)

[edit] 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 <gadget-section-interface-gadgets> 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)

[edit] 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 require_once("extensions/Gadgets/Gadgets.php"); at the end of LocalSettings.php. If you use other extensions try changing their including order. Otherwise check Manual:Extensions#Installing_an_extension --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

[edit] 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:

#Editing
* wikEd|wikEd.js
* textareasansserif|textareasansserif.css

#Interface
* exlinks|exlinks.js
* purgeTab|purgeTab.js

#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)

[edit] 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)

The * is standard wiki markup for lists. You learn that in the first days using MW ;) --Subfader 13:42, 7 April 2009 (UTC)

[edit] Download error

svn: Working copy '/mnt/upload5/private/ExtensionDistributor/mw-snapshot/branches/REL1_14/extensions' locked
svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)

when trying to download with http://www.mediawiki.org/wiki/Special:ExtensionDistributor/Gadgets

--SuperFLoh 10:39, 16 April 2009 (UTC)

[edit] Name of the user gadgets options to do maintenance

Hi. How are generally named the user options of the gadgets ? (for example the preference of HotCat.) almaghi 14:47, 3 June 2009 (UTC)

gadget-$gname e.g. gadget-HotCat for MediaWiki:Gadget-HotCat.js --almaghi 09:30, 10 June 2009 (UTC)

[edit] No "Gadgets" tab in Special:Preferences (solved)

I have installed the extension (I can see it in the Special:Version page). I have added a couple of gadgets: Navigation popups and wikEd (I can see them in the Special:Gadgets page). But in the Special:Preferences page there is no "Gadgets" tab.

I'm using MediaWiki 1.13.3 in Spanish and Gadgets extension rev. 50301 (newer revisions throws "Undefined OutputPage::getTitle" errors).

EDIT: I have updated MediaWiki software to 1.15.0 and still the same problem.

--ajvico, 08:59, 19 June 2009 (UTC)

OK. Solved. The hooks for the preferences page used from revision 49790 aren't available in MediaWiki 1.15.0.

I have downgraded the Gadgets extension to revision 49579 and now seems to work.

--ajvico, 10:11, 19 June 2009 (UTC)

[edit] Gadgets extension r52070 broken with MW-1.15.0?

I updated to the Gadgets extension through SVN to revision 52070, and it doesn't work with MW-1.15.0:

Fatal error: Call to undefined method OutputPage::getTitle() in /srv/www/htdocs/wiki/extensions/Gadgets/Gadgets.php on line 166

Line 166 in Gadgets.php points to wfGadgetsBeforePageDisplay(), specifically:

if ( $out->getTitle()->getNamespace() == NS_SPECIAL) { ... }

However, OutputPage has no getTitle() function; rather it has getPageTitle() (making it nicely incompatible with the other classes that could presumably be underlying instances of $out). ViktorHaag 13:15, 18 June 2009 (UTC)

i got the same problem:

Warning: Missing argument 1 for wfGadgetsInjectMessages() in $IP/extensions/Gadgets/Gadgets.php on line 214

Fatal error: Call to undefined method OutputPage::getTitle() in $IP/extensions/Gadgets/Gadgets.php on line 166

have you (or anyone) managed to find a solution?

Bud0011 08:07, 21 June 2009 (UTC)

[edit] solution 1

I've made a couple updates...dunno if this fixes it for everyone or not, due to all the other problems that are ongoing. I've made these changes, and i think they work...only problem is that I'm not seeing the "gadgets" tab, as other people have mentioned. But, here are my suggested edits that you might want to try:

	global $wgUser, $wgTitle;
	if ( !$wgUser->isLoggedIn() ) return true;
	//disable all gadgets on Special:Preferences
	if ( $wgTitle->getNamespace() == -1 ) { 
		$name = SpecialPage::resolveAlias( $wgTitle->getText() );

That cleared up the errors on my end. Also, to resolve the error on line 214, i wonder if you can remove the variable from the function, and then declare $msgCache as a global? Just a thought.--Duke33 20:59, 28 June 2009 (UTC)

I opened a bug report https://bugzilla.wikimedia.org/show_bug.cgi?id=19431 --Subfader 17:06, 29 June 2009 (UTC)

Don't use the trunk version of an extension with an old version of core. Use the old version of the extension with the older MediaWiki that you are using. Andrew Garrett 17:32, 29 June 2009 (UTC)

[edit] but don't work

this new code don't work too Phd0 12:36, 5 July 2009 (UTC)

	//disable all gadgets on Special:Preferences
	if ( $wgTitle->getNamespace() == -1 ) { 
		$name = SpecialPage::resolveAlias( $wgTitle->getText() );
            }

Fatal error: Call to a member function getNamespace() on a non-object in /var/lib/mediawiki/extensions/Gadgets/Gadgets.php on line 165

but i dont't know anything in PHP, can you help us ?

[edit] "Solution" for 1.15

Download from here here. --Subfader 23:11, 7 July 2009 (UTC)