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)

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)

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)

Use manual:UserOptions.php (with extension:MaintenanceShell if you lack of shell access).--almaghi 14:58, 18 June 2009 (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.

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)

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)

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)

Did you mean different languages simultaneously, because on commons:Special:Preferences the whole are in English? JackPotte 16:55, 10 January 2010 (UTC)

HotCats

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)

I'm still interested to see if/how my gadgets are used. --Subfader 22:49, 17 April 2009 (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 <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)

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

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)

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)

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 Special:ExtensionDistributor/Gadgets

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

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)

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)

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: <snytaxhighlight lang="php">if ( $out->getTitle()->getNamespace() == NS_SPECIAL) { ... }</snytaxhighlight>

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)

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: <snytaxhighlight lang="php"> global $wgUser, $wgTitle; if ( !$wgUser->isLoggedIn() ) return true; //disable all gadgets on Special:Preferences if ( $wgTitle->getNamespace() == -1 ) { $name = SpecialPage::resolveAlias( $wgTitle->getText() ); </snytaxhighlight> 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 reportbugzilla: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)

but don't work

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

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

           }

</snytaxhighlight>

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 ?

"Solution" for 1.15

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

trunk version on 1.16.0beta3 = blank page

When I enable the trunk version of gadgets on 1.16.0beta3 I get a blank page.... any ideas?

I've tried the 1.15 version in 1.16.0beta3, and although it appears in special pages fine, the preferences tab does not appear.

Thanks 125.237.120.21 16 July 2010

I'm seeing the same issue on MediaWiki 1.17alpha (upgraded a month ago) if users attempt to log in with the latest (SVN) version of this extension active. The error logged to /var/log/httpd/error_log is:

[error] PHP Fatal error: Call to undefined method LinkBatch::setCaller() in ...extensions/Gadgets/Gadgets.php on line 180

This setCaller() function was added to MediaWiki as of revision 69171 2010-07-08 08:11:14 GMT. This extension was modified to require setCaller() one day later, here. If you installed MediaWiki before July 8, 2010 (or installed anything other than the latest SVN/trunk version) and installed the extension later? This extension is now attempting to call a setCaller() function which didn't exist in MW a month ago and bailing out with a fatal error and a blank browser screen.

As setCaller() appears to be intended just to get extra info into the log for debug purposes, my first reaction would be to suggest removing this line. --Carlb 22:06, 1 August 2010 (UTC)

If anyone else is reading this, User:Carlb is right! Thanks! Its save to remove that line Kwiki 04:22, 2 October 2010 (UTC)

Dependencies

Is it necessary to add 'mediawiki' and 'jquery' modules as dependencies? They seems to be always available (although 'mediawiki.util' is not, [1], [2], [3]), but I'm not sure it is safe to remove/not put them from/to b:pt:MediaWiki:Gadgets-definition. Helder 15:08, 9 March 2011 (UTC)

ResourceLoader|dependencies=site

If a gadget has [ResourceLoader|dependencies=site] attached to it, it seems to load the site JS twice. Is this supposed to happen? If it is, is there any way to have a gadget load after the site JS without doing that? --Yair rand 07:00, 8 April 2011 (UTC)

This is mostly a ResourceLoader issue, gadgets simply inform it what they need. I'll ask the RL authors about this. Max Semenik 07:19, 8 April 2011 (UTC)

Section headers too big

Is there anything that can be done to make the section headers smaller? Even thought most are defined using ==Header== or ===Sub header===, they are all displayed in in huge H1 headers. I can't find the code that generates the HTML, otherwise I would have prepared a patch myself. — Edokter (talk) — 11:44, 25 June 2011 (UTC)

Yes it's MEGA ugly. Go this waybugzilla:18113--Subfader 01:08, 26 June 2011 (UTC)

[default] option

== Question ==

When will the [default] and [position=top] (or however that will work) options be available? --Yair rand 13:22, 17 July 2011 (UTC)

In ResourceLoader 2.0. — Edokter (talk) — 14:51, 17 July 2011 (UTC)

The page for RL2 seems to indicate that it won't use the existing method of managing gadgets, meaning that the current syntax won't be used. Why does Gadgets show "[default]" as a possible setting if it will never actually be used? --Yair rand 15:12, 17 July 2011 (UTC)

Is the [default] option available on WMF sites or not? It would be very nice if this was mentioned on the page. —AlexSm 21:41, 1 September 2011 (UTC)

Fatal error: Call to undefined method OutputPage::getAllowedModules() in .....

I become this message, if i tried to activate any gadget in my wiki. whats wrong with it? please help me. Abani79 10:02, 14 September 2011 (UTC)
Fatal error: Call to undefined method OutputPage::getAllowedModules() in /users/xx/www/xx/extensions/Gadgets/Gadgets_body.php on line 165

No Gadgets displaying after apparently following extensions installation

• Version: MediaWiki - 1.19alpha; PHP - 5.2.5 (cgi); MySQL - 5.1.30-log
• Using Gadget version from matched tar zip file

1. Special Pages:Wiki Data and Tools:Gadgets >> says

"Below is a list of special gadgets users can enable on their preferences page, as defined by the definitions."

.... but the list is MT and there is no definitions page??

2. There is no 'Gagdets' tab in my preferences page??

Any ideas?

Have you created at least one gadget yet? If not, go to MediaWiki:Gadgets-definition and add e.g.

* my-gadget|my-gadget.css|my-gadget.js

Now I think Special:Gadgets will have a link to edit the JS/CSS code of your first gadget, and there will be a "Gadgets" tab in the preferences. Helder 12:05, 14 October 2011 (UTC)

Thanks Helder ...

As you suggested, I went to MediaWiki:Gadgets-definition clicked on 'view source' and copied the entire list of gadgets into my Gadgets-definition page [had to have admin rights] viz:

== interface-gadgets ==
* Edittop[ResourceLoader]|edittop.js
* UTCLiveClock[ResourceLoader]|UTCLiveClock.js
* ajaxrecentchanges|ajaxrecentchanges.js
.
.
.

and as you predicted, a list now shows under Special:Gadgets and a "Gadgets" tab now exists on the preferences page of all users.

Now to work out how to use them ..*smile*.. John 20:27, 14 October 2011 (UTC)

ResourceLoader + default

After some false starts at the English Wiktionary, we found that ResourceLoader doesn't seem to support Gadgets that are turned on by default. This meant that ...[ResourceLoader|default]|... didn't work, and also that ...[default]|....css didn't work. Is this a known issue? I feel that the documentation should mention it, as it's a large and surprising limitation on default. —Ruakh_TALK 13:05, 12 December 2011 (UTC)

Please provide more details. Just saying that it doesn't work isn't very helpful. It's been developed and known to work for CSS-based gadgets as well as ResourceLoader-enabled gadgets. If it does not work properly on the English Wiktionary, then we can speak of a bug, not a lacking feature. Krinkle 01:13, 15 December 2011 (UTC)

request for extension

asking for a way to collect user input in gadget page.

the way i see it: add a new option called "input" (that can't be used with default gadgets):

• input=radio:<Radio1,Radio2,Radio3>
• input=checkbox:<Checkbox1,Checkbox2,Checkbox3>
• input=text:<label>

IOW, the value of the "input" option will always begin with "checkbox:", "radio:" or "text:", and some more stuff, comma-delimited for checkbox and radios.

currently, any script can ask about "mw.user.options.get(Gadget_Name)", and receive null (for gadgets not selected), empty string (for default gadgets disabled by this user) or "1" for selected gadgets. after implementing the suggestion, the values will be null (for gadgets not selected), the name of the select radio button for input=radio:, some delimiter-separated (pesonally i like \n, but any delimiter is fine) list of selected checkboxes for input=checkbox:, or the content of the input field for input=text:

if this idea makes sense, and there is a will, i volunteer to write it - just don't want to bother if someone can think of a good reason why it shouldn't be done.

peace - קיפודנחש 19:04, 20 December 2011 (UTC)