Open main menu

Programatically enable/disable extensions from the command lineEdit

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)

EndorsementsEdit

  • Legoktm (talk) 05:21, 16 May 2018 (UTC)
  • --Gabriel Birke (WMDE) (talk) 16:00, 18 May 2018 (UTC)
  • Osnard (talk) 15:14, 19 May 2018 (UTC)
  • Something like a maintenance script sounds nice and easy enough to me. Ladsgroup (talk) 11:11, 23 May 2018 (UTC)
  • Would help a lot for vagrant. I've had a number of times when I needed to test with/without certain ext, and removing and reenabling it takes time. Separating "installed" from "enabled" and giving tools to control "enabled" would help. Smalyshev (WMF) (talk) 00:12, 24 May 2018 (UTC)
  • Cindy.cicalese (talk) 20:49, 3 June 2018 (UTC)
  • Edward Chernenko (talk) 23:18, 6 June 2018 (UTC)
  • ...

CommentsEdit

  • 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)

I think installing extensions should be possible using a special pageEdit

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)

EndorsementsEdit

CommentsEdit

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)

  • 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)
    • 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)
    • 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)
      • 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)
    • 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)
    • 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)
    • 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)

Differentiate installing from enabling/disablingEdit

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)

EndorsementsEdit

CommentsEdit

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

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)

EndorsementsEdit

CommentsEdit

  • I thought this can already be specified via "extension.json" when using manifest 2? No? Or is this just for specifying the mimimum MW requrement? --[[kgh]] (talk) 14:16, 20 June 2018 (UTC)

Enable/disable extensions from a web interfaceEdit

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)

EndorsementsEdit

CommentsEdit

  • 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)
    • 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)
  • 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)