Last modified: 2012-04-16 09:16:09 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T28857, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 26857 - Fatal error during installation enabling 'Vector' extension
Fatal error during installation enabling 'Vector' extension
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Installer (Other open bugs)
unspecified
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-01-22 01:45 UTC by Brion Vibber
Modified: 2012-04-16 09:16 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Brion Vibber 2011-01-22 01:45:58 UTC
MW trunk on r80737

Full extensions folder is checked out; using all default install options plus:
* Vector extension on
* image uploads on
* memcached on (localhost:11211)


Output in browser stopped at:

    Install

    Including extensions...


Error log shows:

PHP Notice:  Undefined variable: wgResourceModules in /var/www/trunk/extensions/Vector/Vector.php on line 109, referer: http://stormcloud.local/trunk/config/index.php?page=Options

PHP Fatal error:  Unsupported operand types in /var/www/trunk/extensions/Vector/Vector.php on line 109, referer: http://stormcloud.local/trunk/config/index.php?page=Options


Disabling memcache makes no difference; disabling image uploads *should* make no difference, but didn't get a chance to try in total isolation. Disabling both image uploads and Vector extension got me a functional install.
Comment 1 Roan Kattouw 2011-01-22 01:47:41 UTC
You're using trunk MediaWiki and $wgResourceModules doesn't exist?!? Is your DefaultSettings.php up to date? Does it set $wgResourceModules?
Comment 2 Brion Vibber 2011-01-22 02:16:01 UTC
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?
Comment 3 Chad H. 2011-01-22 02:28:22 UTC
(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)
Comment 4 Brion Vibber 2011-01-22 02:35:33 UTC
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.
Comment 5 Chad H. 2011-01-22 02:42:09 UTC
(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.
Comment 6 Brion Vibber 2011-01-22 03:55:32 UTC
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.
Comment 7 Alain Picard 2011-01-22 23:28:44 UTC
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?
Comment 8 Roan Kattouw 2011-01-24 01:52:17 UTC
(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).
Comment 9 Chad H. 2011-01-31 20:19:49 UTC
This should be resolved with r81266.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links