You're using trunk MediaWiki and $wgResourceModules doesn't exist?!? Is your DefaultSettings.php up to date? Does it set $wgResourceModules?

The installer require()s extension files from within the Installer::includeExtensions() method, so I think any reference to global configuration variables directly in the extension file will fail.

Using a 'global' declaration before each global, or accessing them via $GLOBALS, should resolve that, but I think most extensions that actually need to be doing configuration setup at install time will be potentially affected.

In this case it's extra bogus because not having $wgResourceModules triggers a fatal error with the array += operator; most cases are probably just spewing E_NOTICE whinging about undefined variables.

Now, if the point of including the extensions at this time is to get hooks set up so it'll do the database installation, I don't think this is going to work -- any changes to the global arrays will get wiped out... so the updater hooks won't be there?

(In reply to comment #2)

Now, if the point of including the extensions at this time is to get hooks set
up so it'll do the database installation, I don't think this is going to work

• any changes to the global arrays will get wiped out... so the updater hooks

won't be there?

It's mainly for extensions to get a chance to tie into $wgHooks['LoadExtensionSchemaUpdates'] at install-time and not only at upgrade time (so new tables will be created and you don't have to re-run as an update to get them)

If they're creating / adding to a local variable called '$wgHooks' within Installer::includeExtensions(), I don't think that'll trigger anything at install time.

They would need access to the global $wgHooks and any other global variables that those hooks need access to if/when they get run.

(In reply to comment #4)

If they're creating / adding to a local variable called '$wgHooks' within
Installer::includeExtensions(), I don't think that'll trigger anything at
install time.

That's a mistake on my part, it was supposed to declare global $wgHooks before the require()s.

Ok, so if the only thing we're going to take out of it is $wgHooks entries for schema updates, then explicitly global'ing $wgHooks is probably ok for functional purposes.

We still have the problem that the extension files expect to be loaded in a different context than where we're loading them, and they can spew warning messages or halt the program with a fatal error...

As mentioned in IRC, loading up DefaultSettings.php into local function context first will likely get most or all extension files to load through cleanly. It's still possible some could fail due to something else not being set, or setting their hooks from an extension setup function which might not get called, or trying to include other libraries early etc.

It may be wise to cook up some guidelines to ensure that extension files are safe to load outside of global context, but doing all that stuff really right might be ugly.

picard wrote:

I am having the same issue after trying to install the Collection extension from svn trunk on a 1.16.1 upgraded install.

Notice: Undefined variable: wgResourceModules in /var/www/html/iris/extensions/Collection/Collection.php on line 192

Fatal error: Unsupported operand types in /var/www/html/iris/extensions/Collection/Collection.php on line 192

Will any fix cover this as well?

(In reply to comment #7)

I am having the same issue after trying to install the Collection extension
from svn trunk on a 1.16.1 upgraded install.

Notice: Undefined variable: wgResourceModules in
/var/www/html/iris/extensions/Collection/Collection.php on line 192

Fatal error: Unsupported operand types in
/var/www/html/iris/extensions/Collection/Collection.php on line 192

Will any fix cover this as well?

If you're trying to install it through the installer, yes. If you tried to install it the old-fashioned way (by adding require_once(blahblah) to LocalSettings.php), then no. In the latter case, something else is probably wrong (e.g. you didn't upgrade DefaultSettings.php correctly).

This should be resolved with r81266.