This page needs some attention.
About this board
The last revision of the lead section, while interesting, might be too much for such a brainstorming page. Leucosticte, I found your previous revision very helpful, but if you plan to add more it's probably better to create another page, which can start as an essay and maybe one day become policy. --Nemo 10:35, 20 November 2012 (UTC)
System administrator fatigue
Should we try to limit the number of extensions that are bundled with the core, and that therefore require the person installing MediaWiki to make a decision as to whether to check the box? If there are too many of those checkboxes, people will probably be inclined to either check all of them or leave them all unchecked, rather than thinking about each one. That might defeat part of the point of bundling rather than merging. Leucosticte (talk) 13:47, 26 November 2012 (UTC)
- Short answer: no. Longer answer: IMHO, it's probably better to group the checkboxes so that one can e.g. select "anti-spam extensions", or find some other way than silly checkboxes (false by default even?) to handle this; please file a bug against the installer. Nemo 13:57, 26 November 2012 (UTC)
- As of v1.20, no, we're not. Clicking the "help" icon reveals the text you see on the cyan background. For each box you check, it will add the corresponding require_once line to LocalSettings.php installing the extension. As of v1.21, the installer doesn't have any checkboxes asking you about extensions, and it doesn't add those require_once lines to LocalSettings.php. Leucosticte (talk) 03:01, 27 November 2012 (UTC)
- Filed as bugzilla:43817. --Nemo 10:48, 10 January 2013 (UTC)
Gathering popularity data
I was thinking that if get hold of the API URLs (obtained through, e.g., grabbing the RSD data you get when you hit the RecentChanges URLs available on each WikiIndex page that has a completed wikiindex:Template:Wiki) for a representative sample of the wikis out there, and then hit siprop=extensions, we could assemble a listing that would give us some idea of how widely used each extension is. Those numbers could be weighted by wikiFactor, so that for instance Wikipedia's using CategoryTree would carry more weight than, say, XS4ALL not using it. Any other thoughts on this? I'm assuming we wouldn't pay attention to Wikia wikis, by the way? Anyway, the benefit of this would be to help figure out what extensions are so popular that maybe they should be shipped with MW. Leucosticte (talk) 03:25, 27 November 2012 (UTC)
After , I've filed Bug 43815 – Some more extension to bundle with the 1.21 tarball/installer. --Nemo 10:39, 10 January 2013 (UTC)
Add remove extension
Hi please add a section for removing extension from core or remove the bundled extension please 184.108.40.206 13:01, 9 October 2013 (UTC)
I have wondered, since most large wikis including all wikimeda projects have these extensions installed, why not make them part of the core?
See also Bundling extensions. Note that keeping things modular as extensions isn't bad per se. I can imagine Renameuser might benefit from being completely integrated, whereas Checkuser seems perfectly fine as an extension (doesn't need to be entangled into core). If anything, Checkuser could be bundled, but I don't see a reason for making it a core feature. Only makes it harder to maintain and/or replace for third parties that don't want it.
Checkuser is a vital tool to help, for instance, the maintainer of a wiki (that is whoever techniccally owns it), search for duplicate accounts.
Except for the Wikis that explicitly allow multiple accounts for a single user due to privacy implications. Some even encourage it. Forcing the admin on that wiki to install something which would then need to be manually hacked out of the code is not a great idea.