Current state:

Classically there were three types of installation+activation of MediaWiki extensions (same for skins):

1. installation by putting its directory in extensions/ + activation with require_once in LocalSettings.php;
2. installation by putting its directory in extensions/ + activation with wfLoadExtension in LocalSettings.php;
3. installation with Composer (type = mediawiki-extension) + activation with Composer autoloader.

The third type is known to be badly compatible with wikifarms (because activation cannot be done on a per-wiki basis), but MediaWikiFarm has a workaround (script mwcomposer) by segregating mediawiki-extension’s autoloader and calling it when required during MediaWiki initialisation.

Issue:

A forth type appeared with PageForms 3.7 (see 705cfd4 therein):

4. installation equivalently by putting its directory in extensions/ or with Composer + activation with wfLoadExtension (or require_once) in LocalSettings.php.

This new configuration should be understood by MediaWikiFarm. Currently it is classified as the third type and MWF assumes it can be activated by activating its Composer autoloader, but this one is empty. The only way to activate it is to use wfLoadExtension or require_once (depending of what is available). I find this is the best way to use both Composer for dependency management and MediaWiki for activation, but it is difficult to recognise extensions between the third and the forth types.

Proposed solutions:

• Use both mechanisms (Composer autoloader and wfLoadExtension) when both are available; this could perhaps lead to re-loading some classes (=fatal error) or duplication of some categories, e.g. hooks defined both by a PHP file loaded with Composer and with extension.json;
• Detect that some composer.json has no "autoload" (or no "autoload -> files") section and assume wfLoadExtension/require_once must be used in that case;
• Classify existence of a composer.json + extension.json as the forth type; but I guess there are false positives;
• Use a static map, e.g. PageForms 3.7+ -> wfLoadExtension (I do not like this solution);
• …

At first sight I find the best solution is the second (detect an "empty" autoloader). The difficulty here is to choose one or another solution given there is for now only one extension with that type, and it could depend on how other extensions evolves in the future.