Changing every instance of vector to something else might not be a good idea, because not every instance of the word vector may correspond to the skin name.

It sounds like you changed a reference of which module to load, without making a 'zelda' module (That's a total guess though)

I'm leaning towards this is not a bug.

anton.kochkov wrote:

only change words vector in css classnames, as skin name and in various var names. and changed module/skin name to new word, also renamed directory with css and images.

The line you changed that broke everything is: $out->addModuleStyles( 'skins.vector' );

(In reply to comment #2)

only change words vector in css classnames, as skin name and in various var
names. and changed module/skin name to new word, also renamed directory with
css and images.

Well yes, doing a global find and replace on part of the codebase is a good way to introduce bugs. Anyhow that's kind of off topic since bugzilla is not a support forum.

Re-purposing bug:
Expected behaviour:
*Calling $out->addModuleStyles( 'some.invalid.module' ); should either ignore the invalid module, or throw an exception.

Actual behaviour:
Fatal error: Call to a member function getGroup() on a non-object in
/home/pidginet/public_html/test/includes/OutputPage.php on line 2707

I'm not sure which of ignoring or throwing an exception is better. I personally prefer throwing an exception, however (based on a quick look) scriptModules that are invalid already seem to be ignored so there is precedent that way (but this ignoring seems to be a side effect of filtering them for top/bottom, and not intentional)

At the least we could use wfDebug or wfWarn.

Taking a look at OutputPage.php right now we still use $module = $resourceLoader->getModule( $name ); and then right after start maing calls to $module. ResourceLoader::getModule explicitly says that the return value of getModule may be null, so this doesn't look like proper coding. That portion of OutputPage needs to properly guard against null module returns (just as we guard against null titles) and if it does any failing at all it should at the very least do so using a descriptive message about how a module does not exist, instead of throwing cryptic error messages as a result of trying to call something on null.

r104030 fixes the OutputPage issue described in comment 3 and comment 4.