|Open||None||T199372 Use stakeholder feedback to develop a plan for extension management (TEC13)|
|Open||None||T209086 Programatically enable/disable extensions from the command line|
My rough idea so far is:
- Create a new database table, extensions(ex_wiki, ex_name). This table would have the option of being centrally managed (like botpasswords).
- ex_wiki is the name of the wiki the extension is enabled on, and in the future it could support family style enabling for wiki-farms (+wikisource) or something.
- The contents of this table would be cached in APCu.
- Add maintenance/manageExtensions.php <name> <enable/disable>. It writes to the database table, and should be self-explanatory.
- We're not going to provide Debian Apache-style mwexten/mwextdis shortcuts in core, but distributions can explore adding those if they want.
- Probably this will also trigger update.php if necessary (with a CLI option not to)
- Maybe also tells you that you need to install composer dependencies?
- Introduce a new constant, MW_NO_EXTENSIONS, which if at the top of a maintenance script, prevents extensions from loading (by disabling ExtensionRegistry). This will be used in manageExtensions.php to ensure that even if an extension breaks something, it can still be disabled.
The main downside of using this script is that it can't set config settings for extensions where the default configuration is bad - yet.
Notes from today's meeting:
- Should have a migration plan (script to copy all existing enable stuff into the table, and then tell people they can manually remove the wfLoad calls?)
- Clarify that this is not a breaking change, wfLoad* will continue to work
- Reach out to NASA (aka Meza) folks to see if this would be useful for them and what their needs are
- Figure out whether this should be an RfC or not