No Styles after upgrade from 1.26 to 1.29

[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

[Skizzerz]

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 November 9, 2017 by Skizzerz (see edit history)

[kghbln]

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.

 

[Michael Wrenn]

@kghbln

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 November 9, 2017 by Michael Wrenn (see edit history)

[Skizzerz]

Is your wiki public? If so, can you please link to it?

[Michael Wrenn]

Sorry, it's currently private hosting documents for our department. My plan is to make it public once all the bugs are worked out and all the docs are populated.

[Skizzerz]

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.).

[Michael Wrenn]

$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]
</IfModule>

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

[Michael Wrenn]

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,

Michael