Page MenuHomePhabricator

Running installer on existing wiki can fail when extensions are enabled
Closed, ResolvedPublic

Description

Running the installer on your existing wiki can fail when extension entry points expect their own classes to be registered already when we call Installer::getExistingLocalSettings(). Since the require() there isn't in the global scope, $wgAutoloadClasses doesn't "work" and the subsequent call to the class will fail.


Fatal error: Class 'MwEmbedResourceManager' not found in /vagrant/mediawiki/extensions/MwEmbedSupport/MwEmbedSupport.php on line 58

Call Stack:

0.0000     638800   1. {main}() /vagrant/mediawiki/mw-config/index.php:0
0.0281    3246320   2. wfInstallerMain() /vagrant/mediawiki/mw-config/index.php:31
0.0852    7279256   3. WebInstaller->execute() /vagrant/mediawiki/mw-config/index.php:72
0.0903    7662024   4. WebInstallerExistingWiki->execute() /vagrant/mediawiki/includes/installer/WebInstaller.php:280
0.0903    7662024   5. Installer::getExistingLocalSettings() /vagrant/mediawiki/includes/installer/WebInstallerPage.php:316
0.0908    8019208   6. require('/vagrant/mediawiki/LocalSettings.php') /vagrant/mediawiki/includes/installer/Installer.php:541
0.0915    8020256   7. require_once('/vagrant/LocalSettings.php') /vagrant/mediawiki/LocalSettings.php:128
0.0929    8028128   8. include_once('/vagrant/settings.d/puppet-managed/10-CirrusSearch.php') /vagrant/LocalSettings.php:91
0.0935    8087728   9. include_once('/vagrant/mediawiki/extensions/CirrusSearch/tests/jenkins/Jenkins.php') /vagrant/settings.d/puppet-managed/10-CirrusSearch.php:6
0.0943    8149968  10. require_once('/vagrant/mediawiki/extensions/MwEmbedSupport/MwEmbedSupport.php') /vagrant/mediawiki/extensions/CirrusSearch/tests/jenkins/Jenkins.php:45

This is based on me running Cirrus + MwEmbedSupport on vagrant but it's not specific to any of these cases. You could do a simpler case like this in your LocalSettings:


// other config above here
require_once( "test.php" );


With a test.php of:


<?php

$wgAutoloadClasses['foo'] = 'foo.php';

foo::bar()


This coding style works when in normal execution but explodes for very obvious reasons otherwise. Other than "we shouldn't do that and fix instances where we are" can we think of any sorts of ways to mitigate the problem?


Version: unspecified
Severity: normal

Details

Reference
bz67440

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 3:28 AM
bzimport set Reference to bz67440.
bzimport added a subscriber: Unknown Object (MLST).

Change 143779 had a related patch set uploaded by Chad:
Allow classes to be registered properly from installer

https://gerrit.wikimedia.org/r/143779

Change 143779 merged by jenkins-bot:
Allow classes to be registered properly from installer

https://gerrit.wikimedia.org/r/143779

"fixed" for now, should probably revisit when we have sane extension registration. Flagging for backport.

Change 165727 had a related patch set uploaded by MarkAHershberger:
Allow classes to be registered properly from installer

https://gerrit.wikimedia.org/r/165727

Change 165728 had a related patch set uploaded by MarkAHershberger:
Allow classes to be registered properly from installer

https://gerrit.wikimedia.org/r/165728

Change 165729 had a related patch set uploaded by MarkAHershberger:
Allow classes to be registered properly from installer

https://gerrit.wikimedia.org/r/165729

Change 165727 merged by jenkins-bot:
Allow classes to be registered properly from installer

https://gerrit.wikimedia.org/r/165727

Change 165728 merged by jenkins-bot:
Allow classes to be registered properly from installer

https://gerrit.wikimedia.org/r/165728

Change 165729 merged by jenkins-bot:
Allow classes to be registered properly from installer

https://gerrit.wikimedia.org/r/165729