Suggestions for extensions to be integrated

Should be bundled with the installer

CategoryTree

• may be included as optional configuration variable [disablable]. —The preceding unsigned comment was added by an unknown user on a unknown date.
  • I wouldn't bother with this by default necessarily, though some people like it. The tree widget is rarely used directly, so it's not needed for content compatibility. --brion 21:17, 8 June 2011 (UTC)

Inputbox

• Inputbox needs a rewrite, it's a little scary. :) [disablable]. —The preceding unsigned comment was added by an unknown user on a unknown date.
  • Got a pretty decent rewrite recently ^demon 08:23, 27 December 2008 (UTC)
  • Some Wikipedia templates use this, but not generally in content areas. It's also got such a horrid config interface I wouldn't wish it on new users. ;) --brion 21:17, 8 June 2011 (UTC)

AntiSpoof

• AntiSpoof has no default rules installed and isn't an obvious thing to find, so is of limited use to just install by default. --brion 21:17, 8 June 2011 (UTC)

Assert Edit

• Belongs in the API somewhere? Or does it? Maybe the API obsoletes this, in which case we should leave it out (and force people to move to the API to get the benefits). —The preceding unsigned comment was added by an unknown user on a unknown date.
  • Yeah I guess this can be integrated into the API and just be killed out the main edit form. -- Bryan (talk|commons) 17:38, 22 August 2009 (UTC)
• Not convinced this is needed. --brion 21:17, 8 June 2011 (UTC)

BackAndForth

• [disabled by default]. —The preceding unsigned comment was added by an unknown user on a unknown date.

CheckUser

• should not. There are laws in some countries forbidding logging of IPs, etc. —The preceding unsigned comment was added by an unknown user on a unknown date.
  • So it should be disabled by default. Soxred93 00:35, 26 January 2009 (UTC)
  1. COPPA forbids collecting e-mail addresses in some circumstances that we don't accommodate (sites targeted at minors must ask for age and get parental approval if age < 13). And we don't provide any way at all for admins to comply with that. Since when does the law of one country force us to not add a feature for everyone else?
  2. What country actually forbids collecting IP addresses from being logged period? Some may require them to be discarded after a period, but CheckUser does that.
  3. We already log IPs in rc anyway.
  • So this is an entirely unreasonable reason. All bulletin boards I know of, for instance, have similar functionality enabled by default, and they don't even typically allow you to purge old IPs. —Simetrical (talk • contribs) 12:41, 26 January 2009 (UTC)

Cite

• still have some breakages and not properly handled by {{#if}} clauses. —The preceding unsigned comment was added by an unknown user on a unknown date.
  • Well, neither is <nowiki> or <pre> or any other XML-like tag, right? —Simetrical (talk • contribs) 12:36, 26 January 2009 (UTC)

Duplicator

• "copy" function available on most systems since the beginning of time. —The preceding unsigned comment was added by an unknown user on a unknown date.

ImageMap

• useful [disablable]. —The preceding unsigned comment was added by an unknown user on a unknown date.
  • With the ability to use |link= now, probably not needed in core (see also: r41727, r41789). —The preceding unsigned comment was added by an unknown user on a unknown date.

Tab0

• very simple usability helper. —The preceding unsigned comment was added by an unknown user on a unknown date.

Intersection

• [disablable] — a.k.a. DynamicPageList. —The preceding unsigned comment was added by an unknown user on a unknown date.

TitleKey

• Might want to merge this straight into the page table (as long as we get that easy schema upgrade ability on Wikimedia first...). —The preceding unsigned comment was added by an unknown user on a unknown date.
  • Integrating TitleKey would be beneficial to new mediawiki users. Its use case is confusing, because so much seems to work already without it, making it hard to see whether it is a legacy extension or not. What I mean: this adds substantially to the "learning curve" of installing a usable mediawiki installation. The main reason to not include it in core seems to be that it is a little bit of a hack for something (case-insensitive search and suggestions) that should work without the need to install another extension and a special table - correct? Can this then be fixed? G.Hagedorn 08:53, 30 October 2011 (UTC)

Validator

• Validator is a generic parameter handling tool. As a lot of parameter handling is happening in both core and extensions, it would greatly increase simplicity and consistency, as well as add a lot of useful things such as auto documentation generation. I'm quite sure most core devs will go "we don't need this". Try it, and then tell me it's not vastly better then hard-coding all the stuff over and over again for every use-case. --Jeroen De Dauw 03:29, 8 January 2011 (UTC)
• Since this is not currently used by core or production stuff, no reason to ship it just yet. To the extent that things in it are useful for other extensions, those things probably belong in core; doesn't make sense as its own extension. --brion 21:17, 8 June 2011 (UTC)

Should be merged in core

Extension:NoTitle

• how about putting Extension:NoTitle somewhere on here? Wikademia (copied from discussion page--Moejoe000 21:06, 18 May 2011 (UTC))
• Moved here. Is a very trival feature. Wikipedia uses a JaveScript workaround (for main pages). Removing just the Title in HTML seems really better. --Moejoe000 07:07, 10 June 2011 (UTC)
  • The way this extension does it isn't much cleaner, it inserts a <style> tag in the head section for scripts to declare display:none on the first heading. On the other hand, removing it may break bad scripts. Krinkle 15:39, 13 June 2011 (UTC)
    • I was suggesting to add the feature, not the particular implementation of the extension--Moejoe000 06:54, 14 June 2011 (UTC)

Configure

• every other web software system has had this since the beginning of time [disablable]. —The preceding unsigned comment was added by an unknown user on a unknown date.
  • The current Configure extension is too fragile IMO, based on editing config PHP files. I'd much rather see us work out a proper configuration database which can have a clean, safe UI written on top of it; supporting multiple wikis with cascading configuration options from global -> group -> individual site is a must. --brion 19:40, 19 August 2009 (UTC)

DismissableSiteNotice

• Was implemented, then reverted. Needs a rewrite to make it less hacky-ish before being merged back in [disablable]. —The preceding unsigned comment was added by an unknown user on a unknown date.
  • *nod* would prefer a cleaner implementation on this. --brion 19:42, 19 August 2009 (UTC)

Interwiki

• (at least the option to view available interwikis, see also InterwikiList) - merged in r45062, reverted in r45238 - "please continue working on it, it'd be a nice thing to have for third-party installations if the UI is cleaned up." (ref)
  • It has since been cleaned up quite a lot. I think it should be added to MW core. SPQRobin 20:38, 11 June 2011 (UTC)
  • I agree, it's a simple extension to view and modify interwikis without having to mess in the database and also keeps track of everything in a logging table. Since the interwiki table is populated by default it makes sense to have this in core. Krinkle 12:44, 4 July 2011 (UTC)
  • Still doesn't work for WMF wikis -- any implementation of this needs to work with $wgInterwikiCache. ^demon 17:16, 7 July 2011 (UTC)
  • Also, a lot of the complaints I see from the previous merge still exist in the extension: those need resolving. ^demon 17:18, 7 July 2011 (UTC)
  • I made it work with the interwiki cache, and cleaned up the code. Editing the data is disabled when the cache is used. Are there any other issues left? SPQRobin 16:18, 20 July 2011 (UTC)

See also bug 22043 and bug 31951.

Title Blacklist

• This is probably very useful to avoid a lot of junk on wikis with unexperienced sysops (for instance, Manual:Combating vandalism suggests it in bold). Should probably include some default blacklist for them or default to Meta's global blacklist (which is quite conservative). Nemo 11:09, 28 December 2011 (UTC)

SpamBlacklist

• Is this actually ready to be merged? See 4459 for a request to basically rewrite it. —The preceding unsigned comment was added by an unknown user on a unknown date.
• Same as above, but probably less useful unless some statistics prove that there are recurring spammed domains. Nemo 11:09, 28 December 2011 (UTC)

Poem

• no disadvantages —The preceding unsigned comment was added by an unknown user on a unknown date.
  • Merged in r41710, then reverted in r43520—The preceding unsigned comment was added by an unknown user on a unknown date.
  • Should probably be <nobreak> instead of <poem> (<nobr> is not an option because it is part of HTML)—The preceding unsigned comment was added by an unknown user on a unknown date.
• Should be merged and not bundled, as there are no disadvantages of merging. --Moejoe000 19:06, 25 July 2011 (UTC)

Should not be done

AntiBot

• zomg secret —The preceding unsigned comment was added by an unknown user on a unknown date.

BoardVote

• Wikimedia-specific —The preceding unsigned comment was added by an unknown user on a unknown date.

CentralAuth

• not includable—The preceding unsigned comment was added by an unknown user on a unknown date.

CrossNamespaceLinks

• even now it is useless—The preceding unsigned comment was added by an unknown user on a unknown date.

EasyTimeline

• while it is in Perl—The preceding unsigned comment was added by an unknown user on a unknown date.

ExpandTemplates

• doubtable usefulness for usual user—The preceding unsigned comment was added by an unknown user on a unknown date.
  • It can make finding bits of code that are buried within templates much easier. If improved, it could even create a tree of sorts. Perhaps this should be in the maybe category?—The preceding unsigned comment was added by an unknown user on a unknown date.

FixedImage

• Wikimedia-specific—The preceding unsigned comment was added by an unknown user on a unknown date.

OggHandler

• external dependency—The preceding unsigned comment was added by an unknown user on a unknown date.

Oversight

• to be deprecated by rev_deleted—The preceding unsigned comment was added by an unknown user on a unknown date.

SiteMatrix

• Wikimedia-specific—The preceding unsigned comment was added by an unknown user on a unknown date.

SyntaxHighlight GeSHi

• external dependency—The preceding unsigned comment was added by an unknown user on a unknown date.

TorBlock

• needs cron—The preceding unsigned comment was added by VasilievVV (talk • contribs) {{{2}}}

User Merge and Delete

• causes irreversible changes (deletes users)—The preceding unsigned comment was added by an unknown user on a unknown date.

Username Blacklist

• redundant to features in Title Blacklist—The preceding unsigned comment was added by an unknown user on a unknown date.

WikiHiero

• too heavy—The preceding unsigned comment was added by an unknown user on a unknown date.

Maintenance

• complete and utter hack, plus a security risk since a rogue admin could screw up the site with it.—The preceding unsigned comment was added by an unknown user on a unknown date.

CharInsert

• thought he was admin it was in core :). —The preceding unsigned comment was added by an unknown user on a unknown date.
  • How practical is this extension for core?. —The preceding unsigned comment was added by an unknown user on a unknown date.
    • Very, especially for all languages the use special characters, but also take a look at the average Wikimedia wiki's MediaWiki:Edittools. —The preceding unsigned comment was added by an unknown user on a unknown date.
    • CharInsert is going to be pretty much obsoleted by the new edit toolbar, which has a much cleaner system for special chars / edittools. --brion 19:42, 19 August 2009 (UTC)
  • I'm pretty sure the implementation of this could be improved dramatically. —Simetrical (talk • contribs) 12:42, 26 January 2009 (UTC)
    • Perfect is the ememy of good? Even though it has been adopted widely, it not being perfect would prevent it from being added to core, even though no one touched it since June 2006? (rev:14584)? siebrand 15:16, 26 January 2009 (UTC)
      • Yeah, sure. It could be cleaned up in core as well as anywhere. Just saying. —Simetrical (talk • contribs) 02:02, 27 January 2009 (UTC)
  • This extension should be obsoleted by WikiEditor. And anyway: the current version of this extension could be re-written completely in JavaScript (with the effect that users that do not have JavaScript enabled do not see unusable links) --Moejoe000 18:01, 8 May 2011 (UTC)
• Do not ship: provides nothing by default, and is obsoleted by WikiEditor with pre-populates its own special chars list. --brion 21:17, 8 June 2011 (UTC)

Bundled

ParserFunctions

• potential merge rejected by Tim Starling: difflink—The preceding unsigned comment was added by an unknown user on a unknown date.
• What's wrong with merging ParserFunctions into the core, perhaps with a configuration setting allowing it to be disabled? Tisane 15:41, 24 March 2010 (UTC) (copied from discussion page--Moejoe000 21:06, 18 May 2011 (UTC))
• bundled r98515

Vector

• Maybe one could try to merge those parts which only apply to the vector-skin with the skin itself--188.22.79.199 09:06, 30 April 2011 (UTC)
• Bundled in 101901

ConfirmEdit

• bundled r100366

WikiEditor

• See discussion: bugzilla:26914. —The preceding unsigned comment was added by an unknown user on a unknown date.
• Not shipping this by default is super lame. It should be shipped and enabled by default if possible. --brion 21:17, 8 June 2011 (UTC)
• Agree both, your comment and suggestion in bugzilla:26914 to have a clear interfece for various editors (which would imply "ship with installer" instead of "merge"? --Moejoe000 07:07, 10 June 2011 (UTC)
  • moved to "Bundle" See also bugzilla: 26918 and bugzilla:26914. Krinkle 15:41, 13 June 2011 (UTC)
• bundled r100366

Renameuser

• [Merge:] Yeah, that'd be good. —The preceding unsigned comment was added by an unknown user on a unknown date.
  • [Megre:] Maybe not necessarily the current version, though; see also: bugzilla:15212. —The preceding unsigned comment was added by an unknown user on a unknown date.
• Moved to bundle, as it was bundled currently --Moejoe000 07:50, 30 October 2011 (UTC)
• bundled r100366

Gadgets

• Gadgets are super-useful, but it's still a bit awkward to actually share gadgets from site to site. Might not hurt to slip it in for 1.18, but it'll be way more useful in future versions. --brion 21:20, 8 June 2011 (UTC)
• Sorry, I have to oppose here: (the current implementation of) this extension does not provide anything by default - one has to modify system texts to install gadgets. Persons who know how to do that, can also install the extension manually. If also configuration of Gadgets is easy, I would also suggest to bundle. --Moejoe000 09:46, 30 October 2011 (UTC)
• bundled r100366

Nuke

• installed on all Wikimedia wikis and is handy for non-Wikimedia users [disablable]. —The preceding unsigned comment was added by an unknown user on a unknown date.
  • Was implemented in r41630 but reverted in r42117. —The preceding unsigned comment was added by an unknown user on a unknown date.
• bundled r100366

Merged to core

DeletedContributions

• In core r41178

LinkSearch

• very useful
• In core r40830

Newuserlog

• disableable
• there should be ability to disable it for wikis like Wikia
• In core r40769

UniversalEditButton

• disablable
• In core r41916

See also

• Suggestions to split from core into extensions
• Possible tarballs
• Bundle ParserFunctions extension with MediaWiki