Topic on Project:Support desk

my custom skin disappeared after upgrade to 1.20

20
85.229.192.213 (talkcontribs)

MediaWiki 1.20.2

PHP 5.3.8 (cgi-fcgi)

MySQL 5.0.51b-community-nt

Server: IIS

  • Upgraded from 1.15 to 1.20.2
  • Copied existing skins folder to the new folder.
  • My customized skin disappeared...looks like monobook replaced it.
  • Clicking preferences link gets 500 error.
  • $wgDefaultSkin is correct in localSettings (the name is claysterweb, that is the name of a folder within the Skins folder).
  • The ClaysterWeb.php file is within the Skins/claysterweb folder.
  • Placed requirement in localSettings: require_once( "$IP/skins/claysterweb/ClaysterWeb.php");
  • Tried copying he ClaysterWeb.php file to the Skins folder. This broke login.

Can anyone advise me? Thank you very much.

Jeff Freund

88.130.121.154 (talkcontribs)

Hi Jeff,

normally a skin does not have to be called with require_once(); in LocalSettings.php. Remove that line again. The PHP file of the skin itself must be located in the folder skins/ directly (not in a subfolder like skins/claysterweb).

What is the exact error message, which you get, when you place the file in the skins folder? You most likely have to do some adjustments to make the skin work with MW 1.20.

E.g. to be able to use the new resource loader, you have to set $wgResourceModules just as it is done e.g. for Vector in resources/Ressources.php.

And you will have to update the skin's PHP file; there might well be some functions, which are used in your version, but which are no longer there in MW 1.20.

Without more information about the error 500 it is hard to say, if it is related to the skin. Check the error log to see the actual error message.

85.229.192.213 (talkcontribs)

Hi...thank you very much for responding...here's what I did/got:

  • Removed line from requires
  • Put clayster.php in Skins folder directly
  • Ran update php in maintenance folder
  • Tried login
  • Got 500 error:
    • MODULE_SET_RESPONSE_ERROR_STATUS
    • ModuleName FastCgiModule
    • Notification 128
    • HttpStatus 500
    • HttpReason MediaWiki exception
    • HttpSubStatus 0
    • ErrorCode 0
    • ConfigExceptionInfo
    • Notification EXECUTE_REQUEST_HANDLER
    • ErrorCode The operation completed successfully. (0x0)

Does that give you the info you need to help me?? PS: Login is restored if I remove the PHP file of the skin from the Skins folder. Thanks again Jeff

MarkAHershberger (talkcontribs)

Does MW work if you don't log in? What does your error log show?

85.229.192.213 (talkcontribs)

What do mean "work if you don't login"...if I try to change pages after placing the PHP file of the skin in Skins folder, I get the 500 error logged as you see above...without the skin.php file...it all works fine but of course I can't get the custom skin. Thanks, Jeff

MarkAHershberger (talkcontribs)

What does your error log show?

Would you mind posting the source of your skin somewhere (not here)? Maybe pastebin or something?

85.229.192.213 (talkcontribs)

Hi mark, ...the IIS error log shows only what you see posted above...not mush specifically...unfortunately I cannot share the source of the wiki. I know only that the FastCgiModule handles php requests. Unless you mean the actual skin.php file...I can place that somewhere (here?).

MarkAHershberger (talkcontribs)
85.229.192.213 (talkcontribs)

Great idea Mark...I just put it on pastebin...name is Jeff's skin.php file. Would be wonderful to understand what needs to be updated. Thank you.

MarkAHershberger (talkcontribs)

You could also put it in a sandbox page here, if you wanted.

85.229.192.213 (talkcontribs)

Mark...I Placed $wgShowExceptionDetails = true; at bottom of localSettings and got a more in depth trace when I tried the broken login (with Skin.php file in Skins folder) I posted the trace here (jeff's error trace): http://pastebin.com/D5ELZKNF Hope that helps. Thanks again, Jeff

88.130.121.154 (talkcontribs)

One of the problems you have is that "tooltipAndAccesskey" no longer exists as a method of the Skin class.

Replacing it with tooltipAndAccesskeyAttribs should work.

85.229.192.213 (talkcontribs)

Great. I'll try it tomorrow...I'm on European time and must get to bed... Is there a way for me to check the components of the php file myself to know what is out of date? can't thank you enough for all the help.

MarkAHershberger (talkcontribs)

I don't know of an automated tool to check all the problems, but -- in addition to the tooltipAndAccesskeyAttribs difference -- I have had to add the following my LocalSettiings.php:

$wgValidSkinNames['clayster'] = "Clayster";
$wgAutoLoadClasses['SkinClayster'] = "$IP/skins/Clayster.php";
$wgDefaultSkin = 'clayster';

Note that I also had to change instances of "claysterweb" to "clayster".

I'm still seeing logging messages like

Class SkinClayster not found; skipped loading

but at least the login page is working.

85.229.192.213 (talkcontribs)

Hi mark...here's what I have tried so far:

  • Tried changing $wgDefaultSkin = 'clayster'; to $wgDefaultSkin = 'claysterweb'; broke login.
  • Changed the name of ClaysterWeb.php to clayster.php…logon is fine (with $wgDefaultSkin = 'clayster';)
  • Changed the name of ClaysterWeb folder to clayster …logon is fine (with $wgDefaultSkin = 'clayster'; and ClaysterWeb.php as clayster.php)
  • Changed the name of ClaysterWeb.php (in skins/clayster folder) to clayster.php…logon is fine (with $wgDefaultSkin = 'clayster';)
  • substituted $wgDefaultSkin = 'clayster'; for $wgDefaultSkin = 'claysterweb'; login was fine but still didn’t get the custom skin up.
  • $wgValidSkinNames['clayster'] = "Clayster”
  • $wgAutoLoadClasses['SkinClayster'] = "$IP/skins/Clayster.php";
  • The 2 above break login with/without ClaysterWeb.php directly in skins folder so I tried them with small letter C’s (after changing ClaysterWeb.php to clayster.php)…login was fine but still didn’t get the custom skin up.
  • Preferences page is now restored… but I don’t know at what point that happened.

I'm wondering two thigs at this point:

  1. The Main.css file is using Google fonts...perhaps this is incompatible??
  2. Perhaps I should simply start again with the monobook skin and re-make the custom skin...I would guess the monobook skin with the 1.2 installation would be correctly upgraded with the installation...yes??

Thanks for all the attention, Jeff

88.130.81.187 (talkcontribs)

When you overwrote the old files with the new ones during upgrading, you might still have old unneeded files in your wiki folder. If you want to start the skin over new, you should take the skin files out of the tar archive, which contains the source code of the new MediaWiki version. If you instead put the new skin files into a new, empty folder, then the skin should not be poluted by unneeded bogus files.

MarkAHershberger (talkcontribs)
Reply to "my custom skin disappeared after upgrade to 1.20"