Jump to content

Extension management 2018 feedback

From mediawiki.org

One of MediaWiki's greatest strengths is the diverse extension ecosystem. But navigating that ecosystem and managing those extensions can be difficult and cumbersome. The goal of this RfC is to solicit requirements and feature requests for what people want MediaWiki's extension management system to do. Unless otherwise stated, the term extension applies to skins as well for simplicity.

To keep things organized, we'll split the discussion into four categories: finding extensions, installing extensions, upgrading extensions, and other for anything that doesn't fit into the first three.

For each suggestion you have, use the input box to create a new section, outlining your feature request:

  • Focus on the functionality you desire, rather than the specific implementation. For example, Be able to programatically enable/disable extensions from the command line is better than Have a bash script that can enable/disable extensions.
  • Mention any relevant details about your MediaWiki installation if it is pertinent to your request (e.g. installed on a shared host/a containerized cloud provider)
  • If there are any relevant wiki pages, Phabricator tickets, mailing list discussions, etc., please link them as well.

Underneath each proposal will be a section for endorsements (and any brief comments) and another for longer comments. The goal will be to collate the input provided here, and use it to plan future development work on improving extension management.

Finding

[edit]
Current documentation to find extensions: Manual:Extensions#Browsing extensions

Extensions that have passed a security review should be searchable

[edit]

I typically browse through mediawiki.org to find extensions to install. I'd like to be able to narrow my search results to extensions that have passed a security review. Legoktm (talk) 06:04, 16 May 2018 (UTC)[reply]

Endorsements

[edit]

Comments

[edit]
  • From the discussion we had during the Barcelona Hackathon:
    • "Security reviewed" is only one of the attributes that should be available. There could be any number of other "tags" that should be available for filtering, e.g. user ratings, test coverage, keywords from extension.json, etc.
    • "Security reviewed" in particular raises a number of questions that -to quote - "lead down a rabbit hole": Who is allowed to add the tag, how is it proven (link to a report on trusted source?), is a signed package of the reviewed extension provided?
    • It is understood that some of these imply "stretch goals", which would be projects of their own and certainly are not needed in a first version

--F.trott (talk) 19:28, 19 May 2018 (UTC)[reply]

Central catalogue of extensions

[edit]

There should be a central catalogue of extensions that is accessible via an API. This would allow people to build tools that enable automatic installation.

In addition to extension name and description, it should include the download location and method, including tarballs, git (Gerrit, Github, etc.), composer (from packagist).

It should be possible for other organisations to curate their own catalogues, and any usage of the catalogue in MediaWiki should be configurable. F.trott (talk) 08:12, 17 May 2018 (UTC)[reply]

Endorsements

[edit]

Comments

[edit]
  • Are you're asking for is something similar to the ExtensionDistributor API? But that it would automatically download and install it? Legoktm (talk) 17:33, 18 May 2018 (UTC)[reply]
    • Not really. I don't need a service to download stuff. I'd just like a catalogue that an external tool (e.g. an Extension Manager) could access. Also ExtensionDistributor has several shortcomings: It only supports one source (gerrit), it only supports git dumps, it requires from extensions to maintain versions per MW REL branch. (As far as I remember, which may be outdated. It's off topic, but if there is an easy approach to teach ExtensionDistributor to do any of the following I would be happy for links: load versions according to semver; load something else than git-dumps from gerrit; at least run build scripts before tar-balling.)
  • If we're talking about remote installation, there should be signing scheme, that allows to ensure the extension code is genuine. Of course if it is loaded from git then signed tag may be enough, provided that there's a list of authorized signers with public keys somewhere. Smalyshev (WMF) (talk) 00:06, 24 May 2018 (UTC)[reply]
  • I think we should use Wikidata for this. We have heaps of properties over there and then it would also make sense to use the data. Currently all extensions are also tracked at Wikidata but I dunno for what reason. --[[kgh]] (talk) 14:02, 20 June 2018 (UTC)[reply]

Supported MediaWiki versions should be listed

[edit]

MediaWiki knows at least two kinds of release versions that receive bugfixes and security patches: "Current Stable" and "Current LTS". An extension should specify which version of MediaWiki is actively supported. If I have a MW 1.31 I need to know which version of an extension should be used to benefit from bugfixes and security patches. Osnard (talk) 15:07, 19 May 2018 (UTC)[reply]

Endorsements

[edit]

Comments

[edit]

Extension quality metadata should be collected/searchable

[edit]

When searching for an appropriate extension to solve a problem, a variety of metadata would be useful:

  • Has the extension passed a security review?
  • Has the extension passed (unit, integration, acceptance . . .) tests?
  • Is the extension actively maintained?
  • Who is the maintainer of the extension?
  • What MediaWiki versions does the extension work with?
  • What extensions depend upon this extension?
  • What extensions extend the functionality of this extension?
  • What extensions is this extension incompatible with?
  • How many wikis are known to use this extension?
  • User reviews/ratings

This will need to be done per extension version. Ideally, extension versions would be signed. Ideally, as much of this information as possible would be machine-generated rather than reported by the extension owner.

Based upon the information above, it may be useful to categorize extensions in some way: fully supported with a seal of approval, partially supported, etc. Cindy.cicalese (talk) 20:42, 3 June 2018 (UTC)[reply]

Endorsements

[edit]

Comments

[edit]

Generate mediawiki.org extension infobox information automatically from extension.json

[edit]
Tracked in Phabricator
Task T209084

This may be rendered unnecessary by an extension catalog. But, it might still be useful depending upon how this is done. Cindy.cicalese (talk) 20:47, 3 June 2018 (UTC)[reply]

Endorsements

[edit]

Comments

[edit]

Way to announce and publish new extensions and features

[edit]
Tracked in Phabricator
Task T209085

Currently when we create a new extension/skin/script, nobody gets to know about it. Same is the case when adding a new feature to an existing extension. There should be a way to register a new extension somewhere and then it gets published in a digest mail to the mediawiki-l mailing list. New features could be announced in a similar way. This should be automated to some extent probably by using extension.json. Nischayn22 (talk) 07:12, 12 June 2018 (UTC)[reply]

Endorsements

[edit]

Comments

[edit]

Also see What's New Nischayn22 (talk) 07:12, 12 June 2018 (UTC)[reply]

  • We have the newsletter functionality so I think it should be done via this channel instead of creating some page somethere. Moreover who will manage this newsletter or "way"? --[[kgh]] (talk) 14:10, 20 June 2018 (UTC)[reply]
    • I think it should be automated. The extension.json file could have a "whats new" field where we can add some info (similar to how android apps have a What's New). This should be browseable on mw.org and there should also be a way to subscribe for this.Nischayn22 (talk) 17:32, 10 July 2018 (UTC)[reply]

Installing

[edit]
Current documentation to install extensions: Manual:Extensions#Installing an extension and extension pages

Programatically enable/disable extensions from the command line

[edit]
Tracked in Phabricator
Task T209086

I use Debian packages to install MediaWiki. I'd like to be able to programatically enable/disable extensions from the command line. The main way I envision this being used is that when people install a Debian package of an extension, the package can automatically enable the extension without needing to create or edit PHP files. This would also be applicable to MediaWiki-Vagrant as well I believe. Legoktm (talk) 05:21, 16 May 2018 (UTC)[reply]

Endorsements

[edit]

Comments

[edit]
  • This sounds like yet an extra way to manage extensions. I have already five or so processes I have to track depending of which version to use and how to invoke and what steps to take. I am very reluctant about this. --[[kgh]] (talk) 14:19, 20 June 2018 (UTC)[reply]

I think installing extensions should be possible using a special page

[edit]

Installing extensions from command line or using FTP is very cumbersome and shouldn't be the default way. Instead we should have a Special Page to install any extension. I do understand that this may not be possible for various extensions that require additional software to be installed on the server and those may be exceptions. Nischayn22 (talk) 06:14, 17 May 2018 (UTC)[reply]

Endorsements

[edit]

Comments

[edit]

There should be one central extension management page that allows finding, installing, updating, enabling/disabling, configuring and uninstalling extensions. Much like plugin management in any other software.

  • There should be a mechanism to disable installing/uninstalling from the web frontend. (For security considerations, but also for wikifarms who want to allow enabling/disabling, but not installing/uninstalling.)
  • There should be a mechanism to exclude certain extensions from being managed through this special page (Use case is again wikifarms who may want to force some extensions.)

--F.trott (talk) 07:47, 17 May 2018 (UTC)[reply]

  • Is there a specific requirement that this be a special page, or would any web frontend (e.g. as a part of the web installer) meet your needs? Legoktm (talk) 17:34, 18 May 2018 (UTC)[reply]
    • It depends on how managing extensions should work as a user interaction. If you want to allow the installation process to be run again for an extension to be added or removed, it could well be part of the installation manager (Although people might be hesitant to run it again for fear of accidentally breaking something.). I'd argue that currently management tasks on the wiki are done using Special pages, so admins would probably expect to find extension management there, too. --F.trott (talk) 09:54, 19 May 2018 (UTC)[reply]
    • It would be preferable to be a separate web frontend since the act of enabling an extension could make the wiki inaccessible, hence making it impossible to return to the special page to disable the problematic extension. It should also be separate from the web installer, since it should be possible to enable/disable extensions well after installation is complete. --Cindy.cicalese (talk) 10:07, 19 May 2018 (UTC)[reply]
      • Hmm, fair point. But using an external page would also mean you'd lose all the MW context, e.g. user rights. Could it be an option to introduce some kind of "safe mode" activated by URL parameter that would skip loading extensions? --F.trott (talk) 10:45, 19 May 2018 (UTC)[reply]
    • I'd also go for a dedicated entry point (e.g. <mediawiki>/admin.php) that does not include the WebStart.php. It could be implemented with a common web framework like Laravel or Symfony. Osnard (talk) 15:14, 19 May 2018 (UTC)[reply]
    • To clarify, the main reason I asked was because of "Focus on the functionality you desire, rather than the specific implementation". If there's some important sticking point that it has to be done with a special page, then that's fine, but if not, I think it should be rephrased to be just any web frontend. Legoktm (talk) 17:53, 19 May 2018 (UTC)[reply]
    • Right you are. :) And after the discussion at the hackathon I think it might actually be beneficial to have it as an external application. I modified the proposal. I am not the only one to have commented here, but as far as I am concerned, feel free to summarize or remove the discussion.
  • I wonder how it would work from security POV. This implies write access to all web tree for webserver user, which may be not the best idea for security. Command-line tool may be better for this. Also, bootstrapping/cross-dependency issues may be very tricky - either installed shares almost no code with the rest of MediaWiki, or there's a potential for installed extension to leave wiki in a state where install interface no longer works and there's no way to roll it back. Smalyshev (WMF) (talk) 00:12, 24 May 2018 (UTC)[reply]

Differentiate installing from enabling/disabling

[edit]

While some environments may want to install and enable extensions as one step, it should also be possible to install a large set of extensions and selectively enable some of them. Some extensions may only be enabled during maintenance, for example, and then subsequently disabled. In a wiki farm environment, a different set of extensions may be enabled on different wikis, even though they share a directory of a large number of installed extensions. Cindy.cicalese (talk) 10:15, 19 May 2018 (UTC)[reply]

Endorsements

[edit]

Comments

[edit]

Programatically install extension dependencies (for dev and testing) via command line

[edit]

Currently Wikimedia CI relies on a mapping inside the integration/config repository to determine which extensions depend on other extensions within the context of CI; however, outside of our current testing setup this is not usable. Allowing extensions to define those other extensions on which they depend would be generally useful as well as useful for future development of an extension-testing pipeline. TCipriani (WMF) (talk) 14:27, 19 May 2018 (UTC)[reply]

Endorsements

[edit]

Comments

[edit]

Enable/disable extensions from a web interface

[edit]

This would need to be done as a secure front-end isolated from MediaWiki (or in a "safe mode") to ensure that the web interface does not become inoperable when extensions are misconfigured. A sysop should be able to disable the web interface from the back end in environments that do not want to expose it. The process of enabling/disabling extensions must be wikifarm aware (which presupposed a standard way of configuring wikifarms) so that extensions can be enabled/disabled on a per wiki or per wikifarm basis. Users would be presented with a list of installed extensions to choose from. This web interface would not be used to install extensions. Cindy.cicalese (talk) 20:59, 3 June 2018 (UTC)[reply]

Endorsements

[edit]

Comments

[edit]
  • If this is just about enabling/disabling extensions go forward. I should however be possible to disable such a special page. I personally do not want my admins to fiddle with extension management. --[[kgh]] (talk) 14:20, 20 June 2018 (UTC)[reply]
    • Another option will be to be able to specify which extensions may be enabled or disabled, something like user group management ($wgAddGroups/$wgRemoveGroups). --[[kgh]] (talk) 14:28, 20 June 2018 (UTC)[reply]
  • Since the set of extensions is usually selected upon installation and only rarely thereafter probably not a front burner thing. --[[kgh]] (talk) 14:28, 20 June 2018 (UTC)[reply]

Upgrading

[edit]
Current documentation to upgrade extensions: Manual:Extensions#Upgrading an extension and extension pages

Identify outdated extensions from a web interface

[edit]

I would like to be able to identify extensions that have updates available from a web interface. Extensions that have known security issues would be highlighted in some way. Legoktm (talk) 06:00, 16 May 2018 (UTC)[reply]

Endorsements

[edit]

Comments

[edit]

One concern that was mentioned at the Wikimedia hackathon session on this rfc was that this may end up being a security concern as Special:Version is a public page that would be broadcasting that a particular installation is using out-of-date-extensions.TCipriani (WMF) (talk) 17:52, 19 May 2018 (UTC)[reply]

I don't think there's any requirement to use Special:Version to provide this interface, or even make it public. It's just that I, as a wiki sysadmin, want some web interface that shows me the status of my extensions. Whether it requires a specific user right or some other access control is an issue for implementation IMO. Legoktm (talk) 18:07, 19 May 2018 (UTC)[reply]
  • This should be behind a user right. Somethimes updates are a must sometime they are not, e.g. new features vs. security fixes. Also these updates shoudl be trackt on a branch basis or if a new version tag is available as opposed to a rel tag. --[[kgh]] (talk) 14:43, 20 June 2018 (UTC)[reply]

Channels to subscribe

[edit]

There should be channels like latest-lts, 1-27-lts, 1-31-lts and latest-stable. This way the consumer does not have to care about versions. He is just choosing the desired channel and the catalogue provides the appropriate versions. The channel could also be set implicitly, based on the actual version of MW the consumer is using. Osnard (talk) 07:54, 20 May 2018 (UTC)[reply]

Endorsements

[edit]

Comments

[edit]

...

Other

[edit]

Configuring an extension should be possible from a special page

[edit]

Almost all extensions have various configurations that require us to edit LocalSettings.php file. I think this could be better done using a Special Page where we would have a form for all the configuration options available and the values can be set from there. Nischayn22 (talk) 06:16, 17 May 2018 (UTC)[reply]

Endorsements

[edit]

Comments

[edit]

Revisit extension compatibility policies

[edit]

The current compatibility policies are "master" and "rel".

Policy Pros Cons
rel
  • Makes it clear which version of an extension to use for a given MediaWiki version.
  • Release branches are automatically cut when the first MediaWiki release candidate for a new MediaWiki version is created. This is usually before an extension owner has had a chance to verify that the extension works with that MediaWiki version. Any bug fixes need to be backported to the release branch.
  • If new features are added to an extension that are desirable for the current LTS, they need to be backported. This is not necessarily a straightforward process if not all patches are backported.
  • Especially for volunteers maintaining extensions, keeping multiple release branches up to date can be burdensome.
master
  • Easier for extension maintainers, since no backporting is necessary.
  • Requires backward compatibility shims, which make the code ugly.
  • It becomes less clear which versions of MediaWiki are supported by an extension.
  • ExtensionDistributor provides the release branches of extensions that use master compatibility policy. This frequently results in conversations like:
User: Why isn't feature X working?
Maintainer: Are you using the latest code?
User: Yes!
. . . lots of discussion back and forth . . .
User: . . . when I downloaded the extension from ExtensionDistributor for the version of MediaWiki I'm using . . .
Maintainer: Oh! You should not use the release branch for an extension that has master compatibility policy.

It would be good to revisit the compatibility policies or the supporting environment to try to address some of the issues. Cindy.cicalese (talk) 21:21, 3 June 2018 (UTC)[reply]

Endorsements

[edit]

Comments

[edit]
  • As far as I am concerned I only want to know if I get backports to LTS or not and if the backports include new features, just fixes or only security fixes. Somewhere on this wiki I tried to figure out what these two policies acutally mean. Moreover I suggsted a tagged policy. I cannot find it right now and it was inconlcusive since knowbody was really able to tell what to add. --[[kgh]] (talk) 14:38, 20 June 2018 (UTC)[reply]

Include help documentation within extensions

[edit]

At the moment we link to pages on MediaWiki.org (prefixed with Help:Extension:) to provide end-user help/documentation for extensions. The problems with this are a) that the version in use may not be the latest, and so the docs may not apply; and b) the user is sent away from their wiki and so gets confused. It'd be cool to be able to include help pages within extensions' code, so that the user always sees docs that are applicable to the version they're actually using, and in their own wiki. —Sam Wilson 02:37, 6 June 2018 (UTC)[reply]

Edit: I meant to add that the docs could also be available on MediaWiki.org (via some magic), perhaps even for multiple versions. Sam Wilson 00:19, 7 June 2018 (UTC)[reply]

Endorsements

[edit]

Comments

[edit]
Retrieved from "https://www.mediawiki.org/w/index.php?title=Extension_management_2018_feedback&oldid=2795012"