Last modified: 2013-10-23 18:17:18 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 T34762, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 32762 - invalid magic word errors on canonicalurl after upgrade to 1.18
invalid magic word errors on canonicalurl after upgrade to 1.18
Status: RESOLVED INVALID
Product: MediaWiki
Classification: Unclassified
Installer (Other open bugs)
1.18.x
All All
: Lowest normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-12-02 00:39 UTC by Mark A. Hershberger
Modified: 2013-10-23 18:17 UTC (History)
8 users (show)

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


Attachments

Description Mark A. Hershberger 2011-12-02 00:39:30 UTC
From http://permalink.gmane.org/gmane.org.wikimedia.mediawiki/38415

I extracted 1.18 into a clean directory, copied over LocalSettings.php and my images folder (I have no extensions installed so I skipped that), and recreated my customized MonoBook skin.  (For the skin, I copied the core MonoBook class file and made my tweaks to insert ads, AddThis, etc.  For the monobook resource folder, I use symbolic links to all the files except the main.css, which I copied over and made one tweak to the background image.)  However, my wiki is still white-screening with the following errors in the Apache log:

[Tue Nov 29 13:09:09 2011] [error] [client {my-ip}] "" is not a valid magic word for "canonicalurl", referer: {domain-name}/wiki/Special:SpecialPages
[Tue Nov 29 13:09:09 2011] [error] [client {my-ip}] "" is not a valid magic word for "canonicalurle", referer: {domain-name}/wiki/Special:SpecialPages
[Tue Nov 29 13:09:09 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
[Tue Nov 29 13:10:07 2011] [error] [client {my-ip}] "" is not a valid magic word for "canonicalurl"
[Tue Nov 29 13:10:07 2011] [error] [client {my-ip}] "" is not a valid magic word for "canonicalurle"
[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

I'm not sure if this is relevant, but I use the "short URLs" setup using
Apache mod_rewrite.  The relative URL /wiki/Special:SpecialPages worked
well enough under 1.17.1 and below.
Comment 1 Bawolff (Brian Wolff) 2011-12-02 05:47:40 UTC
>[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.
Comment 2 Jeffrey T. Darlington 2011-12-02 11:33:55 UTC
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.
Comment 3 Bawolff (Brian Wolff) 2011-12-02 14:33:38 UTC
(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;
Comment 4 Jeffrey T. Darlington 2011-12-02 15:50:31 UTC
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?
Comment 5 Daniel Friesen 2011-12-02 16:06:28 UTC
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.
Comment 6 Jeffrey T. Darlington 2011-12-02 16:15:43 UTC
"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
Comment 7 Daniel Friesen 2011-12-02 16:59:29 UTC
(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.
Comment 8 Jeffrey T. Darlington 2011-12-02 17:44:01 UTC
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?
Comment 9 Daniel Friesen 2011-12-02 18:29:40 UTC
(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?
Comment 10 Jeffrey T. Darlington 2011-12-02 18:38:33 UTC
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.
Comment 11 Mark A. Hershberger 2011-12-02 21:46:27 UTC
from triage: lowering priority and removing from block list.
Comment 12 Daniel Friesen 2011-12-02 23:51:01 UTC
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?
Comment 13 Jeffrey T. Darlington 2011-12-03 00:25:59 UTC
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.
Comment 14 Siebrand Mazeland 2012-06-13 17:32:42 UTC
Closed INVALID per comment 13.
Comment 15 Bartosz Dziewoński 2012-10-20 18:47:04 UTC
I think somebody forgot to actually close it :)

Closing now.
Comment 16 Woozle 2012-12-13 15:09:10 UTC
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.
Comment 17 Bawolff (Brian Wolff) 2012-12-13 15:47:33 UTC
(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.

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


Navigation
Links