Extension management 2018 feedback/Installing

Programatically enable/disable extensions from the command line
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)

Endorsements

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

I think installing extensions should be possible using a special page
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)

Endorsements

 * Nischayn22 (talk) 06:14, 17 May 2018 (UTC)
 * F.trott (talk) 07:50, 17 May 2018 (UTC)
 * Osnard (talk) 15:14, 19 May 2018 (UTC)

Comments
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. --F.trott (talk) 07:47, 17 May 2018 (UTC)
 * 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.)


 * 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. ) 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/disabling
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)

Endorsements

 * Cindy.cicalese (talk) 10:15, 19 May 2018 (UTC)
 * Osnard (talk) 15:14, 19 May 2018 (UTC)
 * Legoktm (talk) 18:02, 19 May 2018 (UTC)
 * F.trott (talk) 19:40, 19 May 2018 (UTC)
 * Smalyshev (WMF) (talk) 00:12, 24 May 2018 (UTC)

Programatically install extension dependencies (for dev and testing) via command line
Currently Wikimedia CI relies on a mapping inside the  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)

Endorsements

 * TCipriani (WMF) (talk) 14:27, 19 May 2018 (UTC)
 * DDuvall (WMF) (talk) 17:23, 19 May 2018 (UTC)
 * Legoktm (talk) 17:51, 19 May 2018 (UTC)
 * F.trott (talk) 19:40, 19 May 2018 (UTC)
 * Smalyshev (WMF) (talk) 00:12, 24 May 2018 (UTC)