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

edit

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)[reply]

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

  • 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)[reply]
  •   Oppose Per 86.23.109.101. * Pppery * it has begun 15:54, 17 August 2024 (UTC)[reply]
  •   Oppose per 86.23.109.101. Aeyeu (talk) 03:20, 20 April 2025 (UTC)[reply]
  • 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)[reply]
  •   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)[reply]

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.[reply]

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

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

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)[reply]

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)[reply]

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.

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)[reply]

  •   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)[reply]

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

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)[reply]

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

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

  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  •   Support --Krabina (talk) 08:53, 14 September 2021 (UTC)[reply]
  •   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)[reply]
  •   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)[reply]
  •   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)[reply]

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

Should be integrated in core

edit

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

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

  •   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)[reply]
  •   Oppose per 86.23.109.101 * Pppery * it has begun 15:57, 17 August 2024 (UTC)[reply]

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

  • 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 (talkcontribs) 21:49, 2 August 2008‎ (UTC)[reply]
    • 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)[reply]
  •   Support * Pppery * it has begun 15:57, 17 August 2024 (UTC)[reply]

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

WikiEditor (already bundled)

edit

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)[reply]

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)[reply]
  •   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)[reply]

Declined

edit

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)[reply]

  • 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)[reply]

Bundled

edit

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)[reply]

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 (talkcontribs) 12:40, 14 January 2023

  Bundled in MediaWiki 1.44, [1]

  Bundled in MediaWiki 1.44, [2]

  Bundled in MediaWiki 1.38, gerrit:751479

  Bundled in MediaWiki 1.21, gerrit:65649

  Bundled in MediaWiki 1.21, gerrit:65649

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

  • 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)[reply]
  • 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)[reply]
  •   Bundled r100366

  Bundled in MediaWiki 1.21, gerrit:65649

  Bundled in MediaWiki 1.21, gerrit:65649


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)[reply]

  • 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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]

  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)[reply]

  Bundled in MediaWiki 1.21, gerrit:65649

  Bundled in MediaWiki 1.34, gerrit:536690

  Bundled in MediaWiki 1.21, gerrit:65649

  Bundled in MediaWiki 1.21, gerrit:65649

  Bundled in MediaWiki 1.21, gerrit:65649

Done: Integrated in core

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

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

  • (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)

See also bug 22043 and bug 31951.   Bundled in MediaWiki 1.21, gerrit:65649

  In core MediaWiki 1.44, gerrit:998407

See also

edit