Page MenuHomePhabricator

composer installed SF 3.6 does not take $wgExtensionDirectory into account (MW 1.27)
Closed, ResolvedPublic

Description

Hi,

upgrading to MW 1.27 I installed SF via composer but it fails to take $wgExtensionDirectory into account. I have a wiki that is symlinked and and set wgExtensionDirectory in LocalsSettings but it tries to load SF from a different location that does not exist. When I try to runJobs.php it reports:

sudo -u wwwrun php ./maintenance/runJobs.php  --maxjobs 1000  --conf LocalSettings.php
PHP Fatal error:  Uncaught exception 'Exception' with message '/usr/share/mediawiki/extensions/SemanticForms/extension.json does not exist!' in /usr/share/mediawiki/includes/registration/ExtensionRegistry.php:106
Stack trace:
#0 /usr/share/mediawiki/includes/GlobalFunctions.php(115): ExtensionRegistry->queue('/usr/share/medi...')
#1 /var/lib/mediawiki/webroot/extensions/SemanticForms/SemanticForms.php(56): wfLoadExtension('SemanticForms')
#2 /usr/share/mediawiki/vendor/composer/autoload_real.php(66): require('/var/lib/mediaw...')
#3 /usr/share/mediawiki/vendor/composer/autoload_real.php(56): composerRequire_mediawiki_vendor('2e2887c5a0d771c...', '/var/lib/mediaw...')
#4 /usr/share/mediawiki/vendor/autoload.php(7): ComposerAutoloaderInit_mediawiki_vendor::getLoader()
#5 /usr/share/mediawiki/maintenance/doMaintenance.php(75): require_once('/usr/share/medi...')
#6 /usr/share/mediawiki/maintenance/runJobs.php(127): require_once('/usr/share/medi...')
#7 {main}
thrown in /usr/share/mediawiki/includes/registration/ExtensionRegistry.php on line 106

Other composer extension do load as expected, e.g Semantic Mediawiki but not SF. So I have to download SF the old way. I guess there is something wrong with the extension registration.

Or is there something that I am doing wrong?

Event Timeline

Are you using wfLoadExtension explicitly, or require_once, or just relying on composer autoloading?

The extension was loaded by composer autoloading when I installed it via composer. LocalSettings had no effect whatsoever. In MW 1.25+ (1.26 probably as well) I had to manually load composer in LocalSettings:

if (is_readable("$IP/vendor/autoload.php")) {
  require_once( "$IP/vendor/autoload.php");
}

And that way some LocalSettings could take effect. But in MW 1.27 composer is magically loaded before the LocalSettings.

Of course I could manually symlink the SemanticForms-directory to /usr/share/mediawiki/extensions/ but that is somewhat a messy approach to maintain, because

  • usually one would expect to install it via composer and it works or
  • set additional configurations to adjust functionality and it should work

I know you try the best to make it work, but my guess is that there is something missing to choose when to load the composer. Or is there?

In the meantime I removed SemantcForms from composer and do loading the old way and it works as usual for SF 3.6:

  1. git clone of extension, git checkout 3.6
  2. in LocalSettings.php: set $wgExtensionDirectory to my symlinked extension directory
  3. in LocalSettings.php: requre_once or wfLoadExtension work both

Yep that's what I feared. I do not see any sensible way to make composer autoloading work with extension registration. I have removed composer autoloading from my extensions (SF is not mine).

usually one would expect to install it via composer and it works

... and it should (and it did at some point).

I do not see any sensible way to make composer autoloading work with extension registration.

I feared something like this could easily jeopardise the SMW setup therefore I refrained from making any attempt of using the extension.json (besides some other reasons) for listed https://github.com/SemanticMediaWiki repo's.

@cicalese @Legoktm Some input on this would be appreciated to void confusions and frustrations for a possible future conversion.

Taking @Nikerabbit 's advice, I just removed the "autoload" clause from SF's composer.json file. If anyone knows of a better way to solve this issue, please let me know.

Yaron_Koren claimed this task.

Marking this as resolved... maybe there's a better approach, but this one does seem to solve the problem.