Last modified: 2013-01-28 22:35:02 UTC
Given that the new installer now has the option to enable extensions that are located in $IP/extensions, the ParserFunctions extension should come bundled with MediaWiki. This bug is not about including ParserFunctions in core. It is about including the ParserFunctions code in the extensions directory by default, which would allow the installer to enable it if the user chooses to do so. ParserFunctions has become nearly essential for a MediaWiki installation. Requiring end users to install the extension separately is a completely unnecessary hurdle.
Just trying to think if there is anything else that should go in the list... And make this bug slightly more generic. But you're right, and I believe Ryan Lane has said the same. Especially with the new installer going "oh, you seem to have extension X in your extensions directory, would you like me to install it?" like you say...
I do support the idea of bundling ParserFunctions in MediaWiki tarball.
Tim, or anyone else.. Do we have any sort of download stats from the ExtensionDistributors? Syntax highlighting is probably highly used. I wonder if it's even worth including some of the basic spam filters...? Recaptcha/ConfirmEdit and alike
+1 I have to install ParserFunctions on all installations I am in charge with. Most customers know Wikipedia and want to use templates in their wiki. And most Wikipedia templates make usage of PF.
No matter how much mistake was to introduce it in the first place, now PF is part of wikimarkup as most people know it, and pretending that it's an absolutely separate extension that average wiki doesn't need is stupid^H^H^H^H^H^H way too naive.
On the other hand, it would be quite nice to see someone actually code up a working, secure alternate to ParserFunctions (as opposed to just talking about it and deciding that all the previously-proposed languages are inadequate for one reason or another). Don't look at me to do it, my skills make script kiddies look good. =/
(In reply to comment #1) > Just trying to think if there is anything else that should go in the list... Syntax highlighting, CheckUser, Cite, and ConfirmEdit/SpamBlacklist come to mind, but I don't think any of them is as essential as ParserFunctions. Should the standard bundle be as slim as possible, or should it include all of the most common extensions? I agree that ParserFunctions should be bundled, in any event.
(In reply to comment #3) > Tim, or anyone else.. Do we have any sort of download stats from the > ExtensionDistributors? No, That is requested in https://bugzilla.wikimedia.org/show_bug.cgi?id=25844
Please restrict bug comments to ParserFunctions :-)
I support bundling ParserFunctions. What does this look like to the installing user, anyway? Are they offered the choice to install PF or not in a non-confusing way?
r98515
The installer in 1.17 lists the extensions found by name, but does not select any by default. There are checkboxes beside each one. I'd like to see SOME of those checkboxes on by default (like ParserFunctions), a description of the extension added (not just the name), and maybe allow us to specify two extensions as performing the same function but as alternatives (old wiki editor vs new wiki editor, but still as checkboxes so you can install more than one option). I guess that might be a seperate enh request ><
(In reply to comment #12) > I guess that might be a seperate enh request >< Yes.
(In reply to comment #12) > The installer in 1.17 lists the extensions found by name, but does not select > any by default. There are checkboxes beside each one. > > I'd like to see SOME of those checkboxes on by default (like > ParserFunctions) [...] I just filed Bug 44429 - "Please enable ParserFunctions by default".
