Template talk:Extension/LQT Archive 1

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)

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
type = parser, hook, special puts it in "Category to catch extensions with an unrecognised type". It should be in all three extension categories. -- [[User:Skierpage|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 &lt;dump&gt; 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: . 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)

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 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 : 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 taxanomy
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, 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.
 * 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).
 * 6) * 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
 * 7) * 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.
 * 8) the difference between database/db and data extraction' doesn't seem to be well defined.
 * 9) * 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.
 * 10) * 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 don't like to raise concerns without at least offering some ideas of a solution. My response to the above is as follows: Egfrank 00:44, 9 September 2007 (UTC)
 * 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:
 * 4) * 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
 * 5) * Add the following implementation pattern types based on extension entry point (or lack thereof):
 * 6) ** patch - extension requiring core changes to one or more mediawiki version
 * 7) ** script - off-line maintenance or data extraction script
 * 8) ** bot - tool kit for bot creation
 * 9) ** framework - api, library, or other toolkit targeted at MediaWiki extension developers
 * 10) * Add the following implementation pattern types based on interaction:
 * 11) ** skin - extension adding css, js, or implementing hook functions to change the look and feel of mediawiki
 * 12) ** locale - extension to mediawiki language/internationalization system via one or more non-skin hooks
 * 13) ** page/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, as well as dicussion and rating of articles.
 * 14) ** user/user action - extensions that create, authenticate, grant or revoke permissions to users to perform various page actions
 * 15) ** personalize - extensions that personalize mediawiki via one or more non-skin hooks.
 * 16) ** stats - extensions that collect statistics about page or site usage or performance
 * 17) ** notify - extensions that email users, broadcast messages and provide other forms of community notification
 * 18) ** host - integration with host - e.g. various patches to URLs, virtual host detection scripts, etc
 * 19) * Add the following implementation pattern types based on role in content creation:
 * 20) ** import - extensions that upload information into a wiki
 * 21) ** export - extensions that extract data from a wiki in various formats.
 * 22) ** include - 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
 * 23) * define the hook type as meaning "new hooks" not "use hooks" (skin/action/import/export as well as the various parser types should cover uses)
 * 24) * define database type as meaning "modify the database structure" and/or enable sourcing of wiki pages from non-database sources (special/script/import/export types would already cover maintenance and reporting).
 * 25) * deprecate "data extraction" - it is covered by special/export/include/script each of which covers a different extraction technique