Extension:MediaWikiFarm/Internals

Composer-installed extensions
3 possible strategies: Then, during MediaWiki execution, /vendor/autoload.php loads the required /vendor/composerKEY (possibly multiple such directories) and hence the requested extensions are loaded (possibly a class could be loaded by multiple autoloaders, it’s not grave, and it could be avoided as an improvement). Given the new tendency to autoload classes with Composer (e.g. PSR-4) then activate the extension with wfLoadExtension (PageForms, etc.), we could use the dependency graph obtained from composer.json to correctly sort the various wfLoadExtension functions. For implementation, it is probable possible to obtain the dependencies from Composer with a plugin installed in composer.json in mwcomposer.json.
 * 1) Bold: A script (mwcomposer.php) iterates overs Composer-installed extensions and skins (type: mediawiki-extension or mediawiki-skin), creates as much /vendor/composer directories as there are combinations (= 2^n = \sum_{k=0}^n C(n,k), where n = #extensions), each one with a key (e.g. a hash of its content), then replaces the /vendor/autoload.php by a customised file; this one get the Composer key from MediaWiki (for now when used in multiversion mode, since configuration can be loaded before in this mode) and require_once the right composer subdirectory.
 * 2) Conservative: Similar to the previous scenario, but creates as much MediaWiki directories as there are combinaisons (2^n)
 * 3) Quick bold: Like the bold strategy, but instead of iterating over all combinations, just iterating over extensions , create /vendor/composerKEY for each extensions (inside, it contains all other required extensions and libraries), and read in each composer.json the dependencies. The first step of the iteration remains with all extensions activated, so that Composer handles at the beginning if there are incompatible extensions and we are sure, after this step, there exists a coherent versions set.

Benefits/drawbacks:
 * 1) Bold:
 * 2) *  less disk space used, cleaner (not many MW installations)
 * 3) *  bold (more issues expected), the customised binary Composer must be used instead, O(n^2) complexity
 * 4) Conservative:
 * 5) *  fully compatible with MediaWiki and Composer, even old versions
 * 6) *  more disk space used, less practical to manage MediaWiki
 * 7) Quick bold:
 * 8) *  even less disk space used, cleaner (not many MW installations), O(n) complexity
 * 9) *  bold (more issues expected), the customised binary Composer must be used instead, it reads composer.json so more maintenance expected, possibly a bit slower at runtime than bold (a per-wiki cache could be created, it could be thought)