Suggestions for extensions to be integrated

An extension should be bundled with the installer after it has become extremely widely used. There are various schools of thought concerning other extensions. When deciding whether to integrate an extension into the core, one should consider the likelihood, if any, that extensions will be written that depend upon that functionality, and the prospects that it might be later desired to remove that functionality from the core, which would break those extensions. Extensions with uncommon external dependencies should generally not be bundled with the installer or integrated into the core.

While this page can be used for suggestions and discussion, actual work on bundling extensions in the installer happens on Phabricator, in T178349 and subtasks. For creating new tasks see /Checklist.

For more ideas see Category:Extensions used on Wikimedia, wikiapiary:Extension:Main Page, ...

Should be bundled with the installer

AntiSpoof

Tracked in Phabricator
Task T191736

• 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)
  • It is a prerequisite for Extension:AbuseFilter though. --Damian Yerrick (talk) 19:57, 5 December 2012 (UTC)
• Support integration to core. Rehman 06:14, 9 August 2020 (UTC)
• Support core or bundled. --鈴音雨 (talk) 23:44, 16 May 2024 (UTC)
• Support * Pppery * _{it has begun} 15:54, 17 August 2024 (UTC)

Chameleon

• Chameleon skin is a twitter boostrap based skin that can very easily be configured. Many third-party MW installations use it. Often mobile/desktop versions are not wanted, but a responsive design. Chameleon has a responsive design based on the popular Twitter bootstrap and is actively maintained. --Krabina (talk) 08:41, 14 September 2021 (UTC)
• Support It is one of the most popular skins --Jeroen De Dauw (talk) 10:55, 14 September 2021 (UTC)
• Support Agree. Would use this. - Lbillett (talk) 13:50, 14 September 2021 (UTC)
• Support --[[kgh]] (talk) 20:41, 14 September 2021 (UTC)
• Support: The most powerful and flexible skin out there. -- Cavila 18:44, 16 September 2021 (UTC)
• Support we use this skin essentially in all our wikis. Emwiemaikel (talk) 14:50, 18 September 2021 (UTC)
• Its not written down anywhere I can find, but I'm pretty sure bundled extensions all need to be hosted on gerrit, and this is hosted on github - Oppose as long as its on github --DannyS712 (talk) 17:16, 19 September 2021 (UTC)
• Support If you want your wikis to look like a modern website you have to use Chameleon. --Stefahn (talk) 20:30, 21 October 2021 (UTC)
• Support While I don't personally use it, everyone I have spoken to that uses Chameleon loves using it, they love the customisability, the reliability and quality that it provides, its quality is that of Vector, but it's bootstrapped. Aeyeu (talk) 03:20, 20 April 2025 (UTC)

CodeMirror

I think CodeMirror is an obvious candidate for bundling - it's a widely-used extension (including on most Wikimedia sites), and it works nicely with both VisualEditor and WikiEditor. The relatively new "Used by" template lets us see the popularity of extensions among different wiki farms and distributions, and as you can see, CodeMirror is used by 5 of the current 7 selections, - indicating that many people consider it an essential part of the MediaWiki experience. Yaron Koren (talk) 15:12, 21 July 2022 (UTC)

• Support integration to core Krabina (talk) 09:20, 13 January 2023 (UTC)

• Update - now it's 7 out of 14 for "Used by", which I think is still an impressively high number. Yaron Koren (talk) 13:34, 13 March 2023 (UTC)

  Support bundling or core. --鈴音雨 (talk) 13:14, 2 May 2024 (UTC)

• Support. Essential. Indispensible especially for writing templates using combinations of tags, parser functions, magic words and what not (for instance, it gives you a better clue about the position of your opening and closing braces, which can be incredibly hard to tell apart if everything has the same dark colour). Cavila 07:04, 9 August 2024 (UTC)
• Support * Pppery * _{it has begun} 15:54, 17 August 2024 (UTC)
• Template:Suppoprt CodeMirror has been around for a long time, it is basically a requirement for every wiki to have it, I don't know one wiki that doesn't use it, and even the it is so versatile, so helpful and as Cavila put it best, essential and indispensible for writing templates. Aeyeu (talk) 03:20, 20 April 2025 (UTC)

Disambiguator

• Ship in tarball, not merge, when Special:Disambiguations is removed from core. --Moejoe000 (talk) 10:58, 14 January 2013 (UTC)
• Core is better. --Nemo 12:13, 14 January 2013 (UTC)
• I originally implemented it in core, but was told it should be built as an extension instead. Personally, I thought it would make more sense in core, but I was under the impression that consensus was otherwise, per https://bugzilla.wikimedia.org/show_bug.cgi?id=35981. Let's discuss further in the bug. Kaldari (talk) 23:20, 15 January 2013 (UTC)
• I also think it makes more sense in core. Btw, some discussion has occurred on wikitech-l. --Waldir (talk) 15:52, 6 February 2013 (UTC)
• Moved to "bundle" section because the functionality was removed from core and this will obviously not be reverted any time soon. --Nemo 07:07, 10 September 2013 (UTC)

DynamicPageList

• [disablable] — a.k.a. DynamicPageList. — Preceding subst:unsigned comment added by VasilievVV (talk • contribs) 21:49, 2 August 2008‎ (UTC)
• A nice feature for sure, but may not be something that would be useful as a bundled extension. Probably useful for mid-to-larger wikis. Rehman 06:04, 9 August 2020 (UTC)
• Following the ruwikinews disruption in 2021 (phab:T287362), and especially considering phab:T287380, it seems likely that DPL won't be going anywhere unless it receives a pretty substantive rewrite. 「ディノ奴千？！」^{☎ Dinoguy1000} 15:53, 13 January 2023 (UTC)
• Oppose The extension is in need of a full rewrite, it has caused multiple full site outages, and deployment to further WMF sites is currently banned per Phab:T14423. 86.23.109.101 22:46, 25 January 2024 (UTC)

  But the extension is rewritten as DynamicPageList3, it's a fully rewritten version of DPL for newer versions. 190.190.134.118 20:35, 7 February 2024 (UTC)

• Support I'm going to disagree with 86.23.109.101 here - the extension has caused outages only because WMF wikis are so huge. Most wikis installing MediaWiki are never going to be large enough to cause problems so this remains a useful feature in that context. * Pppery * _{it has begun} 15:54, 17 August 2024 (UTC)

DynamicSidebar

Quite a useful feature to be bundled. Rehman 10:09, 9 August 2020 (UTC)

Echo

Tracked in Phabricator
Task T191738

• I think it would be ideal to include this extension to notify visitors and users alike of (temporary) important things.
• Support Although this is probobly worth integrating into core. MacFan4000 (talk) 23:19, 24 July 2017 (UTC)
• This is definitely an essential extension for every online mediawiki, community system without fast notice will be bad. --LazyKnight (talk) 18:33, 22 December 2017 (UTC)
• Support I strongly agree this is greatly needed. --Examknow (Lets Chat) 23:08, 4 March 2019 (UTC)
• Support this should definitely be integrated. --TheSandDoctor (talk) 15:55, 27 January 2020 (UTC)
• Support integration to core. Rehman 05:31, 9 August 2020 (UTC)
• Support --Krabina (talk) 08:56, 14 September 2021 (UTC)
• Support * Pppery * _{it has begun} 15:54, 17 August 2024 (UTC)
• Support This should be merged with core, rather than integrated. Aeyeu (talk) 03:20, 20 April 2025 (UTC)

FlaggedRevs

• With more and more gaming wiki's out there, I think this could be ideal for user pages, (for instance character pages) where someone else than the owner of the character might suggest a revision and the owner uses it or rejects it. For more CMS oriented wiki's this could also be very useful.
  • Support
• Oppose The top of Extension:FlaggedRevs contains the message Flagged Revisions is very clunky, complex and not recommended for production use, despite the "stable" tag. See phab:T185664. This extension has not been installed on any new WMF wikis since 2014. This is clearly not an extension that should be included in the default installer. 86.23.109.101 22:56, 25 January 2024 (UTC)
• Oppose Per 86.23.109.101. * Pppery * _{it has begun} 15:54, 17 August 2024 (UTC)
• Oppose per 86.23.109.101. Aeyeu (talk) 03:20, 20 April 2025 (UTC)

ApprovedRevs

• I would suggest ApprovedRevs as an alternative. It is much simpler to set up and use.
• Support integration to core --Krabina (talk) 09:21, 13 January 2023 (UTC)
• Support integration to core I feel like this extension shouldn't be merged with core, simply because the feature itself is only really suited for larger wikis that have the threat of mass vandalism, doesn't feel like a feature that needs to be available by default for every wiki, but integration with core should be added. Aeyeu (talk) 03:20, 20 April 2025 (UTC)

HitCounters

The Hit counters feature, removed from core. Requires the extension to be created first, see phabricator:T74420. --Nemo 21:15, 14 January 2015 (UTC) P.s.: The change is gerrit:221059. On the RfC, report and ML, I count 12 persons who wish to keep the feature and nobody but the 2 proposers who want to actively remove it.

• Agreed. We should integrate it. -- ☠MarkAHershberger☢(talk)☣ 18:58, 17 November 2016 (UTC)
• +1 Baxi69 (talk) 19:01, 17 November 2016 (UTC)
• +1 --Subfader (talk) 19:21, 17 November 2016 (UTC)
• Other interesting data: the extension is installed on 94 standalone wikis out of a total of 3116 wikis using 1.25+, i.e. 3 %. This percentage, projected to all the standalone wikis, would make this extension the 41st most popular. Considering the extension is very new and rather hard to install and that some wikis are probably stuck on 1.24 because of the lack of this feature in the tarball, this may easily be the most popular extension recently created. Nemo 19:55, 17 November 2016 (UTC)

Highly speculative. --2003:72:6D24:DB00:B57A:5017:F0BC:133A 16:21, 4 June 2017 (UTC)

• For larger wikis, this may not be helpful. However, this is very useful for smaller wikis who don't necessarily have caching, or more detailed analytics running. -- Prod (talk) 20:51, 18 November 2016 (UTC)
• +2 Every public wiki and nearly every private wiki I "control" wants to keep this feature. For a lot of them this was not even debatable. So great to have this extension and even better to have it integrated. --[[kgh]] (talk) 20:01, 19 November 2016 (UTC)
• +1 Platonides (talk) 19:34, 21 November 2016 (UTC)
• -2 In the meantime several MediaWiki versions, also LTS versions, have been released without this extension. The extension is hard to install, which if you ask me, makes it basically useless. In 1.28+ it cannot be installed at all. If installed after months or years without it, the numbers will all be incorrect anyway. Also there are way better solutions for visitor tracking so there is no need to further bloat the Core with this poor man's counter. If you really want to count page hits, a third party tool like Google Analytics or Piwik is way more useful. --2003:72:6D24:DB00:B57A:5017:F0BC:133A 16:18, 4 June 2017 (UTC)
• +1. Bennylin (talk) 22:40, 20 November 2017 (UTC)

MassMessage

Wikimedia uses it and it is very useful to me. 67.244.49.134 20:07, 18 December 2016 (UTC)

• I don't think that MM is that widely useful to be included in the tarball. Plus it requires a fully functioning job queue to be useful. Legoktm (talk) 01:52, 19 December 2016 (UTC)
• Support Many installs use it. MacFan4000 (talk) 23:19, 24 July 2017 (UTC)
• Support. Rehman 06:16, 9 August 2020 (UTC)
• Support * Pppery * _{it has begun} 15:54, 17 August 2024 (UTC)
• Support Whilst MassMessage requires the job queue being setup as Legoktm stated, core maintenance scripts need the job queue to function properly anyway. Aeyeu (talk) 03:20, 20 April 2025 (UTC)

MathJax

Mediawiki is very good instrument to arrange the mathematical results. Consider to include some MathJax; it seems to be best among various supports of the formula typing. Domitori (talk) 14:53, 6 April 2013 (UTC)

• Oppose Extension:Math is now bundled, so there is no point including this too. 86.23.109.101 00:18, 9 August 2024 (UTC)
• Oppose per 86.23.109.101 * Pppery * _{it has begun} 15:54, 17 August 2024 (UTC)
• Oppose per 86.23.109.101 Aeyeu (talk) 03:20, 20 April 2025 (UTC)

MobileFrontend

Tracked in Phabricator
Task T46852

Tracked in Phabricator
Task T191734

This will provide a Mediawiki frontend to mobile devices. The current frontend seems much too complicated to use there. --Kebap (talk) 12:58, 2 August 2013 (UTC)

YIKES! i've made a bootstrap skin for funtoo.org that takes nothing more than the skin, no extra extensions, works on phone tablet, and pc. bootstrap skin requires no separate m.subdomain.com addresses. all unified =) | funtoo skin screen shots it's designed to be very straight forward and very maintainable.

• Support MacFan4000 (talk) 23:19, 24 July 2017 (UTC)
• Support Integrating into core. Having a website that is properly usable on mobile devices is basic functionality these days. This should be a part of the core mediawiki software, rather than an extension. 86.23.109.101 14:50, 17 August 2024 (UTC)

Newest Pages

Very simple extension found on some wiki now. Not a critical feature perhaps, but it would make sense for this to be an option alongside $wgRCMaxAge and friends, with sane defaults. On a wiki with few dozens pages, showing new pages of the last 30 pages only doesn't make sense. On the other hand, someone may argue we should just raise the defaults for $wgRCMaxAge. --Nemo 08:41, 30 December 2014 (UTC)

• Support This extension will definitely help users in deciding what pages they could/should spend time expanding upon, of-course there may be edit conflicts that arise if the wiki is big and popular enough, but for smaller wikis this will definitely help encourage people to keep contributing and improving articles. Aeyeu (talk) 03:20, 20 April 2025 (UTC)

NewUserMessage

• Should be included in core : it helps to create a basic community by giving indications about the wiki and is very simple to configure. Already used in wikimedias wikis. --Jibec (talk) 20:05, 26 November 2012 (UTC)
• The Welcome Notification in Extension:Echo accomplishes a similar function. I would hold off on merging this with core until we have a clearer picture of what we're going to be doing for new users via Echo and Flow. Kaldari (talk) 23:43, 15 January 2013 (UTC)
• Do not merge (maybe to be bundled): this extension does a very particular thing. It may be interesting for public wikiks, but there are a lot of different approaches to achive effects (extension Echo as Kaldari mentioned, personal welcomes, using a bot, just use a welcome message after account creation,...). --Moejoe000 (talk) 10:03, 16 January 2013 (UTC)
• Neutral on this, I'm unsure though I like the extension and I think future possible broader solutions must not block improvements possible in the present. Moved to bundle section. --Nemo 07:07, 10 September 2013 (UTC)
• Neutral on bundling, but disagree with merging to core. Rehman 05:35, 9 August 2020 (UTC)
• Oppose both - adding a form-letter message to every user's talk page is unnecessary clutter in most cases. * Pppery * _{it has begun} 15:54, 17 August 2024 (UTC)

Popups

This feature would be useful in many use cases. Rehman 10:09, 9 August 2020 (UTC)

• Support since both extensions it is dependend on are already bundled, this is an obvious step --Krabina (talk) 08:54, 14 September 2021 (UTC)

  Support integration to core Krabina (talk) 09:22, 13 January 2023 (UTC)

• Support * Pppery * _{it has begun} 15:54, 17 August 2024 (UTC)
• Support Per what Krabina said, but I would like to see it merged with core, rather than just integrated. Aeyeu (talk) 03:20, 20 April 2025 (UTC)

StructuredDiscussions

Simpler discussion threads like StructuredDiscussions is a major feature for wikis. If this cannot be integrated in core, it should at least come as an easy-to-install option in the bundle. Rehman 10:09, 9 August 2020 (UTC)

• Oppose unmaintained, so many problems and bugs, not easy to revert, not a benefit to enable imo --DannyS712 (talk) 07:12, 11 December 2020 (UTC)
• Oppose development has been abandoned since 2015, buggy, unfinished, currently being removed from WMF sites. 86.23.109.101 00:20, 9 August 2024 (UTC)
• Oppose per 86.23.109.101. DiscussionTools already is bundled. * Pppery * _{it has begun} 15:54, 17 August 2024 (UTC)
• Oppose per 86.23.109.101 and Pppery. Aeyeu (talk) 03:20, 20 April 2025 (UTC)

TemplateSandbox

Can see how a template will really show up. Should be useful for lots of wikis. -- Prod (talk) 17:23, 20 April 2013 (UTC)

• Support MacFan4000 (talk) 23:19, 24 July 2017 (UTC)
• Neutral I believe most non-Wikimedia wikis may not find this that useful. Hence bundling with the installed may not be a good idea. Rehman 05:48, 9 August 2020 (UTC)
• Support * Pppery * _{it has begun} 15:54, 17 August 2024 (UTC)
• Support I believe this is definitely useful for people who like templating content easily. Aeyeu (talk) 03:20, 20 April 2025 (UTC)

Thanks

Tracked in Phabricator
Task T191739

Used by WMF. Very easy to use. 2002:43F4:3186:1234:716B:2BF2:8A30:F8DC 22:07, 29 January 2017 (UTC)

• Support Probobly worth integrating into core. MacFan4000 (talk) 23:19, 24 July 2017 (UTC)
• Support Probably worth integrating indeed. --TheSandDoctor (talk) 15:57, 27 January 2020 (UTC)
• Support integration to core. Rehman 05:35, 9 August 2020 (UTC)
• Support --Krabina (talk) 08:55, 14 September 2021 (UTC)
• Support * Pppery * _{it has begun} 15:54, 17 August 2024 (UTC)
• Support Good way of thanking users for good quality edits. Aeyeu (talk) 03:20, 20 April 2025 (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)
• Such a meta extension should only be included by default when and if it has wide usage in my opinion. Bawolff (talk) 17:46, 26 November 2012 (UTC)
• It's now the 18th most popular extension according to WikiApiary (excluding farm wikis), if that helps with the decision. --etesp (talk) 20:57, 13 July 2014 (UTC)
• Support --Krabina (talk) 08:53, 14 September 2021 (UTC)
• Oppose It makes no sense to bundle this unless the extensions that use it are bundled, and it's now been 13 years without this happening so it clearly isn't needed. * Pppery * _{it has begun} 15:54, 17 August 2024 (UTC)
• Oppose The extension page has just been updated to say that the extension is discontinued, and that no one should use it anymore. 86.23.109.101 20:54, 28 March 2025 (UTC)
• Oppose If this extension was still useful I would support it, but its developed is now discontinued, so therefore this should be declined. Aeyeu (talk) 03:20, 20 April 2025 (UTC)

Variables

• I've found this handy for making complex templates more efficient and readable. It's a fairly straightforward and popular extension which could benefit many wikis. --etesp (talk) 20:57, 13 July 2014 (UTC)
  • This one isn't compatible with the direction the parsing of pages is headed in, since literally its entire functionality relies on creating and using global page state. In addition, it's largely superseded by Scribunto/Lua - if you need to use this extension to implement some template, chances are good you'll have a much cleaner and lighter end result by implementing the functionality in a module instead. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 12:02, 9 April 2018 (UTC)
• Disagree with bundling, as it would most probably not be enabled for same reasons WMF did not enable. Alternatives to this function exist. Rehman 05:50, 9 August 2020 (UTC)
• Support. Without this extension my wiki would not be able to function. And no, Scribunto/Lua isn't a replacement, even if my host allowed me to install it (which it doesn't). Cavila 18:46, 16 September 2021 (UTC)
• Oppose per Dinoguy1000's first sentence * Pppery * _{it has begun} 15:54, 17 August 2024 (UTC)
• Oppose due to incompatibility with parsoid. 86.23.109.101 08:51, 31 March 2025 (UTC)
• Neutral Variables needs to be compatible with the future of parallelise parsing, I will support once that happens. Aeyeu (talk) 03:20, 20 April 2025 (UTC)

WikiLove

Used by WMF. Very easy to use. 2002:43F4:3186:1234:716B:2BF2:8A30:F8DC 22:07, 29 January 2017 (UTC)

• Support MacFan4000 (talk) 23:19, 24 July 2017 (UTC)
• Support Agreed. This would be a good thing to have --Examknow (Lets Chat) 23:09, 4 March 2019 (UTC)
• Support * Pppery * _{it has begun} 15:54, 17 August 2024 (UTC)
• Support It's a bit of a gimmicky feature, but I can see it being part of core, it can help reinforce the idea of always believing in good-faith edits and being positive.Aeyeu (talk) 03:20, 20 April 2025 (UTC)

Should be integrated in core

Tracked in Phabricator
Task T28751

AdvancedSearch

Very useful and user-friendly. Used by most/all WMF projects. Rehman 10:09, 9 August 2020 (UTC)

• Support --Krabina (talk) 08:52, 14 September 2021 (UTC)
• Oppose CirrusSearch (so Elasticsearch) is needed. --鈴音雨 (talk) 04:05, 19 April 2024 (UTC)
• Oppose Maybe merge with CirrusSearch but this doesn't make sense in core as it stands. * Pppery * _{it has begun} 15:57, 17 August 2024 (UTC)

CodeMirror

A very useful extension related to #WikiEditor. Rehman 10:09, 9 August 2020 (UTC)

• Oppose To me this seems like the kind of functionality that would be better suited to an extension, rather than as a part of mediawiki core - This is more of an enhancement than basic functionality. This also depends upon either the wikieditor or visualeditor extension, so integrating this would have the effect of making core mediawiki dependent upon an extension. 86.23.109.101 15:06, 17 August 2024 (UTC)
• Oppose per 86.23.109.101 * Pppery * _{it has begun} 15:57, 17 August 2024 (UTC)

DismissableSiteNotice

• Was implemented, then reverted. Needs a rewrite to make it less hacky-ish before being merged back in [disablable]. — Preceding subst:unsigned comment added by VasilievVV (talk • contribs) 21:49, 2 August 2008‎ (UTC)
  • *nod* would prefer a cleaner implementation on this. --brion 19:42, 19 August 2009 (UTC)
  • Support MacFan4000 (talk) 23:05, 24 July 2017 (UTC)
  • Support Sure, why not? Kizule (talk) 06:58, 11 December 2020 (UTC)

    Support integration to core Krabina (talk) 09:23, 13 January 2023 (UTC)

• Support * Pppery * _{it has begun} 15:57, 17 August 2024 (UTC)

LoginNotify

A useful extension which notifies you when someone logs into your account. Enabled by WMF wikis. Rehman 10:09, 9 August 2020 (UTC)

• Support A very simple and easy to use method of improving the security of a site. This is standard functionality provided by a lot of accounts and seems like something that should be included in core. 86.23.109.101 15:00, 17 August 2024 (UTC)
• Support This depends on Echo being merged into core to make sense, so is a really long way away, but otherwise seems fine. * Pppery * _{it has begun} 15:57, 17 August 2024 (UTC)

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)
• Oppose Don't see the use case here. * Pppery * _{it has begun} 15:57, 17 August 2024 (UTC)
• Oppose Can already be implemented using {{DISPLAYTITLE: in combination with $wgRestrictDisplayTitle. 86.23.109.101 09:06, 31 March 2025 (UTC)

TitleKey

Tracked in Phabricator
Task T38203

• Might want to merge this straight into the page table (as long as we get that easy schema upgrade ability on Wikimedia first...). — Preceding subst:unsigned comment added by VasilievVV (talk • contribs) 21:49, 2 August 2008‎ (UTC)
  • 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)
• Support * Pppery * _{it has begun} 15:57, 17 August 2024 (UTC)

UnusedRedirects

Tracked in Phabricator
Task T159062

Reasoning is the task. Kizule (talk) 23:02, 19 April 2025 (UTC)

• Support Kizule (talk) 23:02, 19 April 2025 (UTC)
• Oppose Sorry, I agree with Dinoguy1000 on the task. * Pppery * _{it has begun} 23:04, 19 April 2025 (UTC)
• Support We already have Special:BrokenRedirects and Special:DoubleRedirects, it only makes sense to have Special:UnusedRedirects merged with core. Aeyeu (talk) 03:20, 20 April 2025 (UTC)
• Oppose This special page makes no sense to me - a redirect isn't "unused" because it has no incoming links. On the English wikipedia, for example, there are masses of redirects from misspellings which should never be linked to but which receive a ton of pageviews from people misspelling things in the search bar. 86.23.109.101 18:02, 24 April 2025 (UTC)

WikiEditor (already bundled)

WikiEditor is already bundled, but would make more sense if it is part of the core (and doesn't require separate installation). Rehman 10:09, 9 August 2020 (UTC)

• Support integration to core --Krabina (talk) 06:25, 6 May 2024 (UTC)

I doubt very much that the legacy 2010 wikitext editor is going to be merged into core. (Or the 2017 one and the visual editor.) Jdforrester (WMF) (talk) 11:39, 9 May 2024 (UTC)

• Oppose From a software design perspective it seems much more elegant to implement all editors than extensions than to have one oddball editor that is part of core and all other editors being extensions. There's also no reason to suppose that every third party wiki would want to have this specific wikitext editor from 2010 available. 86.23.109.101 09:01, 31 March 2025 (UTC)

Declined

AntiBot

• zomg secret — Preceding subst:unsigned comment added by VasilievVV (talk • contribs) 21:49, 2 August 2008‎ (UTC)

BackAndForth

• [disabled by default]. — Preceding subst:unsigned comment added by VasilievVV (talk • contribs) 21:49, 2 August 2008‎ (UTC)
• Archived extension. 「ディノ奴千？！」^{☎ Dinoguy1000} 23:25, 17 July 2019 (UTC)

BoardVote

• Wikimedia-specific — Preceding subst:unsigned comment added by VasilievVV (talk • contribs) 21:49, 2 August 2008‎ (UTC)

CentralAuth

• not includable— Preceding subst:unsigned comment added by VasilievVV (talk • contribs) 21:49, 2 August 2008‎ (UTC)

CharInsert

• thought he was admin it was in core :). — Preceding subst:unsigned comment added by VasilievVV (talk • contribs) 21:49, 2 August 2008‎ (UTC)
  • How practical is this extension for core?. — Preceding subst:unsigned comment added by VasilievVV (talk • contribs) 21:49, 2 August 2008‎ (UTC)
    • Very, especially for all languages the use special characters, but also take a look at the average Wikimedia wiki's MediaWiki:Edittools. — Preceding subst:unsigned comment added by VasilievVV (talk • contribs) 21:49, 2 August 2008‎ (UTC)
    • 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)

Configure

• every other web software system has had this since the beginning of time [disablable]. — Preceding subst:unsigned comment added by VasilievVV (talk • contribs) 21:49, 2 August 2008‎ (UTC)
  • 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)
• Oppose Not really needed. MacFan4000 (talk) 23:19, 24 July 2017 (UTC)
• Archived extension. 「ディノ奴千？！」^{☎ Dinoguy1000} 23:25, 17 July 2019 (UTC)

CrossNamespaceLinks

• even now it is useless— Preceding subst:unsigned comment added by VasilievVV (talk • contribs) 21:49, 2 August 2008‎ (UTC)

EasyTimeline

• while it is in Perl— Preceding subst:unsigned comment added by VasilievVV (talk • contribs) 21:49, 2 August 2008‎ (UTC)

FixedImage

• Wikimedia-specific— Preceding subst:unsigned comment added by VasilievVV (talk • contribs) 21:49, 2 August 2008‎ (UTC)

Maintenance

• complete and utter hack, plus a security risk since a rogue admin could screw up the site with it.— Preceding subst:unsigned comment added by VasilievVV (talk • contribs) 21:49, 2 August 2008‎ (UTC)

OggHandler

• external dependency— Preceding subst:unsigned comment added by VasilievVV (talk • contribs) 21:49, 2 August 2008‎ (UTC)

Oversight

• to be deprecated by rev_deleted— Preceding subst:unsigned comment added by VasilievVV (talk • contribs) 21:49, 2 August 2008‎ (UTC)

Short URL

It seems to me, that everybody prefers short URL rather than the long one. I think, the short URL should be default. Domitori (talk) 14:53, 6 April 2013 (UTC)

• So you mean the apache configuration, not the extension (which is an URL shortener). Makes sense, but it's not what this page is for and I've no idea how can be addressed. Maybe a bug against the installer? --Nemo 00:27, 7 April 2013 (UTC)
  • Discarded, this is not an extension. Please file an enhancement for the Installer. If we want this, it is something our installation wizard might be able to do. Krinkle (talk) 04:38, 1 October 2013 (UTC)

SiteMatrix

• Wikimedia-specific— Preceding subst:unsigned comment added by VasilievVV (talk • contribs) 21:49, 2 August 2008‎ (UTC)

Tab0

• very simple usability helper. — Preceding subst:unsigned comment added by VasilievVV (talk • contribs) 21:49, 2 August 2008‎ (UTC)
• Should be dealt with at bugzilla:156 instead. --Nemo 22:13, 26 May 2013 (UTC)
• Archived extension. 「ディノ奴千？！」^{☎ Dinoguy1000} 23:05, 14 September 2019 (UTC)

TorBlock

• needs cron— Preceding unsigned comment added by VasilievVV (talk • contribs)

User Merge and Delete

• causes irreversible changes (deletes users)— Preceding subst:unsigned comment added by VasilievVV (talk • contribs) 21:49, 2 August 2008‎ (UTC)

Username Blacklist

• redundant to features in TitleBlacklist— Preceding subst:unsigned comment added by VasilievVV (talk • contribs) 21:49, 2 August 2008‎ (UTC)

WikiHiero

• too heavy— Preceding subst:unsigned comment added by VasilievVV (talk • contribs) 21:49, 2 August 2008‎ (UTC)

Duplicator

• "copy" function available on most systems since the beginning of time. — Preceding subst:unsigned comment added by VasilievVV (talk • contribs) 21:49, 2 August 2008‎ (UTC)
• Oppose bundling this due to the fact that it is not a common need. Rehman 06:05, 9 August 2020 (UTC)
  • N Not done unmaintained. MacFan4000 (talk) 17:47, 11 November 2020 (UTC)

FancyBoxThumbs

• Extremely useful for any wiki. Bennylin (talk) 17:48, 14 January 2014 (UTC)
• Don't bundle, as it is no longer maintained. Rehman 06:00, 9 August 2020 (UTC)
  • N Not done unmaintained. MacFan4000 (talk) 17:47, 11 November 2020 (UTC)

Bundled

TemplateStyles

Tracked in Phabricator
Task T327006

Necessary for any wiki that wants to copy templates from Wikipedia and many other WMF wikis (and increasingly, from third-party wikis as well). 「ディノ奴千？！」^{☎ Dinoguy1000} 15:46, 13 January 2023 (UTC)

Yes, I think this is important too. It's widely used, and the second most downloaded extension. I added as https://phabricator.wikimedia.org/T327006 — Preceding unsigned comment added by Bugreporter (talk • contribs) 12:40, 14 January 2023

• Support * Pppery * _{it has begun} 15:54, 17 August 2024 (UTC)
• Support Widely used, required by many templates. 86.23.109.101 08:52, 31 March 2025 (UTC)
• Support TemplateStyles feels like a basic feature we've been missing for all this time, it really needs to be merged with core as long as Extension:TemplateStylesExtender is also merged alongside it. Aeyeu (talk) 03:20, 20 April 2025 (UTC)

Bundled in MediaWiki 1.44, [1]

CheckUser

Tracked in Phabricator
Task T317147

• should not. There are laws in some countries forbidding logging of IPs, etc. — Preceding subst:unsigned comment added by VasilievVV (talk • contribs) 21:49, 2 August 2008‎ (UTC)
  • 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)
• I agree with Simetrical. It's an out of the box feature available to staff on most comparable software, if anything MW's implementation is extremely conservative and has a lot more oversight. Missing this after coming from forums and other places is kind of jaring. --etesp (talk) 20:57, 13 July 2014 (UTC)
• Support MacFan4000 (talk) 23:19, 24 July 2017 (UTC)
• See also phab:T37653 (closed in 2012, but no major discussion) and Talk:Suggestions for extensions to be integrated#Why are Renameuser and Checkuser not core features (brief discussion in 2013). Quiddity (WMF) (talk) 21:20, 17 July 2019 (UTC)
• Support bundling, per above. Rehman 06:10, 9 August 2020 (UTC)
• Support * Pppery * _{it has begun} 15:54, 17 August 2024 (UTC)
• Support I agree with all the points above, especially with Simetrical's and MacFan4000's points. Aeyeu (talk) 03:20, 20 April 2025 (UTC)

Bundled in MediaWiki 1.44, [2]

AbuseFilter

Tracked in Phabricator
Task T191740

• This is an immensely helpful tool for preventing spam-edits and should be available to everyone creating a new wiki. It needs Extension:AntiSpoof.--Baumgeist (talk) 17:49, 29 May 2013 (UTC)
• Any more opinions? --Nemo 07:07, 10 September 2013 (UTC)
• Support MacFan4000 (talk) 23:19, 24 July 2017 (UTC)
• Support seems helpful to include by default. --TheSandDoctor (talk) 15:54, 27 January 2020 (UTC)
• Support. Rehman 06:15, 9 August 2020 (UTC)

Bundled in MediaWiki 1.38, gerrit:751479

CategoryTree

Tracked in Phabricator
Task T191735

• may be included as optional configuration variable [disablable]. — Preceding subst:unsigned comment added by VasilievVV (talk • contribs) 21:49, 2 August 2008‎ (UTC)
  • 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)
  • It's pretty useful. E.g., compare how easy it is to browse documents in this Category listing compared to this CategoryTree listing. The latter is much more navigable, because you can see the full filenames. I also think CategoryTree has reached a degree of popularity sufficient to justify its inclusion in the core; the wikisphere seems to have settled on it as a standard. Leucosticte (talk) 03:11, 27 November 2012 (UTC)

Bundled in MediaWiki 1.21, gerrit:65649

• N Not done Was not bundled with 1.21. I moved it back here because it might still be added to the bundle in the future. The Anonymouse [talk] 05:29, 14 June 2014 (UTC)
• This is by some way the most popular non-bundled extension, and is in my opinion a fairly significant improvement over normal category navigation. --etesp (talk) 20:57, 13 July 2014 (UTC)

Cite

• still have some breakages and not properly handled by {{#if}} clauses. — Preceding subst:unsigned comment added by VasilievVV (talk • contribs) 21:49, 2 August 2008‎ (UTC)
  • Well, neither is <nowiki> or <pre> or any other XML-like tag, right? —Simetrical (talk • contribs) 12:36, 26 January 2009 (UTC)
• I agree this should be included by default. Bawolff (talk) 17:46, 26 November 2012 (UTC)
• This seems logical to me - even for third-party wikis. --Varnent (talk) 00:45, 5 January 2013 (UTC)

Bundled in MediaWiki 1.21, gerrit:65649

CodeEditor

Tracked in Phabricator
Task T191742

Used by WMF. Very useful. 2002:43F4:3186:1234:716B:2BF2:8A30:F8DC 22:07, 29 January 2017 (UTC)

• Support MacFan4000 (talk) 23:19, 24 July 2017 (UTC)

ConfirmEdit

• 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

ImageMap

• useful [disablable]. — Preceding subst:unsigned comment added by VasilievVV (talk • contribs) 21:49, 2 August 2008‎ (UTC)
  • With the ability to use |link= now, probably not needed in core (see also: r41727, r41789). — Preceding subst:unsigned comment added by VasilievVV (talk • contribs) 21:49, 2 August 2008‎ (UTC)
  • Agreed. Bawolff (talk) 17:46, 26 November 2012 (UTC)

Bundled in MediaWiki 1.21, gerrit:65649

Inputbox

• Inputbox needs a rewrite, it's a little scary. :) [disablable]. — Preceding subst:unsigned comment added by VasilievVV (talk • contribs) 21:49, 2 August 2008‎ (UTC)
  • 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)

Bundled in MediaWiki 1.21, gerrit:65649

LocalisationUpdate

It's about time we start supporting localisation well in all MediaWiki installations. As far as I know, LU has already been updated to use will soon work (thanks to gerrit:34496, while WMF used a custom hack) with gerrit/git reliably enough; the problem would be that as is it needs cron (like #TorBlock which was discarded). If we had this, we could also use some special system messages, or qqq messages, to spread crucial information or docs (see also bugzilla:41578). --Nemo 21:28, 10 November 2012 (UTC)

• I'm somewhat doubtful this is really needed for proper localization support. We ship the localizations with MediaWiki. Well it is certainly nice for WMF wikis to have up to the minute localization updates, I don't see why it is critical for up to the moment updates of the localizations in general. Bawolff (talk)

  Have you considered that most wikis are not updated for months or years and that sometimes not even 1.x.y releases include localisation updates? WMF wikis are those which need LU less now, thanks to the bi-weekly update. Could you please elaborate on why updated localisation is not so useful in your opinion? I don't know where to start replying. Thanks, Nemo 17:55, 26 November 2012 (UTC)

  I don't see the need for bundling LocalisationUpdate. I think it would be much better to find a way to encourage updating the whole MediaWiki installation of outdated wikis rather than focusing on updating their localisations. If we offer LocalisationUpdate *from now on*, that won't have any effect for wikis that are already using older versions at this moment anyway. And non-WMF wikis are usually in major languages that are already very well localised. SPQRobin (talk) 19:31, 8 January 2013 (UTC)

  Do you have any stat for the last claim? About updating, by default security updates don't necessarily include localisation updates. Updating MediaWiki is not a solution to have an up to date localisation, unless one uses git of course. We should go towards a usable experience for tarball users. Nemo 19:44, 8 January 2013 (UTC)

  No, I don't, but it's quite logical (see also sites using MediaWiki). Or, the other way around, look at translatewiki:Translating:MediaWiki/statistics/1.20: I don't think there are many non-WMF wikis at all in languages with less than 80-90% localised. About updating, I'm not really talking about security updates, I'm also talking about wikis using versions like 1.15, 1.16 etc, I think it would be better to focus on wikis upgrading more regularly rather than solely keeping their localisations up to date. SPQRobin (talk) 18:55, 14 January 2013 (UTC)

  You should use this list and extract language info from there, not rely on assumptions. "Why don't you focus on X instead" is not a valid argument, anyway it's also wrong here because in these days I am working on contacting those thousands of wikis which need to upgrade.

  I'd rather like to hear reasons why bundling LU would do harm or not do good. --Nemo 20:01, 14 January 2013 (UTC)

  I just give my opinion, I said "I think it would be better to focus on...". And please, even from the linked list it is, imho, quite obvious that when you take away all English, German, Italian, Spanish, ... wikis you will have only few wikis left in "rare" languages. SPQRobin (talk) 00:14, 16 January 2013 (UTC)

  Why don't security updates include localization updates? I think they should. The fact that many wikis don't update actually makes me like the idea of including this extension a bit more. A separate conversation from if we want to bundle this is how we would make it work. It needs cron, and I'm opposed to bundling any extension that cannot be automatically set up via the web installer. Bawolff (talk) 23:15, 17 January 2013 (UTC)

  Can you file a bug with a proposal on how to make the installer set such things up? It was needed for TorBlock too. In the case of LU, running the script once in a while is still a valid use case. Security releases usually include localisation updates, but it depends on Siebrand being notified in advance and having enough time for it the days before. --Nemo 09:05, 18 January 2013 (UTC)

Bundled in MediaWiki 1.21, gerrit:65649

This was later removed from the bundle and archived. * Pppery * _{it has begun} 15:59, 17 August 2024 (UTC)

Nuke

• installed on all Wikimedia wikis and is handy for non-Wikimedia users [disablable]. — Preceding subst:unsigned comment added by VasilievVV (talk • contribs) 21:49, 2 August 2008‎ (UTC)
  • Was implemented in r41630 but reverted in r42117. — Preceding subst:unsigned comment added by VasilievVV (talk • contribs) 21:49, 2 August 2008‎ (UTC)
• Bundled r100366

ParserFunctions

• Bug 26261
• potential merge rejected by Tim Starling: difflink— Preceding subst:unsigned comment added by VasilievVV (talk • contribs) 21:49, 2 August 2008‎ (UTC)
• 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))
  • I second that, please merge it with mediawiki core. --85.253.84.143 12:54, 9 November 2014 (UTC)
• Bundled r98515

Poem

• no disadvantages — Preceding subst:unsigned comment added by VasilievVV (talk • contribs) 21:49, 2 August 2008‎ (UTC)
  • Merged in r41710, then reverted in r43520— Preceding subst:unsigned comment added by VasilievVV (talk • contribs) 21:49, 2 August 2008‎ (UTC)
  • Should probably be <nobreak> instead of <poem> (<nobr> is not an option because it is part of HTML)— Preceding subst:unsigned comment added by VasilievVV (talk • contribs) 21:49, 2 August 2008‎ (UTC)
    • I disagree. The tag does a lot more than preserve line breaks. See Extension:Poem. We should keep the <poem> tag, IMO. Kaldari (talk) 23:40, 15 January 2013 (UTC)
• Should be merged and not bundled, as there are no disadvantages of merging. --Moejoe000 19:06, 25 July 2011 (UTC)
  • I concur. It's useful enough by default with no discernable disadvantages, and merging it would be a good idea. I wouldn't mind it being bundled with the installer, but merging would be as good an idea if not better. Arcane21 (talk) 13:43, 26 November 2012 (UTC)

Bundled in MediaWiki 1.21, gerrit:65649

Renameuser

• [Merge:] Yeah, that'd be good. — Preceding subst:unsigned comment added by VasilievVV (talk • contribs) 21:49, 2 August 2008‎ (UTC)
  • [Merge:] Maybe not necessarily the current version, though; see also: bugzilla:15212. — Preceding subst:unsigned comment added by VasilievVV (talk • contribs) 21:49, 2 August 2008‎ (UTC)
• Moved to bundle, as it was bundled currently --Moejoe000 07:50, 30 October 2011 (UTC)
• See also Merge RenameUser into core.--Qgil (talk) 19:15, 5 March 2013 (UTC)
• Bundled r100366

  This was later merged outright into core. * Pppery * _{it has begun} 15:59, 17 August 2024 (UTC)

Scribunto

Tracked in Phabricator
Task T191737

• A lot of users import templates and modules from Wikipedia into their wikis, and this is necessary for most of them to work. Jackmcbarn (talk) 04:31, 7 September 2014 (UTC)

  +1 Legoktm (talk) 04:32, 7 September 2014 (UTC)

  This is a complex extension, and it will cause a number of issues for shared hosts. Platonides (talk) 19:39, 21 November 2016 (UTC)

• Support MacFan4000 (talk) 23:19, 24 July 2017 (UTC)

Bundled in MediaWiki 1.34, gerrit:536690

SpamBlacklist

• Is this actually ready to be merged? See 4459 for a request to basically rewrite it. — Preceding subst:unsigned comment added by VasilievVV (talk • contribs) 21:49, 2 August 2008‎ (UTC)
• Same as above, but probably less useful unless some statistics prove that there are recurring spammed domains. Nemo 11:09, 28 December 2011 (UTC)
  • Does anyone doubt that there are recurring spammed domains? We could just compare the blacklists of various sites for recurrence. Ciaran (talk) 14:35, 9 April 2013 (UTC)

Bundled in MediaWiki 1.21, gerrit:65649

SyntaxHighlight GeSHi

• external dependency— Preceding subst:unsigned comment added by VasilievVV (talk • contribs) 21:49, 2 August 2008‎ (UTC)

  What external dependency? I think this should be bundled with or merged into the core. It helps a lot with collaboration involving code, and a lot of wikis have adopted it. Leucosticte (talk) 00:21, 11 November 2012 (UTC)

Bundled in MediaWiki 1.21, gerrit:65649

TitleBlacklist

• 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)
• Given the prevalence of spam on wikis these days - this seems valuable to me. --Varnent (talk) 00:47, 5 January 2013 (UTC)

Bundled in MediaWiki 1.21, gerrit:65649

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

VisualEditor

• Given that this is becoming the default on Wikipedia, this should be included in the installer.--Simoneau (talk) 20:33, 17 September 2013 (UTC)

  Right now, VisualEditor is still in a beta state and not really fit for bundling for novice sysadmins (it's more than a little complex to get going compared to normal extensions that we bundle - most especially, the dependency on Parsoid, a nodeJS service). Perhaps early-ish next year it will be in a better state for this to be appropriate. Jdforrester (WMF) (talk) 06:15, 21 September 2013 (UTC)

• Almost six years on, and VE is still in beta with a highly involved install process (though it might be simplified once Parsoid lands in core? not sure). Suggesting this for declined, at least for now. 「ディノ奴千？！」^{☎ Dinoguy1000} 01:53, 14 September 2019 (UTC)
• Support integration to core. Per the extension page, this comes bundled from 1.35+. Rehman 05:41, 9 August 2020 (UTC)
• Done

WikiEditor

• See discussion: bugzilla:26914. — Preceding subst:unsigned comment added by VasilievVV (talk • contribs) 21:49, 2 August 2008‎ (UTC)
• 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

Done: Integrated in core

AssertEdit

• 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). — Preceding subst:unsigned comment added by VasilievVV (talk • contribs) 21:49, 2 August 2008‎ (UTC)
  • 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)
• In core, see gerrit:90263. The Anonymouse [talk] 05:19, 14 June 2014 (UTC)

DeletedContributions

• In core r41178

ExpandTemplates

• doubtable usefulness for usual user
  • 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?
• In core, see bugzilla:28264 and gerrit:96810. This, that and the other (talk) 07:11, 30 November 2013 (UTC)

LinkSearch

• very useful
• In core r40830

Newuserlog

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

PostEdit

• Per bug 48276. --Ori.livneh (talk) 20:57, 30 May 2013 (UTC)

SimpleAntiSpam

Very silly and harmless, seems to work for some. --Nemo 19:02, 26 May 2013 (UTC)

• Any more opinions please?
• Seconded and bundled with gerrit:88483. Should maybe put in queue for integration too? --Nemo 15:56, 9 October 2013 (UTC)
• In core, see bugzilla:52063 and gerrit:90291. This, that and the other (talk) 07:11, 30 November 2013 (UTC)

UniversalEditButton

• disablable
• In core r41916

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. Bundled in MediaWiki 1.21, gerrit:65649

In core MediaWiki 1.44, gerrit:998407

See also

• Bundled extensions
• Suggestions to split from core into extensions
• Possible tarballs
• Bug 26751 “Extensions that should really be core functionality (tracking)”
• wikiapiary:Extension:Main Page/Merged and Bundled