Which extensions should be installed by default by Meza?

[jamesmontalvo3]

Currently Meza installs a lot of extensions. Many people have asked to not have Meza force all the extensions on them. So the question is: what should be installed by default? There are three possibilities:

1. Install nothing
2. Install just a minimal base of extensions
3. Continue to install a suite of extensions

Personally I lean towards (2), where the minimal set includes Visual Editor and CirrusSearch since a lot of the effort of maintaining Meza is keeping those extensions up-to-date. We could also include those extensions "bundled" with MediaWiki, but not all of them are applicable in all contexts (SpamBlacklist, Nuke, Poem, etc are irrelevant in business intranet wikis).

I'm opening this issue to gather inputs. Please share your thoughts!

[jamesmontalvo3]

@darenwelsh @freephile @revansx @cicalese @hexmode @bryandamon

[bryandamon]

I'm in-between (1) & (2). If (1) was chosen, is it harder for that wiki to be redeployed with any extensions in the future (or specifically CirrusSearch/ElasticSearch and VisualEditor)?

[jamesmontalvo3]

I’m not sure if this answers your question, but I think if we went with (1) we’d have to make VE and CirrusSearch special cases where you choose to enable them or not, since you need to have something that tells Meza to install dependencies (Node.js, elasticsearch, java, etc)

[jamesmontalvo3]

Also, I think it’d be good for Meza to maintain a list of extensions that it does some basic tests for, and that are easy for users to enable the tested version. Tests could be as simple as “verify this special page loads without errors”

[freephile]

I like the idea of installing CirrusSearch, VisualEditor and all the extensions bundled with MediaWiki. By switching on git submodules, you get those via composer. However they still need configuration.

@revansx put together an inventory of extensions with ratings at https://www.mediawiki.org/wiki/Meza/ExtensionList

I put together a simple inventory of which extensions are provided by what in this spreadsheet

Aside: Google Sheets lets you grab any HTML table off the internet for manipulation in a spreadsheet. E.g. Rich's list

I'm also inclined to create a generous list of "LocalExtensions" that have perhaps been tested or at least configured "in a recommended way" to work with Meza.

[jamesmontalvo3]

I don’t think the fact that some extensions are “bundled” as submodules is something we should consider, for two reasons: (1) there are extensions in that list that enterprise/intranet users do not want and (2) when a MW release is older and the bundled version of the extension is out of date, a Meza user needs to get a change committed to MW core to update the extension, rather than a change to Meza (much easier) or a change to their own config (very easy). Additionally, from Meza’s perspective it doesn’t make sense to have most extensions installed one way, but have some other extensions installed another way.

[RheingoldRiver]

I'm pretty opposed to a mandatory SMW installation - this extension interferes with too many things when it's installed, and I'll never use it over Cargo. I also won't ever use VE, but I think that does make sense to include and is more easily ignored than SMW imo.

[jamesmontalvo3]

@RheingoldRiver thanks. I think I'm leaning towards "if any reasonable user would be opposed to an extension, do not require it unless it is prohibitively difficult to enable/disable it". So VE may fall in to that "prohibitively difficult" camp (at least until Parsoid is rolled into Core). CirrusSearch almost definitely falls into that camp, but what reasonable user doesn't want better search? 🙂

[revansx]

I think we should keep an eye on what "enterprise" means too.

I would ask that we update the above metric to, "... if any reasonable 'enterprise' user would be opposed'.." .. I think we need a vision and mission statement that recognizes the difference between an enterprise environment (saml, ldap, external data, data transfer, responsive design, approved revisions, graphs, Hexmode's ViewProtect, semantic results formats, batch uploads, the need for non-cached files/images, etc..) and a traditional non-wmf audience that functions very much like a WMF project, but simply isn't a WMF project.

[revansx]

imo Meza needs to emphasize what makes it's default deploy more attractive than SharePoint

[jamesmontalvo3]

Let's say for a minute that we make Meza able to install close to nothing (maybe requiring CirrusSearch, etc). I think we'd want to be able to do something like meza deploy <env> --with-bundles=enterprisemediawiki,smw,common,public-internet where:

• enterprisemediawiki = extensions from https://github.com/enterprisemediawiki
• smw = SemanticMediaWiki and related
• common = ParserFunctions, Interwiki, Cite...stuff that probably most people want
• public-internet = spam-management and other things you'd want on an internet-facing site

I'm not sure exactly on the implementation here--if putting it in deploy makes sense--but I think that if you're running deploy for the first time and you don't specify anything for with-bundles it give you some set of extensions. So maybe it defaults to common on that first run if nothing else is specified.

And you could do something like meza deploy <env> --with-bundles=none if you really wanted nothing.

[bryandamon]

@jamesmontalvo3

I think we'd want to be able to do something like meza deploy --with-bundles=enterprisemediawiki,smw,common,public-internet

After the comments @revansx made, I saw a lot of value in a curated "enterprise suite". Your response make perfect sense and seems to be a great balance.

[darenwelsh]

I think it makes sense to provide some kind of minimal install and then to allow for installation of bundles of extensions and individual extensions. I wonder if it is better to specify the config in some kind of config file vs the deploy command (something that is likely to be repeated). For example, what happens if you initially deploy with a bunch of extensions (and SMW) and then later deploy and omit one of these? Does it try to uninstall the extension? Does this cause you to lose data? I think it would be best if when you run meza deploy ... that even if you forget to include some argument like --with-bundles it should not be "destructive". You should have to make an act like removing content from a file to be "destructive" vs forgetting a command argument.

[darenwelsh]

It might also be worth providing the distinction between having an extension installed and having it "activated" (registered via LocalSettings.php). That might allow a wiki farm to install an extension to be available for all, but only active on a subset of wikis on that server.

[jamesmontalvo3]

better to specify the config in some kind of config file vs the deploy command

Yeah, probably. I was thinking of --with-bundles as additive, but putting it in config is probably better.

Thinking about this a little more, MezaCoreExtensions.yml (or something similarly named, or SomeBundle.yml) could still have content like is currently in Meza:

- name: VisualEditor
  repo: https://github.com/...
  version: tags/x.y.z
  config: |
    $wgSomeVar = 'xyz';

And then the user's MezaLocalExtensions.yml could have just this, if the user wanted VisualEditor:

- name: VisualEditor

This would use all of Meza's defaults. Or they could have this if they wanted to override the default version:

- name: VisualEditor
  version: master

And they could similarly override config and repo. If VE isn't in MezaLocalExtensions.yml, it doesn't get installed.

I think having something like this mitigates another potential issue of removing mandatory etensions from Meza: everyone on Meza version x.y.z being on a different version of SMW, and a different version of VE, and a different version of YourFavoriteExtension. If you're on Meza 35.1.3, you want the best version of Cargo that runs on Meza 35.1.3. On the one hand that means when a new version of Cargo comes out that you really care about, you want to be able to upgrade now by altering your own config without waiting for Meza maintainers to upgrade Meza. But on the other hand it also means that when you forget about checking for new versions of Cargo, the Meza community continues to add better versions of Cargo that you get for free without thinking about it.

One downside might be that this has the potential to really blow up the list of extensions+versions Meza "recommends", so I think we'd either (a) need to be careful and limit how long we let the list get, or (b) we'd need to have some automated testing associated with each extension. Maybe something like:

- name: AdminLinks
  repo: https://github.com/...
  version: tags/x.y.z
  config: |
    $wgSomeVar = 'xyz';
  tests:
    specialpages:
      - AdminLinks

This could be some really basic test that Special:AdminLinks loads without error, and perhaps checks the page for presence of notices, warnings and errors. We'd have to flesh out how to handle other cases (validating parser functions, running extensions unit tests if they have them, etc), and maybe it wouldn't make sense to store it all in the same YAML file.

[jamesmontalvo3]

It might also be worth providing the distinction between having an extension installed and having it "activated" (registered via LocalSettings.php). That might allow a wiki farm to install an extension to be available for all, but only active on a subset of wikis on that server.

That's possible now.

- name: AdminLinks
  repo: https://github.com/...
  version: tags/x.y.z
  wikis:
    - wiki4

This is installed on the server, but only activated for wiki4.

[jamesmontalvo3]

It’d be great to hear from more people. @hexmode @cicalese @akuckartz

[cicalese]

I support the idea of having a very minimal base set of extensions (possibly just VE and CirrusSearch) and then having profiles of suites of extensions that can be enabled. I also support the idea of differentiating between downloading and enabling extensions (avoiding the work install, because it has been used to mean either or both of those things). I agree with Daren's concern suggestion that the bundles be specified in a config file so that redeploying without flags won't be destructive. And, it should remain possible to selectively enable extensions on different wikis.

[hexmode]

Re: other services like js parsoid and ElasticSearch:

Using containers for these is a clear win. The services are easily be enabled or disabled as needed and all that needs configuring is, basically, telling MW how to communicate with them.

I'm leaning towards running the php engine and mysql in a container as well.

Containers address a lot of the complexity problem. RHEL's podman addresses a lot of security concerns with docker (i.e. it doesn't require root).

That addresses some of the extensions (VE, CirrusSearch, Math, etc) and thinking about whether or not they should be enabled.

Another effort to come up with a basic list of extensions, in a deploy-agnostic way, is at Sunflower.

[akuckartz]

Does there need to be a default set of extensions? (Maybe it is better if users are required to decide which set they would like to have installed?)

If yes: keep it small.

[jamesmontalvo3]

@akuckartz thanks for the input!

Does there need to be a default set of extensions?

I think for an experienced user/administrator the answer is "no". I think for new users considering MediaWiki it is good to provide them with a fully-featured experience.