Template talk:Extension/Archive 1

Example Link

Hello, Is there any complaints if we add to this a link to where the extension can be seen in action? --Rick 03:28, 25 September 2006 (UTC)

No - that sounds sensible. --HappyDog 11:59, 25 September 2006 (UTC)

ditto --:Bdk: 16:01, 25 September 2006 (UTC)

I still see no link to an implementation of this extension (three years after the last comment). Anybody know of one? 204.8.227.40 16:09, 14 November 2010 (UTC)

Formatting is weird

Take a look at Extension:OpenID. What's going on? --wikitravel:User:Evan

I'm not sure what you mean - please elaborate. --HappyDog 19:16, 21 October 2006 (UTC)

Here is?

Why the change from "This is a MediaWiki Extension" to "Here is a MediaWiki Extension"? I think it sounds frivolous. I propose it is reverted. If anyone is against reverting it, please speak up... --Fernando Correia 10:24, 1 February 2007 (UTC)

I agree, I reverted it.--Patrick 10:29, 1 February 2007 (UTC)

Tools

I propose that a new type is added to the list: "tool". This could be used to indicate modules that provide additional functionality to a MediaWiki installation. Examples would be Extension:AddPageService and Extension:Word2MediaWikiPlus. --Fernando Correia 13:52, 20 February 2007 (UTC)

Perhaps it would be even better to have a separate namespace for them. After all, they are not really extensions. -- Duesentrieb ⇌ 23:46, 22 February 2007 (UTC)

That may be a good way. Although they "extend" MediaWiki core functionality, they are really not extensions in the sense that they are called by MediaWiki code. Actually the call MediaWiki. They are similar to pywikipediabot and to the "maintenance" directory scripts. Anyway, I think a clarification on this would be helpful, because some tools used to be classified as extensions on Meta, and at the same time classified as Category:MediaWiki tools. --Fernando Correia 11:11, 23 February 2007 (UTC)

The namespace was originally designed to hold all 3rd party extensions relating to MediaWiki (including tools that are worked on in the MediaWiki SVN tree, but which are not distributed as part of a standard MW install). Therefore tools should be included in the extensions namespace. Only include tools that are specifically MediaWiki related, e.g. a Notepad style text editor that happens to be usable as an external MW editor (via user preferences) should perhaps be listed on a page of compatible editors, but it doesn't deserve its own page as a 'MediaWiki tool'. Ditto stuff like apache or MySQL.

If we find that there are a sufficiently large number of MW-related tools that they warrant their own namespace then it might be worth creating one, but I suspect not. A better solution might be to use a different infobox for tools. Or at the very least, it should be expressed in this box very clearly... --HappyDog 01:43, 22 March 2007 (UTC)

I'm glad you think they belong in the Extensions namespace. So, I propose that a new type is added to the list of extension types: "tool". --Fernando Correia 20:36, 22 March 2007 (UTC)

Categorise by author

I tried to get the template to categorise into Category:Extensions by "author" but couldn't get it to work. --Nad 21:38, 22 February 2007 (UTC)

Personally, I don't think this is very useful. I would suggest a better approach would be to create a new category called something like Extension authors, which authors can add to their user page, which should list all extensions they have authored. Aside from satisfying the OCDers desire to categorise, I have yet to see a useful application of listing extensions by author... --HappyDog 01:43, 22 March 2007 (UTC)

Extension of multiple types

Extension:Semantic MediaWiki adds an <ask> query parser, hooks wiki text and page handling, and adds several special pages. But

 | type = parser, hook, special

puts it in "Category to catch extensions with an unrecognised type". It should be in all three extension categories. -- Skierpage 05:22, 17 March 2007 (UTC)

I added that combination. More combinations may have to be added. An alternative would have been to have a boolean parameter for each type.--Patrick 07:18, 17 March 2007 (UTC)

I guess the question is, why are we categorising and displaying this information? I would suggest it is so that people can find extensions, therefore 'special' is for extensions that are special pages (e.g. providing meta information), 'parser' is for extensions that add an extra piece of syntax. If an extension is both, then it should be listed under it's main purpose. E.g. a special page that uses a tag to gather its data (e.g. a special 'dump' page that provides a tarball of all pages that have the requested attribute in a <dump> tag) should be 'special'. A tag that is supported by a special page (in the same way that the ISBN magic word works) should be 'parser'. In cases where an extension is made up of all these different components, I feel that it should really be in a separate category, e.g. 'mixed'. --HappyDog 01:43, 22 March 2007 (UTC)

I'd rather have specific categories for each various extension type because it makes sorting/finding extensions easier and more intuitive. Special page extensions are not just extensions that are special pages but ones that manipulate/alter/edit/redisplay special pages, too. Multiple extension type support is badly needed in this template. It's too confusing to try and figure out which "mother" type extensions belong to, which is why I've been adding various categories for form, table, list, etc under category:extensions by category (nice redundant name, eh?). -Eep² 05:35, 29 July 2007 (UTC)

Support for up to 6 types in any order, added as of 2007-09-08, Egfrank 19:45, 8 September 2007 (UTC)

Extra info for template users

The template page could use some additional "noinclude" comments for extension users. In particular I am confused by some of the terms like hooks. Does this mean that the extension uses a hook or creates a hook? I assumed the former, but this and other items could use additional comments/instructions for newbies. --Sunergos 19:18, 22 April 2007 (UTC)

There is no 'hooks' parameter. 'hook' is one of the potential extension types, so if your extension creates a new parser tag then you should use this type. --HappyDog 22:59, 20 May 2007 (UTC)

Question about style object - css

Hi,

I'm interresting to use a similar extension into my wiki. I try to understand how it works but i don't understand where the class object are located (first line of your template: class="ext-infobox ext-status-{.... I seen MediaWiki:Monobook.css but not found information about ext-infobox.

Thx, --Ouaibsky 13:48, 21 May 2007 (UTC)

extension by subcategory

I have created a duplicate template so that subcategorized extensions can reside within either category:extension or in their own category:subcategory, but not both. Bouncingmolar 01:07, 25 June 2007 (UTC)

Additional fields depends/suggests

Two additional fields could be added, one for extension dependancies (depends) and one for suggests which could be other extensions or third party code such as http://mootools.net or whatever --Zven 23:43, 25 June 2007 (UTC)

Extension Lang

I want to make Template:Extension/es in spanish

who agree?

--Hsilamot 00:27, 9 July 2007 (UTC)

I'm not sure how useful this would be. A Spanish version of the template would only be placed on Spanish versions of the extension page (e.g. Extension:MyExtension/es), and these pages will need to be translations of the English version to which they are connected. Personally, I think attempting to translate the extension namespace is a bit of a lost cause, as it is written by the extension authors and changes so much that any translations will become out of date very quickly. My recommendation would be that it is not worth creating this template unless there are a sufficient number of Spanish extension translations to make it worthwhile. --HappyDog 21:37, 11 July 2007 (UTC)

How about just making this template language aware? The tags can be set somewhere and a new parameter can be set, e.g. "lang". The default to be English. This way, the links to the hooks, etc. can be to the ones in the correct language. --Kimon 15:11, 31 October 2007 (UTC)

template field

obsolete status

there are some extensions which may have become obsolete because of changes to mediawiki. should there be a special status for them? Extension:Email_notification - Bouncingmolar 02:29, 15 July 2007 (UTC)

Probably. I suggest 'obsolete' :-) I will add that sometime soon and post here when it's done. --HappyDog 16:40, 24 July 2007 (UTC)

I have added it as historical, because retaining the pages is only for historical interest. I stole this idea from the enotif extension which the author used the template {{historical}} I have also added this template to the extension template conditionally for when the status is set to historical. Bouncingmolar 23:26, 24 July 2007 (UTC)

'obsolete' would probably be better, as that is what is used elsewhere on the site. The historical template was copied from meta in March because Extensions that had been copied here used it, but we should be working towards some kind of consistency here, I think. That said, there may be a case for having both that I have not thought of... --HappyDog 23:48, 24 July 2007 (UTC)

ok i have changed historical to obsolete. I will just start tidying up a few loose ends Bouncingmolar 00:11, 25 July 2007 (UTC)

the template:obsolete doesn't seem to apply to extensions that have been replaced by better extension versions (see Extension:Open Office Export). I have left the template:historical for the moment Bouncingmolar 00:14, 25 July 2007 (UTC)

Hmmm... You're right. I guess we need to think about that. Why extensions 'no good'?

• Broken - don't work. These should have status 'experimental', I think.
• Replaced by built-in functionality - obsolete from version X (but still useful for people using older versions)
• Replaced by a different extension that offers the same (or more) functionality. Note that 'similar' is not a good enough reason, as some people may prefer extension 1, while others prefer extension 2.

I don't know if you can think of any more scenarios...

For that last one, I would suggest that instead of a new status, we should have a field 'replacedby' that allows you to specify an alternative extension as a replacement. The status may be 'beta status' but never finished because someone got there first. We lose this info if we replace 'beta' with 'historical'.

--HappyDog 00:23, 25 July 2007 (UTC)

True re: historical/beta. hmmm if only we could have more than one status. Bouncingmolar 00:40, 25 July 2007 (UTC)

This has since been reverted without any discussion by user:Voice of All Can someone please explain this? Bouncingmolar 05:42, 30 July 2007 (UTC)

field for extension stored externally

There are many extensions I have noticed that have their main content located on another site (eg bluecortex). Perhaps there should be a field such as "main site" which allows authors to put their content there, that way we can include in the template a warning message saying that more up to date info can be found on eg:bluecortex Bouncingmolar 00:48, 25 July 2007 (UTC) I would prefer if all the content was on mediawiki.org, but many authors are already avoiding that.. Bouncingmolar 00:49, 25 July 2007 (UTC)

Well, take a look at my WikiDB extension. That has most content held off-site, but still has a page here with the basic information and links to the detail. I don't think there is any need to flag up 'off-site' extensions, except to note it on the extension page itself. --HappyDog 13:03, 25 July 2007 (UTC)

I agree. That method has worked very well for your extension, but I have viewed many extension pages which do not do as you have done. Perhaps adding a field with a similar meaning to offsite storage, then it could be included in the template and a standardised message (similar to the one on your page) could be put to tell people to visit the offsite link. At the moment I have been doing what you have done on your extension page, and pysically visiting the offsite extension and copying some of the info back here and adding a custom message to visit the offiste page for a more up to date version. I made this suggestion after seeing a need for it. Bouncingmolar 05:27, 30 July 2007 (UTC)

Add type: authentication

There's quite a few extensions that deal with authentication, can we add a type for these?

See Extension:Shibboleth Authentication for an example. Djcapelis 21:47, 23 July 2007 (UTC)

No - that's not what the type is for. We are in the process of working out a way to include the purpose(s) of an extension in the template, and once that's done then functional groupings (e.g. "authentication extensions") will be created automatically based on these new template parameter(s). --HappyDog 16:43, 24 July 2007 (UTC)

Okay, what is the type for? I've written Extension:BOINC Authentication. My next best guess is to use type 'interface'. Is that correct? --Eric Myers 12:25, 6 September 2007 (UTC)

My sense is that type identifies the technical method(s) of implementation - types are intended primarily as an aid to programmers who need help finding examples of extensions that use different kinds of entry points and programming techniques. Egfrank 07:27, 7 September 2007 (UTC)

So I changed the type to 'interface' and now the page seems to be categorized correctly by whatever system does that. I also explicitly added the category 'Authentication and Login', which seems to be the practice for most other auth extensions. --Eric Myers 14:58, 7 September 2007 (UTC)

And I made similar changes to the Shibbolith page. --Eric Myers 15:45, 7 September 2007 (UTC)

Multiple authors

How to add multiple authors without the "author" parameter's auto link screwing up and combining multiple authors into a single author? -Eep² 02:08, 30 July 2007 (UTC)

hmmm. I've just been comma separating them and I have not been using the username field. I suppose that may cause problems for any future categories such as extension by author. Perhaps we need to add an author2 author3 field? Bouncingmolar 05:19, 30 July 2007 (UTC)

Yea. I tried doing something like that for extension type, but also transcluding (whatever) template:extensiontype into the switch function but it doesn't seem to work, so I undid it. Check it out if you can make it work right. -Eep² 08:53, 11 August 2007 (UTC)

Template page revision

I've added the ability to handle up to 6 types in any order and updated the documentation accordingly. In the course of this enhancement I've also made the following changes:

• teased apart documentation and code: Documentation is now on a separate page: see Template:Extension/Doc. Hopefully this will make the code a bit easier to maintain as we go along.
  • This will also reduce the amount of material that has to be parsed when including a template and reduce the already small risk of a page with lots of transclusion being pushed over a pre-expand include limit.
• added a "nocats" mode to the template. This lets up include it as an example on documentation pages without accidentally adding the host page to various categories. I've also used it to remove redundant listings of an extension where the author wanted the Extension template on each of his/her subpages (c.f. Extension:Google Maps)
• added link to extension documentation when a type is unrecognized or deprecated
• deprecated the comma delimited forms
• fixed 3 bugs related to missing or empty attributes:
  • blank name fails to default to Extension/Archive 1: now it does
  • blank types do not add extension to the unknown type category: they now do
  • blank download does not default to no link: now it does

I've run this through several tests - mostly involving alternate types and combinations of blank values. If I've missed some combos and you see a problem that isn't obvious to fix, please let me know. Egfrank 12:08, 8 September 2007 (UTC)

Type taxonomy

Proposal

As I've been spending some time recently trying to clean up the long list of extensions with invalid or missing types, I've begun to feel that there is some inconsistency in our list of types.

1. I've been under the impression that "type" referred to an implementation strategy or pattern. This works well for database/db, extended syntax, hook, action, link, parser function, parser, special and variable. Each of these has a well defined set of techniques and even articles dedicated to those techniques. I'm happy with these and categorizing articles based on these has been a relatively quick and objective process.
2. Upon closer examination, there are other categories that seem to be purposes rather than patterns. I would group among these: category, data extraction, form, interface, list, media, namespace, and table. These don't work as implementation categories because most, if not all of them, have multiple implementation patterns: at least seven of note: (i) skins and skin modifications (ii) various page action and processing hooks (iii) scripts and templates that assist in the setting of configuration variables (iv) patches to the core mediawiki code (v) wiki markup extensions of various sorts (vi) custom subclasses (vii) use of a cluster of hooks associated with one of mediawiki's classes or subsystems
3. Even if we do want some element of purpose in our taxonomy, some types seem overbroad. For example, both skin related extensions and permissions related extensions end up in type "interface". However they serve very different purposes (work flow vs. look and feel) and are implemented using entirely different classes, hooks, and configuration variables. An article that explained how to write permissions extensions would give little insight in how to develop a skin.
4. If implementation is our focus, some important categories appear to be missing: bot toolkits and frameworks, and static maintenance/reporting scripts come to mind. These involve very different programming patterns than parser extensions, skin extensions, or anything else involving hooks. For one, they have the option of being run on a shut-down wiki and so don't have to be quite as careful about caching issues. These may be written specifically for use with MediaWiki but may be implemented in a variety of languages such as Perl, Python or Java.
5. hooks appears to suffer from diverse interpretations. On the talk page of Extension hook registry, there seems to be some feeling that the "hook" type should be limited to functions that define their own hooks. On the other hand, a lot of people have categorized their extensions as hook exensions merely because they use hooks (defined elsewhere).
   • There is a significant difference between programming to use a hook and programming to create one. It really does seem to me that these should be separate categories
   • Hook users as a category is too broad to really have any meaning. Virtually any extension (other than a maintenance script or bot) directly or indirectly uses some sort of hook somewhere.
6. the difference between database/db and data extraction doesn't seem to be well defined.
   • Almost anything that extracts data, will, by definition be a database extension. Do we mean database/db to be something that maintains the data? Adds new database tables? It is my feeling that something that changes the database is going to raise very different administrative concerns that something that maintains or extracts data from the database and so these should be categorized separately.
   • By database/db/data extraction do we mean strictly the data stored in an SQl/Postgress database? If so, what do we do about the many extensions that provide a way to allow multi-sourcing of article content: from the dbms, the file system, even remote sources?

I feel that there is a very definite and important need to know if an extension will do any SQL queries that can update the database rather than using the high level methods of article objects. I think that's really what an extension should be meaning by being of type "database". --Nad 03:52, 15 September 2007 (UTC)

I don't like to raise concerns without at least offering some ideas of a solution. My response to the above is as follows:

1. I do think it is helpful to have a categorization of extensions based on implementaiton techniques. Lots of people learn by example and this makes examples easy to find.
2. We now have an easy way to add multiple anythings (see type1...typeN and hook1...hookN, and Template:Foreach, so there is no reason we can't have both a purpose/usecase (usecase1...usecaseN) and type list for each extension.
3. Based on the above two points, I would recommend that we:
   • deprecate category, form, interface, list, media, namespace, and table as types. If we still want the convenience of a shorthand way of specifying those purposes, we add usecase1..usecaseN parameters to the templates and use these depreciated types as part of the value set to those parameters
   • Add the interface, system, and data types needed to produce the type hierarchy below. Each type should have both a corresponding category and article describing how that type of extension is implemented and documented in our extension registry (proposed new types in red).

• access - catchall for extensions that create, authenticate, grant or revoke permissions to users
  • user identity - extensions that create and delete users, and/or verify the identity of a user
  • user rights - extensions to the rights management system, e.g. changes to the way rights are assigned, apis, maintenance tools (does not include extensions that merely name rights needed to use the features of that extension).
• interface - catchall for uncategorized extensions involving end-user interaction (exclusive of access)
  • special - extensions that define one or more special pages, i.e. extensions that subclass SpecialPage or employ older techniques of hooking into it. Note: Some special pages seem to be intended for behind-the-scenes use. Is this true? If so, does this belong under system? under both system and interface?
  • skin - extensions adding css, js, or implementing hook functions to change the look and feel of mediawiki via the skins framework.
  • page action - extensions modifying page actions via implementation of one or more non-skin hooks. Page actions would include anything that implements the action (not the permissions) for the query parameter action, as well as dicussion and rating of articles.
  • mywiki - extensions that personalize mediawiki via one or more non-skin hook.
  • notify - extensions that email users, broadcast messages and provide other forms of community notification
  • locale - extension to mediawiki language/internationalization system via one or more non-skin hooks
• parser - catchall for uncategorized parser extensions
  • tag - custom XML tag markup
  • parser function - custom parameterized {{name: ... }} markup
  • variable - custom unparameterized {{NAME}} markup
  • link - customized [[...]] markup
  • extended syntax - miscellaneous other types of markup
• data - catchall for uncategorized back-end data extensions:
  • import - the back-end portion of extensions that upload various kinds of data, i.e. the filters and transformers, not the special pages and wiki markup that use them.
  • export - the back-end portion of extensions that export data from wikis in various formats.
  • include - the back-end portion of extensions that select and embed article content in non-special pages based on query parameters, e.g. Extension:DynamicPageList or Extension:LabeledSectionTransclusion and various rss extensions
  • database/dbdbschema - the back-end portion of extensions that add tables or columns to the database
  • source - extensions that support storage of articles and included content in alternate data sources - version control systems, file systems, GIS's
  • dbadmin/dbupdate - the back-end portion of tools for refreshing or recalculating derived data, fixing indexes, administrative activities, and any sort of direct updates to the database.
• system - catch all for uncategorized system extensions:
  • hook - extension that define one or more new hooks, i.e. they expand the systems customizability
  • bot - bots written for mediawiki
  • framework - api, library, or other toolkit targeted at MediaWiki extension developers
  • flavor/package - a bundled package of extensions meant to serve a philosophical approach to a wiki, e.g. Extension:SemanticMediaWiki or Extension:XmlWiki
  • stats - extensions that collect statistics about page or site usage or performance, e.g. Extension:FireStats
  • script - off-line administrative, data cleanup, and configuration scripts (does not include scripts dedicated solely to data or access)
  • patch - extension requiring changes to one or more MediaWiki files other than LocalSettings.php
  • host - integration with host - e.g. various patches to URLs, virtual host detection scripts, etc
  • wikia/admin - extensions for managing and maintaining a collection of wikis

Egfrank 00:44, 9 September 2007 (UTC) (revised Egfrank 09:08, 9 September 2007 (UTC))

Discussion

Hi. I haven't had a chance to read all of the above, but here are some points that spring to mind. Apologies if you've already covered them or if you already know this stuff - I'll be back to look at this in more detail soon (things are a bit busy for me at the moment...)

• You are right about the 'type' field being rubbish. It was intended to refer to implementation strategy as you suggest, but people who have not understood it have added other items to the list, and people who have understood it have not corrected (myself included). This is partly because there was ongoing discussion and a lot of general confusion too. See most of Category talk:Extensions for details.
• The point of categorising extensions via the template is to help people browsing through the category tree (predominantly). There is little point in over-categorising. That is why (for example) we removed the categorisations by author. If we don't want to add items to a category then free text is better than structured items.
• Your proposed categorisation scheme seems to highly specified at this point (as I say - based on quick glance).

In general, my thoughts are as follows:

• Remove 'type' altogether. Introduce a new parameter 'implementation' which will largely be a 1 to 1 mapping of the current 'type' parameter but a bit clearer about what it's for.
• Add a new parameter, 'subject' or 'function' or 'purpose' or 'feature' (all of these have been discussed and no consensus reached - the person who implements it therefore gets to choose - though my current preference is 'feature'). This should not be prescriptive. It should be a free-form field (possibly several fields, as only one item per entry) that allows for expansion. This will cover most of the values that you recommend removing.

That's my thoughts for now, but as I said I need to look at this in more detail when I get a bit more time. --HappyDog 00:27, 11 September 2007 (UTC)

Thanks so much for the feedback, especially seeing as you are busy. You seem pretty frustrated with the type parameter. In reference to your comments:

• Overlap between implementation type and purpose: No matter what we do there will be some overlap between the values in these two fields. Not every reason for use has multiple implementation strategies and not every implementation strategy has multiple reasons for use. None the less, they are still two questions, with two different answers, addressing two different perspectives (needs requirements vs. implementation). Technically, the overlap isn't really a problem since the template is setting up the categories. Worst case: [Category:XXX] gets added twice to the wiki text. The main point is: we get people to ask themselves the two questions and understand that they are two questions.
• Implementation type: many people learn best by example - a categorization by implementation type is essential for that learning strategy to work. Its current definition may be a mess, but it isn't IMHO "rubbish".
  • A better name? The idea of renaming the parameter to implementation is a good one: perhaps we should change the label. Changing the parameter name itself is a bit problematic. In MediaWiki global change is pretty much a human process and we have 200+ extensions using a parameter named "type" in their wiki code.
    • I think 'type' should be deprecated completely. However, we can do this gracefully. Initially, we add an 'implementation' parameter to the template, literally replacing the 'type' parameter. Then, we make the default value for 'implementation' be the otherwise unused 'type' parameter (e.g. {{{implementation|{{{type|}}}}}}) and then we add pages to Category:Extensions still using the deprecated 'type' parameter if the 'type' field is filled in. This way, all existing pages will continue to work as before, but will be flagged as needing work (and could be listed here). Once the cat is empty the template logic involving 'type', along with the cat, can be removed. --HappyDog 13:46, 14 September 2007 (UTC)
  • Category tree: I think the type field needs to function as more than a roadmap through the category tree. In fact, I'm not sure that's its purpose at all. People don't come to MediaWiki implicitly knowing its specific architecture (even when software architecture/development is their profession) and many people don't even have programming experience nor are they software architects - they just want to help by publishing their idea. We need to help them back by showing them how it fits into the larger whole. This is, I think, the real purpose of the field.
    • Sure - that's the purpose of the field, but the purpose of categorising on this field is partly to make information findable via the tree, and partly to find other extensions that use similar techniques. If we don't need to the categories (which I think we do) then it should just be free text. --HappyDog 13:46, 14 September 2007 (UTC)
  • Freeform: Because some implementation patterns are specific to MediaWiki, anything that purports to capture implementation patterns needs to have clear usage guidelines. A freeform field wouldn't accomplish that at all. A prescriptive type code functions essentially as a table of contents saying "here's what's out there". That's why each type needs to correspond (and be autolinked) to an article on that implementation pattern and we need to make sure that the template gives feedback when users use a non-standard type and links them quickly to help. Note: this feedback has already been implemented.
    • Agreed. 'implementation' should have a rigid definition (similar to 'status'). The suggestion was for the 'purpose'/'use'/'feature' field to be free-form, so if you set feature=Google it gets put in Category:Google extensions without first requiring that you lobby an admin to get 'google' added as a valid parameter value in the template. --HappyDog 13:46, 14 September 2007 (UTC)
  • Highly specified: The number of types is reflective of the complexity of MediaWiki - there are a lot of ways to customize this software. But I don't think it is overly specific. Each type corresponds to a distinct skill set and design pattern and really does need an article on its behalf discussing strategies and gotchas. A corresponding category is not unreasonable. The taxonomy is the end product of having gone through 200+ MediaWiki extensions and pondering their various implementation strategies (yes and even their source code).
• Purpose/Use case field: I like the idea of a purpose/use case field, but I'm not sure what it being free-form would buy us - the description already handles the need for totally free-form input.
  • I think a mix would be better - define some purposes that are linked to well established categories and leave the rest unlinked to a category (easy to do with a {{#switch ...}} parser function). This would also help keep down over categorization by privileging the more important ones.
  • As for the name of this fields parameters/labels, my own preference is "purpose" or "usecases". Its more likely to get people focused on the question of "why do I need this?" as opposed to "how does one do this?"
  • I don't think feature will accomplish that: We already have an idea of how people are going to percieve "feature" because several extensions include feature lists - it tends to be a mix of "we're easy to install", "we use non-invasive implementation strategies", a list of implementation strategies, and sometimes purpose. Egfrank 09:24, 11 September 2007 (UTC)

Gday, I read all of the above discussion. Your proposal and category tree seems logical and well thought out, I think it would help programmers by categorising the extension architecture. I'm not a programmer, so I'm sorry if i missed the point, but it does seem exteremely specific and besides being a lot of work to implement, Who would be qualified enough to look at each extension to determine what categories they fall under. would that mean reading the code to extract the methods the authors have used?

• Is the Purpose/Use case field, the one which categorizes the extensions by what they add to mediawiki? ie google extensions, editing extensions etc? I am very interested.. (or was) in making a category tree for the extensions to make the functions easily findable for people who maintain wikis and just want to add functionality. - Bouncingmolar 08:04, 13 September 2007 (UTC)

Thinking about the above - what is the point of the 'feature'/'usecase'/'subject'/'whatever' field? As far as I understand it, the point was to show the purpose of the extension in the infobox, with a link to a category containing other similar extensions. However, if we remove the need for having this in the infobox, then using standard category links will do the same thing. So maybe this field isn't needed at all? Removing it from the template and using cat links instead would certainly make everyone's lives a bit easier. Are we losing any (current, or potential future) functionality by doing this? --HappyDog 13:46, 14 September 2007 (UTC)

Been wondering that myself Egfrank 15:09, 14 September 2007 (UTC)

From Egfrank. BouncingMolar, nice to hear from you. You make a good point about usability. A taxonomy that no one can use isn't really much use. My sense is that the people who write extensions will know quite easily what type their code belongs in. If not, we'll see that pretty quickly - the number of untyped extensions will grow. As for the existing extensions, well we do have to look at the code ... sometimes. It depends on the quality of the documentation. There are some simple tell-tale signs that can help, and don't require great programming expertise to use. For example, an extension that says it adds database tables is going to belong to dbschema at the very least. Many of the implementation types correspond to certain families of Hooks - scanning the source code for the key values used with $wgHooks will tell you want hooks are used and in many cases, it will also pinpoint the hooks. When I was categorizing the categories without implementation type, I documented a lot (though not all) of these hooks. For certain of the extension types, putting them in the right category is little more than knowing what hook names go with what types. Egfrank 15:09, 14 September 2007 (UTC)

As for specificity. Its hard for any of us to know that apart from the extensions themselves. MediaWiki is complicated. Also what looks a lot in overview may not look so specific up close, especially for developers. For example, a person focused on parser extensions only has four types to choose from, not 20+. Someone working on extensions to the database only has one. Someone working on importing or exporting mediawiki content only has two (import/export).

Perhaps we should let the extensions themselves make the final decision. At present, "interface" as a general category has 200 or so extensions - way to many to make the category of much use for finding examples of how to implement X. Lets just categorize those using whatever types from the above taxonomy seem helpful. If we need them all great. If we don't that's fine too. Egfrank 15:09, 14 September 2007 (UTC)

I've always been a bit unclear about the type field, but would definitely use it properly if the meanings were made clear as outlined above. Maybe the info-box itself could have a link to the current options and their agreed upon meanings. --Nad 04:13, 15 September 2007 (UTC)

Consensus

This discussion had four participants: User:HappyDog, User:Bouncingmolar, User:Nad, and User:egfrank

After a week of discussion, it appears the following consensus exists:

1. The implementation type field as it stands is unclear. It would benefit from both a better label (User:HappyDog, User:egfrank) and better documentation (User:Nad,User:HappyDog, User:egfrank).
2. The implementation type field would benefit from a formal enforced taxonomy such as used with the status field. (User:HappyDog, User:egfrank).
3. There is concern about the degree of specificity of the taxonomy (User:HappyDog,User:Bouncingmolar) and some minor changes to/clarification of the taxonomy (User:Nad).
4. There has been one confirmation(User:HappyDog?) and no objections to the recommendation that types not in the proposed taxonomy be deprecated and their members be moved to more appropriate implementation types.
5. Use case/purpose can be handled using category links - there is no need for a separate field in the info box (User:HappyDog,User:egfrank).

Egfrank 07:02, 16 September 2007 (UTC)

Follow-up actions

Based on the above discussion, the following actions need to be taken:

1. revise template and documentation to reflect deprecated types
   • namespace, category, form, list, table deprecated as of 2007-09-21. Both code and documentation changed to reflect documentation. Where relevant, anything using one of those type code has been added explicitly to the appropriate category. For any remaining extensions using deprecated types, see Category:Extensions with deprecated types * add new types from the taxonomy as needed. Need determined by re-classification of existing extensions with deprecated types and/or membership in existing types with too much diversity/too many members (e.g. Category:User interface. Egfrank 06:28, 21 September 2007 (UTC)
   • media, search not deprecated, see below
2. improve documentation of non-deprecated types.
   • template updated so that field labels link to usage documentation, usage documentation improved 2007-09-16 through 2007-09-21. If anyone wants to check spelling/copy - please edit Template:Extension/Doc. Egfrank 06:28, 21 September 2007 (UTC)
3. add new types:
   • new access, parser, and interface types have been added to code and documentation; and extensions moved into those types where appropriate - complete as of 2007-09-20. Egfrank 06:47, 21 September 2007 (UTC)
4. reclassify extensions - see above

Egfrank 06:37, 16 September 2007 (UTC)

Addendums

After we began implementing the above conclusions, some developers responded with their edit or revert button. I've tried to follow up to see how these "action" votes might help us improve our understanding of an implementation taxonomy - Egfrank 03:43, 20 September 2007 (UTC)

Is media an implementataion type

Background note: User:Tim Starling reverted change of media to link on 2007-09-11. (see Extension:OggHandler).

Upon investigation of his source code it was clear we'd missed an implementation type: there is a clear framework for associating media file extensions with custom handlers. Media needs to be redefined so it can be used to identify extensions that use that framework. Egfrank 06:37, 21 September 2007 (UTC)

How is search a page action?

Background note: When the type of Extension:LuceneSearch was changed from search to page action, User:Rainman reverted it with the above comment. This is the follow up

I guess it isn't except in the broadest sense that it queries and operates on batches of pages (normally we think of a page action operating on a single page). You're right that that is pretty forced. I'm taking by your choice of "search" as a value that you feel it is a fundamental implementation type and not just a use case for the extension? Writing search engines is definitely a programming discipline unto itself and within MediaWiki there are specific hooks one needs to work with.

That being the case, it should remain part of the implementation taxonomy. On Template_talk:Extension we've been trying to sort out the distinction between the two (when there is one - which there isn't always). Your contributions would be most helpful. The point is to make this code set helpful to developers. Egfrank 10:29, 18 September 2007 (UTC)

From the taxonomy in Template_talk:Extension I think nearest match is special page, since LuceneSearch redefines the default mysql search on Special:Search. "Page action" is a bit misleading, because it implies that it's search within a page and not whole wiki. I guess that search is a core function of any wiki, and is different from other special pages, so there is some argument to single it out, especially if there are other implementations that would fall into this type... --Rainman 20:32, 18 September 2007 (UTC) - taken from my talk page.

Thanks for your thoughts - good documentation is impossible without a partnership between those who write the code and those who like to describe it.

• page action implies "within page" - hadn't thought about it that way, but I see your point.
• There are other extensions related to this core function, see Category:Search extensions.
• Implementation techniques differ widely. What I've seen so far:
  • page widgets using third party off-site search engines, e.g. Extension:Google
  • page widgets using local search daemons, e.g. Extension:Hyper Estraier
  • page widgets using default search engine, e.g. Extension:Inputbox
  • special page using local search daemons, e.g. your Extension:LuceneSearch
  • special page using custom SQL query, e.g. Extension:RigorousSearch
  • subclassing SpecialSearch.php and then replacing the default class via the SpecialPage_initList hook. No examples yet.
  • attaching functions to SpecialSearchNogomatch defined in SpecialSearch.php. No examples yet
  • configuring the SearchEngine.php by setting $wgSearchType to a custom class, e.g. Extension:Wildcard search.
  • patches to core code! Extension:Multi-select Namespace Search, Extension:GoogleSiteSearch
• Despite being a core function, documentation is poor: we don't even have a Manual:Search overview page or a Manual:Search extensions page to describe how to customize or extend it. On the other hand, because it is core, people probably look for help using that word.
• Even though the techniques vary widely, an extension writer still needs to make a choice among the techniques. Providing examples and documenting them as a single entity still has merit. Furthermore, back-end, any decent extension needs to consider some common questions: caching, indexing (and possibly intercepting saves to do it), and, most basically, the lovely MediaWiki version dependent multi-table join that is needed to connect a page title to its current text. Front-end, special page isn't unique to search and not all search extensions subclass special page.

So my vote would be: add it to the implementation type taxonomy in honor of it being a core function of a wiki but don't further subtype it based on details. If we had a hundreds of extensions for this core function (e.g. parser extensions) maybe we would need subtypes, but this isn't the case at present. Egfrank 09:05, 19 September 2007 (UTC)

I agree with your remarks, have just few comments. About Manual:Search - I think it's tricky writing overviews, because they tend to get out of date extremely fast (e.g. see m:Searching, a collection of random statements, and already fixed bugs). Instead, I guess that one would just add some basic remarks to Category:Search extensions, and leave to extensions to present their case. --Rainman 12:23, 19 September 2007 (UTC)

Updates?

Any updates on this discussion? I notice the documentation still has some comments about the taxonomy being unfinished. --Cneubauer 16:19, 7 February 2008 (UTC)

Template enhancement - license parameter

To accommodate some extensions that wish to publish their license (and are using the rights parameter to do so), I've added a license parameter Egfrank 14:12, 10 September 2007 (UTC)

Template enhancement - now up to 10 hooks used per extension

You can now add up to 10 hooks per extension.

Third party integration field

I think the template would benefit from a 3rd party integration field (integration1, integration2, integration3...).

• Being able to find extensions that integrate with X is of great importance to system administrators.
• The categorization of extension by integration is currently haphazard with some extensions adding themselves to Category:Integration, some adding themselves to categories named Category: ''Appname'' extensions, and some not categorized at all.
• While an integration field is no guarantee that people will add their extensions to integration categories, it does I think make it more likely:
  • Saliance: It puts the question up front and center: what (if anything) do you integrate with. This is more likely to encourage people to add this information.
  • Ease of use: Adding a parameter value to a template involves less typing and scrolling than typing out a category link. Since this is key information, I think making it as easy to add as possible is important.
  • Standardization: - because the category name is auto-generated by Template:Extension, we can insure that all 3rd party extension categories are named the same way. Possible naming conventions: Category:''Appname'' extensions, Category:''Appname'' integration extensions. The former seems to have arisen automatically (e.g. Category:Google extensions). The later is more precise. Any preferences out there?
  • Maintenance: - we can more easily monitor what 3rd party packages need categories for their integration extensions. This is a simple matter of using {{#ifexist:...}} to check whether or not a category exists for 3rd party package XXX. If not, we add the extension to a category for "extensions with undefined integration categories".

Egfrank 04:23, 16 September 2007 (UTC)

Suggestion withdrawn - I've just finished manually categorizing extensions by integration target (see Category:Extensions by integration target) - I don't think we would get good quality information in a template, and many software packages only have one extension that integrates with them. At present trying to automate this would add categories without clear benefit. Egfrank 06:52, 21 September 2007 (UTC)

Recent additions to Template:Extension

I'm quite confused about the recent additions to this template. I preferred the old version over the current one and I'm quite sure other people do too. Why?

1. The 'hook' field promotes instruction creep - people complain already enough about MediaWiki's documentation and they tell us that the docs suck, which seems to be true. This isn't making them not to suck.
2. Additions to the 'type' field are not neccessary - a lot of extensions, like Oversight do add table/tables to the database, but that certainly isn't the extension's main function - most likely the extension just adds a new special page or another new feature.
3. It clutters pages up. Aaron reverted this change to Extension:FlaggedRevs as it clutters up the page too much. I trust that the developers know what they're talking about.
4. It adds lots of useless categories, cluttering up not only the page, but the whole category structure of the wiki.

Please consider reverting these changes. Thank you. --Sayuri 14:02, 18 September 2007 (UTC)

I guess I agree with the above, at least with regards to the new hook category. I'm not sure how useful it is, and for some major extensions, there can be a LOT of hook use. Also not too fond of some of the newer 'type' categories, like "user activity". Aaron 16:43, 18 September 2007 (UTC)

Aaron - I wish you had been part of the discussion last week... your input was sorely needed. Egfrank 18:51, 18 September 2007 (UTC)

Sayuri (also from Egfrank 18:51, 18 September 2007 (UTC)), Thanks for expressing your concerns.

1. All additional fields on the template are optional and add nothing to the template if they are left blank. This was deliberate and followed a design pattern that has been in place for months. Nothing has changed in that respect. The minimal template, as always, looks like this:

   MediaWiki extensions manual

   MyExtension Release status: unknown
   License	No license specified
   Download	No link
   Translate the Extension/Archive 1 extension if it is available at translatewiki.net

   . So if you leave blank the fields that don't interest you, you have the old template back.




2. Instruction creep: If the hook field simply documented hooks for their own sake, I would definitely agree. However, documenting a hook used also adds the extension to a list of extensions that use that hook. Many people I've worked with need to learn by example - the abstract synopsis and brief discussion available in the hook documentation isn't really enough. They need to see the way others are using it. They need context. The main reason for encouraging people to document their hook use is to build up a treasury of examples that people can turn to when they want to write an extension but aren't sure of how to go about it. The template does just that.
3. Useless categories: It is not the number, but the quality of categories that creates clutter. Aaron is absolutely right about 20 hooks creating clutter. In his case, Aaron is doing a near complete overhaul on certain portions of MediaWiki's version management. The individual hooks used don't have much worth as examples because it is the overall effect created by those hooks that is important. In retrospect, I think he made the right decision removing the documentation. But most extensions aren't like Aaron's. They do one limited thing and do it well. And they are good examples of how to use certain hooks alone or in combination.
4. Additions to the type field are not necessary - its not the essence of the extension. For the record, database has been a legal value of the type field long before I got anywhere near this template. I am only responsible for assigning it to Extension:Oversight. If you feel there is a better value, go ahead. However, I hope you will consider these points:
   • The primarily purpose of that field is to capture the implementation technique, not the purpose of the extensions. Purposes are too diverse to capture in any kind of formal type set (see the above discussion). Documenting implementation strategies via the type code gives us the opportunity to automatically gather together examples of code employing various implementation strategies.
   • For Extension:Oversight, the purpose is managing data visibility. However, as stated in the first paragraph of the extension, the essential implementation technique is database related.
   • Over the years working as a manager of software projects, hands-on developer and a system administrator, I have found that what counts as key information generally depends on one's job responsibilities. For management, controlling visibility of information is the key issue. How its done is meaningless. But system administrators often see things differently. To them, an extension that modifies the database is an indicator of increased risk. MediaWiki does a great job of smoothing data migration issues between releases, but who knows about a random uncertified extension? An extension that changes the database needs to be evaluated differently than one that does not.

Egfrank 18:51, 18 September 2007 (UTC)

Overprinting

In firefox with javascript and images turned off, Extension:NukeDPL (for example) overprints words. (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.10) Gecko/20071115 Iceweasel/2.0.0.10 (Debian-2.0.0.10-1))

Please do

$ wget //www.mediawiki.org/wiki/Extension:NukeDPL > x.html; firefox x.html

to test. Jidanni 00:44, 28 November 2007 (UTC)

Adding a machine usable reference to the source of an extension

We suggest to add a structured reference to the source of an extension which can be used be used by automated and semiautomated installers. These ca be such things as:

• an svn link combined with the information that is is an svn link,
• a link to a page in the mediawiki wiki plus the info which sections need to go into which files, etc.

--Purodha Blissenbach 10:09, 29 December 2007 (UTC) on behalf of the 24C3 workshop

How to create this extension template for my personal wiki?

Hey could someone provide the know-how - step by step for creating this Template:Extension article?

I installed my wiki 2 weeks ago, and now I am trying to add this Template:Extensions article and I cannot manage to do it.

for example instead of showing me the nice short description table (chapter usage) it shows me just text ...something like this:

 MediaWiki Extension  [[Image:{{#ifeq: {{{status}}}|unstable|Crystal Clear app error.png|Crystal Clear action run.png}}|left|40px]] {{#if:|{{{name}}}|Extension}}

Release status: {{#switch: {{{status}}}|unstable|experimental|beta|stable={{{status}}}|#default=unknown}} {{#ifeq:nocats|nocats||[[Category:{{#switch: {{{status}}}|unstable|experimental|stable={{{status}}} extensions|beta=beta status extensions|unknown|=extensions with unknown status|#default=extensions with invalid status}}]]}}
[[Image:{{{image}}}|220px]]

}}

Make sure you have the ParserFunctions extension installed, as this template relies on it. --Skizzerz ^talk MediaWiki Support Team 03:50, 15 January 2008 (UTC)

Thanks man, I put the parser and everything works fine.

One more thing, do you have any idea why the infobox is always white, and doesn't change it's color according to the status?

You need this in your MediaWiki:Common.css :

.ext-infobox {
  border: 2px solid #aaaaaa;
  width: 272px; 
  float: right; 
  margin: 0 0 0.5em 0.5em; 
  border-collapse: collapse; 
  background-color: white;
}
 
.ext-infobox td {
  border: 2px none #aaaaaa;
  padding: 0.2em 0.5em;
  border-bottom: 1px solid #f0f0f0 !important;
}
 
.ext-header {
  background-color: #aaaaaa;
  color: white;
  text-align: left;
}
.ext-header td {
  padding-top: 0.5em;
}
 
.ext-header img {
  padding: 0 0.2em 0 0.5em;
}
 
.ext-status-unstable, .ext-status-unstable td {
  border-color: #990000;
}
.ext-status-unstable .ext-header {
  background-color: #990000;
  color: #ffff00;
}
 
.ext-status-experimental, .ext-status-experimental td {
  border-color: #CC6600;
}
.ext-status-experimental .ext-header {
  background-color: #CC6600;
}
 
.ext-status-beta, .ext-status-beta td {
  border-color: #000099;
}
.ext-status-beta .ext-header {
  background-color: #000099;
}
 
.ext-status-stable, .ext-status-stable td  {
  border-color: #009900;
}
.ext-status-stable .ext-header {
  background-color: #009900;
}

• iAlex 20:11, 15 January 2008 (UTC)

• Thanks man, it really works.

• Got one more issue. Because the pagename of the extensions are Extension:NameOfExtension, in the Category:All Extension they all appear under letter "E", is there any way to sort by NameOfExtension? How?

• I assume you mean on your wiki. Help:Category#Sort_key gives details of using sort keys. Sounds like you have not created a namespace Extension: that the articles reside in i.e. Extension:Foo is an entire article name, that is not made up in two parts [Namespace]:[Article name]. If you find this is the issue you will also have problems if you create a namespace, I recall you will have to move the articles temporarily to get the database to recognise the namespace component in the article name. --Zven 03:12, 17 January 2008 (UTC)

• Yes man, it's for my personal wiki... and you are right i didn't created the namespace, since I don't have so many pages I applied Manual:Using custom namespaces#Move conflicting pages. Thanks man!

WARNING: failed to fetch Extension:RawFile

Hello, I created a new extension page Extension:RawFile and edited the copy of the template in what I though a correct way but the robot of the Extension_Matrix said "WARNING: failed to fetch Extension:RawFile". Could someone have a look and tell me (or fix) what's wrong? Thanks! --Philippe Teuwen

deprecated extensions

I'd suggest to add another status besides expermintal, beta, stable, etc: deprecated. To be used for extensions that no longer work with current versions of mediawiki, or should no longer be used fro some other reason. any thoughts? -- Duesentrieb ⇌ 19:28, 14 August 2008 (UTC)

I second this. I would like to deprecate my memorize extension. I guess I'll change it to unstable, and add a warning banner for now...
--Ryan lane 14:33, 29 December 2009 (UTC)

PNG should be replaced with SVG

Please could someone replace Image:Crystal Clear action run.png with Image:Crystal Clear action run.svg? Thanks in advance. It Is Me Here 12:59, 16 August 2008 (UTC)

Why? There are many cases where a PNG image is vastly superior to SVG, and this is one of these cases. Since the image is being downsized to a specific size, scalability is not an issue. Besides, the PNG image's appearance looks a lot better than the SVG. Why should we downgrade the quality of the image? --Skizzerz 16:18, 16 August 2008 (UTC)

Strange, I thought that moving to SVG was always preferable apart from -mbox templates from what I remember. Anyway, I'd have said that the SVG looks nicer, but it's a matter of taste, I suppose. It Is Me Here 08:07, 17 August 2008 (UTC)

Especially with icons, hand-optimized raster versions often look better. It's always good to have an svg version, so different sized can be produced easily, though. With diagrams, matters are different.

For these particular icons, the SVG version renders considerably different from the PNG version - not sure which one is better over all, though the edges look a bit rough as rendered by rsvg. -- Duesentrieb ⇌ 11:11, 17 August 2008 (UTC)

Proposal: Collapsible sections

Manual on MediaWiki Extensions
List of MediaWiki Extensions

Wikilog Release status: beta
	Implementation	Template:Extension/TypeSwitchNoCats, Template:Extension/TypeSwitchNoCats
Description	Adds blogging features to MediaWiki, through a special namespace, making it a wiki-blog hybrid, like a Bliki.
	Author(s)	Julianotalk
	Last Version	0.6.0 (2008-09-21)
	MediaWiki	1.13+
License	GPLv2+
Download	svn: v0.6.0, trunk
	Parameters	$wgTaggingEntity $wgWikilogSummaryLimit $wgWikilogNumArticles $wgWikilogMaxAuthors $wgWikilogEnableTags $wgWikilogMaxTags $wgWikilogFeedClasses $wgWikilogFeedCategories $wgWikilogFeedRelated $wgWikilogNavTop $wgWikilogNavBottom $wgWikilogNamespaces
	Example	http://juliano.info/en/Blog:Memory_Leak
	Hooks used	ArticleFromTitle ArticleEditUpdatesDeleteFromRecentchanges ArticleDeleteComplete TitleMoveComplete GetLocalURL GetFullURL LanguageGetSpecialPageAliases LanguageGetMagic LoadExtensionSchemaUpdates LinksUpdate ParserFirstCallInit ParserClearState ParserBeforeInternalParse ParserAfterTidy

Like it was already complained a few times above, the current version of this template has a few issues, as illustrated here:

1. Box width: When the extension uses certain hooks, SkinTemplateBuildContentActionUrlsAfterSpecialPage and ArticleEditUpdatesDeleteFromRecentchanges , the box becomes too wide, taking too much horizontal space and making it hard to place it nicely in the extension page. Some extension authors have chosen to remove hook information from the template in order to avoid the annoyance.
2. Information overload: Some time ago, the box presented just enough information. Now, casual visitors to extension pages are presented a lot of information (i.e. noise) that have no relevance unless they are extension developers or MediaWiki hackers. This includes the parameters, added rights and the hooks themselves, as mentioned above.

I just tried to use this template on my new extension Wikilog, and these two issues bugged me. The ArticleEditUpdatesDeleteFromRecentchanges hook causes the box to have almost half of the horizontal screen space. Then I decided to modify the template in order to address these two issues.

To the right it the extension box as it is currently.

MediaWiki extensions manual - list

Wikilog Release status: beta
Implementation	Template:Extension/TypeSwitchNoCats, Template:Extension/TypeSwitchNoCats
Description	Adds blogging features to MediaWiki, through a special namespace, making it a wiki-blog hybrid, like a Bliki.
Author(s)	Julianotalk
Latest version	0.6.0 (2008-09-21)
MediaWiki	1.13+
License	GPLv2+
Download	svn: v0.6.0, trunk
Example	http://juliano.info/en/Blog:Memory_Leak
Parameters $wgTaggingEntity $wgWikilogSummaryLimit $wgWikilogNumArticles $wgWikilogMaxAuthors $wgWikilogEnableTags $wgWikilogMaxTags $wgWikilogFeedClasses $wgWikilogFeedCategories $wgWikilogFeedRelated $wgWikilogNavTop $wgWikilogNavBottom $wgWikilogNamespaces
Hooks used ArticleFromTitle ArticleEditUpdatesDeleteFromRecentchanges ArticleDeleteComplete TitleMoveComplete GetLocalURL GetFullURL LanguageGetSpecialPageAliases LanguageGetMagic LoadExtensionSchemaUpdates LinksUpdate ParserFirstCallInit ParserClearState ParserBeforeInternalParse ParserAfterTidy
[[translatewiki:Special:Translate/ext-|Translate the Extension/Archive 1 extension]] if possible

This is my proposed change. You may check User:Juliano/Template:Extension.

Parameters, Added rights and Hooks sections are hidden (collapsed) by default, and when shown, their contents stack vertically relative to the header, so that long hook and parameter names have less effect over the width of the box.

The collapsible sections are a good compromise allowing both simplicity and optional presentation of advanced information.

Note that it also fixes a bug in the current version that the first line of each of these sections are rendered differently than the others (compare the list of parameters in the current version and the new version).

If nobody have any restrictions regarding this new version, I would like to propose these changes.

--Juliano 06:11, 27 September 2008 (UTC)

Provided the boxes are open if the user doesn't have javascript enabled then the change seems sensible. It is important that the content doesn't become inaccessible if JS is disabled. Ideally the 'hide' link would also be hidden in this situation, as it would not be functional. --HappyDog 01:04, 1 October 2008 (UTC)

Sure. When JavaScript is disabled, the sections are expanded by default and there will be no 'show/hide' links, since it is the script itself that collapses the boxes and adds the 'show/hide' links after the page is rendered. In fact, if you are using Firefox (at least), you may have the opportunity to briefly see the sections expanded during a short time between the page is first rendered and the collapseTables() JS function is executed.

The tricks I used in this proposed change are the same used all over Wikipedia in w:Template:Navbox and others. They have been discussed a lot already, and its use is accepted in Wikipedia because it degrades correctly when JavaScript is disabled.

--Juliano 03:06, 1 October 2008 (UTC)

Cool! Gets my vote then! --HappyDog 18:00, 1 October 2008 (UTC)

More than one week has passed and there is one positive vote, besides mine. So, I'm doing the change. --Juliano 04:22, 5 October 2008 (UTC)

Compatibility

I have been doing some extension testing recently and have begun to create some compatibility charts for the latest supported MediaWiki versions (currently 1.12 and 1.13). See User:MinuteElectron/Testing for examples, and also see the blog. I think it would be nice to include this in the infobox as the table is now small enough to fit. Currently the table template is at Template:Extension Testing. What do you all think? MinuteElectron 12:10, 22 November 2008 (UTC)

Implemented this, feel free to adjust to make it look nicer. See Extension:Uniwiki CreatePage for an example. MinuteElectron 13:14, 22 November 2008 (UTC)

Excellent stuff. It is possible to add download links to the correct release version of extensions in the extension distributor in case a trunk version of the extension is not compatible? Siebrand 13:53, 22 November 2008 (UTC)

This is not currently possible as ExtensionDistributor insists on POST request to the actual download page, the furthest you can link to is to the version selection page. MinuteElectron 14:15, 22 November 2008 (UTC)

That's too bad. I created bugzilla:16425 for that. Siebrand 14:22, 22 November 2008 (UTC)

Check Usage

It has been changes to a different website. The other website takes time and is annoying. Whereas the new one is easy. Its basically a wiki. http://userdirectory.co.uk Sachein 16:45, 29 June 2009 (UTC)

I would like to know what is the purpose of linking to a different wiki for this. At least the previous site was an automated script, the new site is a blank wiki where we have to fill the information. Why not put in this very same wiki then? --Juliano 03:06, 30 June 2009 (UTC)