About this board

(Sub-) Page for each snippet?

As the list of snippets is growing I would suggest giving each snippet its own (sub-) page for providing a talk space for a more targeted discussion on each snippet. --Nakohdo 08:58, 14 February 2011 (UTC)

Support If and when we do this we might as well move it to "Snippets" or "Code snippets" at the same time since "jQuery" may be too specific (ie. sometimes a one-line JavaScript without using jQuery functions works fine, or perhaps a CSS-only trick).
This would also allow better searching as the name of the snippet will then be in the page title and thus searchwhat=title&prefix=Code_snippets can be used. Krinkle 11:06, 14 February 2011 (UTC)
Sounds fairly reasonable. I'm not sure if "code snippets" is too generic or not. There are two ways to go, maybe: "JavaScript snippets" or "Code snippets/PHP/Foo" / "Code snippets/JavaScript/Foo". Maybe I'm overthinking this, but a more generic title might lead to more generic content... not sure if that's a feature or a bug. --MZMcBride 02:00, 15 February 2011 (UTC)
It should be limited to front-end development. Anything that can run from site scripts, user scripts and gadgets.
Unless we use categories. Which allows some snippets to be put in "CSS" as well as "JavaScript" and other under "PHP".
Because of linking to this page from other wikis it's important to try to move it only once and for all. Krinkle 02:11, 15 February 2011 (UTC)
YesYDone. Moved to Snippets, created Template:Snippet and Category:Snippets (and subcategories) Krinkle 21:30, 15 February 2011 (UTC)
Thanks! --Nakohdo 09:33, 16 February 2011 (UTC)

Snippet to hide "Snippets/" from link names on Snippets category pages

This snippet makes the links on Category:All snippets et al. a bit more readable:

$( 'table li a' ).each(function(){
    $(this).text().replace( 'Snippets/', '' )

--Nakohdo 12:34, 17 February 2011 (UTC)

This is similar to the following script from pt.wikibooks: b:pt:MediaWiki:Gadget-Títulos simples.js. Helder 16:42, 17 February 2011 (UTC)
Thanks for the link. I suppose we will stumble across many re-invented wheels as this list will grow over time ;-) --Nakohdo 18:18, 17 February 2011 (UTC)
Here's a different version a bit like the prefixindex-snippet, without calling $() and .text() twice
if ( mw.config.get('wgPageName') == 'Category:All_snippets' ) {
$( '#mw-pages' ).find( 'table a' ).each(function(){
    return val.replace( 'Snippets/', '' );
Thanks again. Krinkle 18:32, 17 February 2011 (UTC)
find() and each() don't need to be called either. $() can find all links within a table within an element with an id attribute set to mw-pages. text() can be used to set the text for all matched elements. That is why text can take a function with index and value passed. Here's a version that takes that into account:
if ( mw.config.get( 'wgPageName' ) == 'Category:All_snippets' ) {
  $( '#mw-pages table a' ).text( function( i, val ) {
    return val.replace( 'Snippets/', '' );
--Darklama 13:49, 20 February 2011 (UTC)
Hi Darklama,
Calling both each() and text() is indeed redundant, not sure what I was thinking. The find() however was intentional as this gives a performance improvement (not much, but it does make a difference on larger category pages). As you may or may not know, selectors like Sizzle (which jQuery uses) and the browser engines that parse .css files parse selectors from right to left. Which means in the case of "#mw-pages table a" all <a>-tags will be selected, and checked if they have a direct or indirect parent that matches "table", which are then all of those are checked to see if they have a direct or indirect parent that matches #mw-pages. That's quite slow. In addition to the selector logic, there's also jQuery's quickExpr which can be used to select elements without initiating the selector engine at all. When selecting plain IDs (which pass quickExpr) jQuery will use document.getElementById instead of initiating Sizzle. By combining these two things, as a result you can use $('#id').find('foo bar'); to quickly select the ID-element, and then search for "foo bar" within that context (rather than the entire document). I can recommend these two videos from Paul Irish (developer at jQuery) in which he explains some other cool performance tips and tricks. Krinkle 15:32, 13 June 2011 (UTC)

Make it possible to import the snippets directly

He7d3r (talkcontribs)


I was wondering if wouldn't be better to have the snippets code in real .js pages (e.g. on MediaWiki: namespace, problably as gadgets) so that people could use

mw.loader.load( '//' );

instead of copying the source from Mediawiki pages. The migration guide suggests we should avoid duplication of code.

In case it is necessary to display the source on documentation page, that could be achieved easily by using something like


which results in

mw.loader.load( '//' );

which is the content of MediaWiki:Gadget-HotCat.js.

Krinkle (talkcontribs)

Indeed, but these are small snippets intended as inspiration or examples or so simple that they need no centralization.

The last thing you want is to load all of these as separate http requests for 10 lines of code, that'd be a significant cut in performance.

Stuff that is more advanced or stuff you think should be a gadget, simply make it a gadget and remove the snippet.

He7d3r (talkcontribs)

We should reconsider this, as there are many outdated copies of Snippets copied to WMF wikis' MediaWiki:Common.js pages (or default gadgets).

Reply to "Make it possible to import the snippets directly"

"How to use snippets" page missing

Nakohdo (talkcontribs)

Links from the individual snippet pages point to Snippets but content is not available (any more?).

Reply to ""How to use snippets" page missing"
There are no older topics