Jump to content
  • 0

No Styles after upgrade from 1.26 to 1.29

Guest Michale Wrenn


Guest Michale Wrenn

Perfect timing for this forum.

I just performed an upgrade of our mediawiki from 1.26 to 1.29.1. I followed the instruction as documented on the Mediawiki site. I downloaded 1.29 into its own folder, performed an upgrade of php to 5.6, backed up the database, then ran the update.php. All seem to go well until the site was reloaded. When the main page loaded it was devoid of any styling. I then reverted back to the 1.26 install folder, reloaded the page and verified that the 1.26 folder would still load correctly and it did.

Assuming now that I had done something wrong when copying over the 1.26 files and folders to the 1.29 folder, I attempted a clean install of 1.29. The install proceeded as expected, however after completing the install the main page loaded without any styles applied.

I have turned on debugging using the following 

$wgShowExceptionDetails = true; 
$wgDebugToolbar = true; 
$wgShowDebug = true; 
$wgDevelopmentWarnings = true;
$wgDebugLogFile = "/tmp/{$wgSitename}-debug.log";

I am unable to find anything that stands out in the debug info or the debug log. I've also noted that after doing the install of 1.29 and the database was updated, that now the 1.26 install is exhibiting the same problem of not showing any styles.

Any and all helpful suggestions welcomed.

Many thanks in advance,

Michael Wrenn

Link to comment
Share on other sites

8 answers to this question

Recommended Posts

  • 1

It looks like your .htaccess RewriteRule is what is blocking it. I highly recommend disabling or revisiting that rule as it will cause issues with the wiki itself as well -- you will be unable to view or edit any page with a . in it followed by letters. What is that rule supposed to be protecting against?

To be clear: it isn't failing to find the files. You are getting 403 Forbidden back. Your RewriteCond is checking for a query string containing a period followed by anything EXCEPT a bunch of special characters. So having something like ".styles" or ".css" in the query string will trip it. You can verify this yourself by attempting to view the page http://wiki.tri-sen.local/index.php?title=MediaWiki:Common.css -- your browser will display a 403 Forbidden page there as well.

Edited by Skizzerz (see edit history)
  • Thanks 1
Link to comment
Share on other sites

  • 0

So this only happens on Main Page? The error console of the browser should tell you more details. Try to comment out the "$wgServer" configuration parameter and look where you go from there. Moreover is "$wgStylePath" pointing to where it should. "$wgResourceBasePath" may be a cause too.


Link to comment
Share on other sites

  • 0


Thanks for the response. This is not a main page issue only. It plagues the entire application.

I've tried your suggestion of commenting out "$wrgserver" however this did not make any changes. I've searched the new LocalSettings.php file and "$wgStylePath" is not found. I was able to find it in the old 1.26 file however. "$wgResourceBasePath" is set equal to "$wgScriptPath". And "$wgScriptPath" is set to empty quotes.

I've found some info on the MW site concerning short URLs which describe an issue similar to mine. I'm going to work through that write up and see what I can figure out. If you have any other suggestions feel free to post them.

Also note that I was not able to see anything in the browser console that indicates a problem.

Edited by Michael Wrenn (see edit history)
Link to comment
Share on other sites

  • 0

Can you please let us know the value of every setting in LocalSettings.php that has the word 'Path' or 'Directory' in it? For example: $wgScriptPath, $wgStylePath, $wgArticlePath, etc.

Are you using pretty URLs/short URLs in your wiki? If so, can you please post the URL rewrite-related contents of your .htaccess file (assuming apache)?

In your browser, open up the dev tools (usually by pressing F12). Go to the network tab and then refresh the site with ?debug=1 added to the end of the URL (or &debug=1 if the URL already has a '?' in it). For example: http://example.com/wiki/Pagename?debug=1 or http://example.com/w/index.php?title=Pagename&debug=1. Look for errors with load.php, and let us know what type of error you are seeing (403, 404, 500, etc.).

Link to comment
Share on other sites

  • 0
$wgScriptPath = "";
$wgResourceBasePath = $wgScriptPath;
$wgArticlePath (Does not exist)

I am not using the short URLs.

The .htaccess file in the root contains the following:

# Protect against bug 28235
<IfModule rewrite_module>
	RewriteEngine On
	RewriteCond %{QUERY_STRING} \.[^\\/:*?\x22<>|%]+(#|\?|$) [nocase]
	RewriteRule . - [forbidden]

I've attached a screen capture of the debug screen. As expected it is failing attempting to find the css files. 


Link to comment
Share on other sites

  • 0

You nailed it @Skizzerz. I have no idea where that htaccess file came from. Had to have been created by my predecessor. I was under the impression that it was being created with the default install because it was alway in the directory each time I would wipe it and recreate it. It looks like the rm -rf command was not deleting that file. Now that it's gone the main page and login are working as expected. Unfortunately, the other wiki pages are now not loading at all. But that's an unrelated issue.

Thank you very much for your assistance, and I sure hope this forum takes off. This is really a much better platform for user support.

All the best,


Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.