Wikimedia Bugzilla is closed!

>[Tue Nov 29 13:10:07 2011] [error] [client {my-ip}] "" is not a valid magic
>word for "canonicalurle"

So perhaps something to do with LocalizationCache not realizing that the language files have changed maybe. I believe that error would be caused if it couldn't find any entries for that magic word (since in that case the value is false, which gets printed as empty string)

>[Tue Nov 29 13:10:07 2011] [error] [client {my-ip}] PHP Fatal error: Call to a
>member function getGroup() on a non-object in
>{path-to-wiki}/includes/OutputPage.php on line 2958

Is RL related (specifically, if someone tried to add a style module that didn't exist)

---
Both of these errors would probably be caused by someone extracting over top of an existing install, but only extracting the includes directory, and not extracting the "resources" and the "languages" directory.

I was one of the original reporters for this bug, over on the MediaWiki-l mailing list. Regarding the "Call to a member function getGroup() on a non-object" error, as stated above this occurred when I tried to install MediaWiki to a new, clean directory. I did originally try to extract 1.18 over an existing 1.17 installation, but ran into a different set of problems. This error occurred after I restored my original 1.17.1 install and tried installing 1.18 to a new directory. The only items I copied over from the 1.17.1 install were LocalSettings.php and my images directory.

(In reply to comment #2)
> I was one of the original reporters for this bug, over on the MediaWiki-l
> mailing list. Regarding the "Call to a member function getGroup() on a
> non-object" error, as stated above this occurred when I tried to install
> MediaWiki to a new, clean directory. I did originally try to extract 1.18 over
> an existing 1.17 installation, but ran into a different set of problems. This
> error occurred after I restored my original 1.17.1 install and tried installing
> 1.18 to a new directory. The only items I copied over from the 1.17.1 install
> were LocalSettings.php and my images directory.

-----
(btw, this (invalid RL module) is no longer a fatal in trunk due to r104030. Perhaps that should be back-ported)


I'm not sure how much/if you are willing to debug this, but if you are willing to debug this, it would be useful to know:

* if languages/messages/MessagesEn.php contains the line:
'canonicalurle'          => array( 0,    'CANONICALURLE:'         ),

(probably somewhere around line 314) [This is just to make sure the file didn't somehow get corrupt on your end]

*Applying the following patch, would give more detailed error reporting about where the invalid style module is coming from:

Index: OutputPage.php
===================================================================
--- OutputPage.php	(revision 104932)
+++ OutputPage.php	(working copy)
@@ -2955,7 +2955,9 @@
 		$styles = array( 'other' => array(), 'user' => array(), 'site' => array(), 'private' => array(), 'noscript' => array() );
 		$resourceLoader = $this->getResourceLoader();
 		foreach ( $this->getModuleStyles() as $name ) {
-			$group = $resourceLoader->getModule( $name )->getGroup();
+			$mod = $resourceLoader->getModule( $name );
+			if ( !mod ) throw new MWException( "invalid module name: $name" );
+			$group = $mod->getGroup();
 			// Modules in groups named "other" or anything different than "user", "site" or "private"
 			// will be placed in the "other" group
 			$styles[isset( $styles[$group] ) ? $group : 'other'][] = $name;

OK, I think I've narrowed down where my problem lies. It could be somewhere between the keyboard and the chair. It could also be in the MediaWiki skinning system.

languages/messages/MessagesEn.php is fine; the line referenced above is present.

I stepped back through the process of installing 1.18.0: I extracted the tarball into a new directly, copied over the LocalSettings.php and images directory, ran maintenance/update.php, and did the necessary magic within my Apache configuration to have it point to the new directory. This time, however, I skipped the step of creating my custom skin and commented out the code in LocalSettings.php that referenced it. MediaWiki loaded up just fine with MonoBook as the skin.

Then I went through the task of setting back up my custom skin. Essentially what I do for this is to copy the MonoBook class files (MonoBook.php and MonoBook.deps.php) and rename them to the new skin name, then edit the main skin class file (we'll call it "NewSkin.php") to replace all references of MonoBook to NewSkin. I create a "newskin" directory and fill it with symbolic links to all the files in ../monobook, with the exception of main.css. I copy ../monobook/main.css to the newskin directory and tweak the body section to change the background. At this point, my skin is effectively a clone of MonoBook, only with a different background image that matches the rest of my site. After this I further edit NewSkin.php to insert a tiny bit of JavaScript to include my site's ads, AddThis buttons, and a tiny bit of code for paid subscribers.

This is where everything fails. If I use $wgDefaultSkin = 'newskin' in LocalSettings.php, everything bombs. If I comment that out and let it default to MonoBook, it works fine. Obviously, I'm doing something wrong modifying the skin.

At this point, however, I don't see what I *could* be doing wrong. I've run through this process several times, minimizing the changes I've been making. I left out all my custom HTML and JavaScript so the only modifications I make to NewSkin.php become changing the class name. In theory, this should work; I should get a clone of MonoBook just with a different name. Instead, I just get a 500. There must be a new step somewhere for adding a new skin that did not exist prior to 1.18.0. Before this (and including 1.17.1), I didn't need to make any further changes for my custom skin to work; MediaWiki just discovered it was there and it worked without a hitch.

I've tried looking at the skinning manual (https://www.mediawiki.org/wiki/Manual:Skinning) but it's plastered with warnings about how "this MediaWiki page is inactive and kept for historical interest". Thus I don't feel I can trust anything I might read there. I cannot simply tweak the MonoBook CSS as the changes I need to make are more invasive than just modifying CSS values.

So what has changed with the skinning functionality between <= 1.17.1 and 1.18.0 that is making my skin break? What magic incantations do I need to perform to make MediaWiki see my new skin?

Could you try running `php maintenance/rebuildLocalisationCache.php` to see if this is another in a run of errors that stem from one central issue.

"320 languages rebuilt out of 363". No obvious errors in the output. No change in overall results: Site still white-screens. Right now my custom theme is basically a clone of MonoBook with no customizations besides a new name. Here's my Apache error_log when I refresh the page:

[Fri Dec 02 11:11:53 2011] [error] [client {my-ip}] "" is not a valid magic word for "canonicalurl", referer: {domain-name}/wiki/Special:SpecialPages
[Fri Dec 02 11:11:53 2011] [error] [client {my-ip}] "" is not a valid magic word for "canonicalurle", referer: {domain-name}/wiki/Special:SpecialPages
[Fri Dec 02 11:11:53 2011] [error] [client {my-ip}] PHP Fatal error:  Call to a member function getGroup() on a non-object in {path-to-wiki}/includes/OutputPage.php on line 2958, referer: {domain-name}/wiki/Special:SpecialPages

(In reply to comment #4)
> Then I went through the task of setting back up my custom skin. Essentially
> what I do for this is to copy the MonoBook class files (MonoBook.php and
> MonoBook.deps.php) and rename them to the new skin name, then edit the main
> skin class file (we'll call it "NewSkin.php") to replace all references of
> MonoBook to NewSkin. I create a "newskin" directory and fill it with symbolic
> links to all the files in ../monobook, with the exception of main.css. I copy
> ../monobook/main.css to the newskin directory and tweak the body section to
> change the background. At this point, my skin is effectively a clone of
> MonoBook, only with a different background image that matches the rest of my
> site. After this I further edit NewSkin.php to insert a tiny bit of JavaScript
> to include my site's ads, AddThis buttons, and a tiny bit of code for paid
> subscribers.
Ok, this does seam like you're doing something wrong.

Drop the symlinks, duplicating the css like this is pointless when you're making a derivative skin.
You likely changed $out->addModuleStyles( 'skin.monobook' ); to $out->addModuleStyles( 'skin.newskin' ); without creating a new resource loader module.
We might as well make this a proper derivative of MonoBook.

Change your `extends SkinTemplate` to `extends SkinMonoBook`. You may want to add a `require_once( dirname( __FILE__ ) . '/MonoBook.php' );` to the top of your file, or rather maybe a .deps file.
You can drop the `$useHeadElement = true` if you want since it'll be inherited.

Tweak that part of the code so your entire setupSkinUserCss looks like this:
parent::setupSkinUserCss( $out );
$out->addModuleStyles( 'skin.newskin' );

In your LocalSettings.php create a new resource loader module using:
$wgResourceModules["skins.newskin"] = array(
	'styles' => array(
		"newskin/screen.css" => array( 'media' => 'screen' ),
	),
	'remoteBasePath' => &$GLOBALS['wgStylePath'],
	'localBasePath' => &$GLOBALS['wgStyleDirectory'],
);

Then create an empty 'screen.css' in a newskin/ folder in skins/ and make JUST the css you want to MonoBook there.

If you want, you can also change `extends BaseTemplate` to `extends MonoBookTemplate` and delete all the functions that you don't make modifications to.

OK, that seemed to do the trick... mostly. Everything seems to be working, including my custom code (the ads, AddThis, my customer subscriber code), with the exception of the CSS that overrides the MonoBook background with my site's background. I've got the skins/newskin/screen.css file in place containing only the body{background} change, but I'm still seeing the MonoBook background.

Any more ideas?

(In reply to comment #8)
> OK, that seemed to do the trick... mostly. Everything seems to be working,
> including my custom code (the ads, AddThis, my customer subscriber code), with
> the exception of the CSS that overrides the MonoBook background with my site's
> background. I've got the skins/newskin/screen.css file in place containing only
> the body{background} change, but I'm still seeing the MonoBook background.
> 
> Any more ideas?

Backseat debugging is excessively difficult when you have no place you can go, check for 404 errors, bad css, cascade issues, etc...
Got a url?

I've had my wiki locked down so my end users can't see it. I'll have to reopen it for you to get to it.

http://www.gpf-comics.com/wiki/

Firebug isn't giving me anything useful. AddThis is being a bit slow to load a few things, but that doesn't affect my local CSS. What I *can* see looks to be working fine (there's another custom CSS, premium2.css, that is getting loaded directly in the skin class file), but I *can't* see the the screen.css file getting loaded. (It's actual path should be /wikix/skins/gpfskin/screen.css.) Unfortunately, the way MediaWiki obscures loading some resources through load.php makes it hard to track things down.

from triage: lowering priority and removing from block list.

modules=mediawiki.legacy.commonPrint%2Cshared%7Cskins.gpfskin%2Cmonobook

It looks like your gpfskin css is being loaded before the monobook css and being overridden by the cascade.

What's the code you used for your setupSkinUserCss?

Here's what I had when you probably looked at it:

function setupSkinUserCss( OutputPage $out ) {
    parent::setupSkinUserCss( $out );
    $out->addModuleStyles( 'skins.gpfskin' );
    /* Add Premium CSS to header: */
    $out->addStyle( 'gpfskin/premium2.css', 'screen' );
}

The "gpfskin/premium2.css" reference is to a custom CSS file that applies styles to some of the custom HTML/JavaScript I mentioned previously.  This is CSS that gets used throughout my site and should have no collisions with anything within MediaWiki.

On a whim, I tried adding the following line after that "premium2.css" declaration:

    $out->addStyle( 'gpfskin/screen.css', 'screen' );

When I added that, it found the MonoBook override CSS and my background worked the way it was supposed to.  I tested it several times, commenting and uncommenting out that line and refreshing the page, and sure enough that fixed the background issue.

I guess this means it's safe to close this issue then. I'm *really* dreading my next MediaWiki upgrade now; I *hope* these changes will make upgrading my customer skin easier, but after this experience I'm going start setting aside entire weekends to MediaWiki upgrades, rather than the half an hour it's taken me for every upgrade since 1.12.

Closed INVALID per comment 13.

I think somebody forgot to actually close it :)

Closing now.

I experienced this same error on upgrading from ~1.18 (not sure exactly what version, and no time to research it now) to 1.20.2.

After spending maybe an hour tracing the problem, I determined that for some reason this line in MessagesEn.php --

	'speciale'                => array( 0,    'speciale' ),

-- was somehow not being loaded into the array, although the lines before it and after it were. If I commented out the line before it ('special' without an e), 'speciale' showed up in the list.

I next tried reversing the two lines, since it seemed like there was a problem with the 'special' line -- and at that point, the wiki loaded successfully.

Then I put the lines back in order, and the wiki loaded again.

My only theory at this point is that perhaps there was an invisible but syntactically-significant character in the 'special' line which was somehow messing with the parsing of the 'speciale' line.

I don't have time to dig further just at the moment and verify that this is a replicable problem, but I thought I should at least add a comment about this in case anyone else has run into it with 1.20.

(In reply to comment #16)

> 
> My only theory at this point is that perhaps there was an invisible but
> syntactically-significant character in the 'special' line which was somehow
> messing with the parsing of the 'speciale' line.
> 

The message files are cached. Sounds like by editing the file you purged the cached version of the file. I looked through the relavent lines in MessagesEn.php and didn't see any inapropriate non-printing characters.