Talk:Suggestions for extensions to be integrated

Jump to navigation Jump to search

About this board

Rubric?

It would be great if this page linked to an explanation of why an extension would be integrated into core, and criteria that are used to make the decision. Adamw (talk) 18:46, 12 September 2012 (UTC)

Lead

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)

Side note... are we bothering to include the description of the extension near the checkbox? Daniel Friesen (Dantman) (talk) 14:21, 26 November 2012 (UTC)

MediaWiki 1.20 installer.
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)
Actually I was mistaken; because I didn't download the tarball, I didn't see the checkboxes. As Nemo writes on IRC, "if it's not the actual tarball and it doesn't ship the extensions, the installer won't ask about them". Leucosticte (talk) 22:24, 14 November 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)

1.21

After , I've filed Bug 43815 – Some more extension to bundle with the 1.21 tarball/installer. --Nemo 10:39, 10 January 2013 (UTC)

And Mark mentioned some more. --Nemo 20:42, 14 January 2013 (UTC)

Add remove extension

Hi please add a section for removing extension from core or remove the bundled extension please 90.212.81.76 13:01, 9 October 2013 (UTC)

That's Suggestions to split from core into extensions. --Nemo 15:47, 9 October 2013 (UTC)


67.244.49.134 (talkcontribs)

This page needs some attention.

Reply to "This page"
Myrtonos (talkcontribs)

I have wondered, since most large wikis including all wikimeda projects have these extensions installed, why not make them part of the core?

He7d3r (talkcontribs)
Krinkle (talkcontribs)

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.

Myrtonos (talkcontribs)

Checkuser is a vital tool to help, for instance, the maintainer of a wiki (that is whoever techniccally owns it), search for duplicate accounts.

109.188.127.85 (talkcontribs)

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.

Reply to "Why are Renameuser and Checkuser not core features"
There are no older topics