Topic on Project:Support desk/Flow

I've been up and down Google for the last few hours and I'm completely stumped for this problem. I've been using PHP for years but I have no idea of MediaWiki's inner workings and this completely escapes me.

I have a Wiki running on MediaWiki 1.18 (just upgraded today to see if it would fix the problem; it did not). For a long time everything has been completely find (a glitch here, one there, nothing serious). Two days ago, a user came to me and told me that the website looked "odd". When I asked to see what he meant, he showed me a site with no formatting (except inline styles)--that is, Times New Roman, white background, etc. I thought it might be his computer only, but then a second user came forward, and I checked it on another computer of mine, and it had the same issue. Mystified as to why I did not have this error on my main computer, I cleared my cache. Lo and behold, the CSS became blank.

Using Chrome's inspect element, I found the URLs of all the loaded stylesheets (3, to be exact, all loaded from load.php), and opened them in a new tab. Everything worked--that is to say, all of the CSS printed out properly. However, when I view the same resource in Chrome's resources tab, it is blank.

Oddly, even though the JS is loaded from load.php, it is working fine.

When reloading the page with "Inspect Element" open, I get this warning: Resource interpreted as Other but transferred with MIME type undefined. However I'm not sure if this is related. (My guess is that it is not.)

• MediaWiki: 1.18.0
• PHP: 5.2.14 (cgi-fcgi)
• MySQL: 5.0.91-log

Attached are links to a few images. This issue happens in both Chrome and Firefox (other browsers untested) and on multiple computers as aforementioned.

• http://imageshack.us/photo/my-images/856/cssfail1.jpg/
• http://imageshack.us/photo/my-images/208/cssfail2.jpg/
• http://imageshack.us/photo/my-images/833/cssfail3.jpg/
• http://imageshack.us/photo/my-images/841/cssfail4.jpg/

Again, I must emphasize that this problem just started a few days ago. (The Wiki has been up since September 8th.) Except for a few additions to Vector.css, nothing has been changed. Any help or advice is appreciated. Been banging my head on my desk for hours now!

I discovered that, indeed, MIME type is related here. When I opened the site in IE and checked the dev tools, I get these errors:

SEC7113: CSS was ignored due to mime type mismatch 
load.php?debug=false&lang=en&modules=mediawiki.legacy.commonPrint%2Cshared%7Cskins.vector&only=styles&skin=vector&*
SEC7113: CSS was ignored due to mime type mismatch 
load.php?debug=false&lang=en&modules=site&only=styles&skin=vector&*
SEC7112: Script from http://********/load.php?debug=false&lang=en&modules=startup&only=scripts&skin=vector&* was blocked due to mime type mismatch 
Special:Version
SEC7112: Script from http://********/load.php?debug=false&lang=en&modules=skins.vector&only=scripts&skin=vector&* was blocked due to mime type mismatch 
Special:Version
SEC7112: Script from http://********/load.php?debug=false&lang=en&modules=site&only=scripts&skin=vector&* was blocked due to mime type mismatch 
Special:Version

How can I ensure that load.php is serving the CSS MIME type properly? In mime.types, it lists "text/css css", so I'm not sure what else I can do.

Resolved.

Appended the following to .htaccess, and the problem is resolved.

RewriteCond %{QUERY_STRING} only=styles
RewriteRule ^load.php - [QSA,E=content_type:text/css]

RewriteCond %{QUERY_STRING} only=scripts
RewriteRule ^load.php - [QSA,E=content_type:text/javascript]

<FilesMatch "load\.php">
	Header set Content-type %{content_type}e
</FilesMatch>

This does not fix the problem. Is this bug ever going to be fixed?

I have this extact same issue on an IIS install, every other page refresh results in no CSS. Can you translate this into an IIS URL Rewrite rule. I tried to save the above example in an htaccess file and import it but it doesn't like part of the E--- portion of the rule.

IIS7 on windows Server 2008 R2 and 2012 R2 results in same behavior. Been working on this for days trying to figure it out.....

Shane

Not resolved. Such work-around should not and is not required by MediaWiki.

Something else is causing this to go wrong, this may fix it for you, but I'd like for this to be further investigated.

I belive i'm getting same issue, after some clicks load.php just stops sending css and images. If i delete browser history and access the wiki if loads fine, if i reload the problems begin. I am using 1.18.1 version.

Did you try alternate browsers?

I am having the same problem after upgrading from 1.17 to 1.18.2. Everything else seems to be working fine. I don't see any errors.

I have this on my .htaccess and fix the problem: RewriteCond %{REQUEST_URI} !^/(redirect|load|texvc|index).php

I hit this problem too (1.20.3, Firefox).

Cause: conflicting document root settings seems to make load.php choke on finding its stylesheets.

1. in apache configuration file DocumentRoot "/path/to/mediawiki"
2. in LocalSettings.php wgScriptPath ="/mediawiki";

Solution: wgScriptPath = "";

Hat-Tip to someone at StackOverflow

I had this problem too. I am using Apache rewrite rules to make very short URLs.

RewriteEngine On
RewriteRule ^(images/|skins/|(api|img_auth|index|redirect)\.php) - [L]
RewriteRule ^/*$ /index.php?title=Main_Page [L,QSA]
RewriteRule ^(.+)$ /index.php?title=$1 [L,QSA]

After upgrading, there are more top-level PHP scripts that are part of MediaWiki, including load.php, which is a new script used to obtain skin CSS and images.

I added all the new top-level PHP scripts to my rewrite rule and restarted Apache.

RewriteEngine On
RewriteRule ^(images/|skins/|(api|img_auth|index|load|opensearch_desc|redirect|thumb|trackback)\.php) - [L]
RewriteRule ^/*$ /index.php?title=Main_Page [L,QSA]
RewriteRule ^(.+)$ /index.php?title=$1 [L,QSA]

This fixed my problem.

193.9.13.138's comment saved my day! I encountered the same thing: after upgrading to short URL (using a sandbox installation worked fine), the css is not loading but I can still see the page content. However, I had to add a "/" in the beginning for it to work, like this:

RewriteRule ^/(images/|skins/|(api|img_auth|index|load|opensearch_desc|redirect|thumb|trackback)\.php) - [L]

Hopefully it will help some one. BTW, 193.9.13.138's last rule

RewriteRule ^(.+)$ /index.php?title=$1 [L,QSA]

is not recommended by Mediawiki and something like the following line should be used.

RewriteRule ^/?wiki(/.*)?$ %{DOCUMENT_ROOT}/index.php [L]

Where do you add the mentioned statements?

Your webserver config file. In my case, httpd.conf

-

I do not like the way how MediaWiki supplies the CSS file. A CSS file should be static. No PHP and no RedirectRules should be necessary. I made a dirty hack to create static files. Maybe some of the developers get inspired to implement a similar feature by default: http://www.wiki-forum.de/metatag-veraendern-t354878.htm#4363428

There is also bug in PHP: https://bugs.php.net/bug.php?id=64836 that may cause this problem.

And here the Gentoo bug: https://bugs.gentoo.org/show_bug.cgi?id=467756

If your variables.less is missing some variables, the less compiler will not compile the CSS output properly, and you'll get an error like this:

/*

exception 'Exception' with message 'variable @collapsible-nav-heading-color is undefined:
failed at `ight.woff") format("woff"),` /var/lib/mediawiki/skins/vectorcatalyst/catalyst.less
on line 17' in /var/lib/mediawik/includes /libs/lessc.inc.php:3581
Stack trace:
#0 /var/lib/mediawiki/includes/libs/lessc.inc.php(2125): lessc_parser->throwError('variable @colla...', 351)
#1 /var/lib/mediawiki/includes/libs/lessc.inc.php(1880): lessc->throwError('variable @colla...')
#2 /var/lib/mediawiki/includes/libs/lessc.inc.php(1503): lessc->get('@collapsible-na...')
#3 /var/lib/mediawiki/includes/libs/lessc.inc.php(714): lessc->reduce(Array)
#4 /var/lib/mediawiki/includes/libs/lessc.inc.php(311): lessc->compileProp(Array, Object(stdClass), Object(stdClass))
#5 /var/lib/mediawiki/includes/libs/lessc.inc.php(249): lessc->compileProps(Object(stdClass), Object(stdClass))
#6 /var/lib/mediawiki/includes/libs/lessc.inc.php(223): lessc->compileCSSBlock(Object(stdClass))
#7 /var/lib/mediawiki/includes/libs/lessc.inc.php(719): lessc->compileBlock(Object(stdClass))
#8 /var/lib/mediawiki/includes/libs/lessc.inc.php(311): lessc->compileProp(Array, Object(stdClass), Object(stdClass))
#9 /var/lib/mediawiki/includes/libs/lessc.inc.php(249): lessc->compileProps(Object(stdClass), Object(stdClass))
#10 /var/lib/mediawiki/includes/libs/lessc.inc.php(223): lessc->compileCSSBlock(Object(stdClass))
#11 /var/lib/mediawiki/includes/libs/lessc.inc.php(719): lessc->compileBlock(Object(stdClass))
#12 /var/lib/mediawiki/includes/libs/lessc.inc.php(311): lessc->compileProp(Array, Object(stdClass), Object(stdClass))
#13 /var/lib/mediawiki/includes/libs/lessc.inc.php(249): lessc->compileProps(Object(stdClass), Object(stdClass))
#14 /var/lib/mediawiki/includes/libs/lessc.inc.php(223): lessc->compileCSSBlock(Object(stdClass))
#15 /var/lib/mediawiki/includes/libs/lessc.inc.php(719): lessc->compileBlock(Object(stdClass))
#16 /var/lib/mediawiki/includes/libs/lessc.inc.php(189): lessc->compileProp(Array, Object(stdClass), Object(stdClass))
#17 /var/lib/mediawiki/includes/libs/lessc.inc.php(829): lessc->compileImportedProps(Array, Object(stdClass), Object(stdClass), Object(lessc_parser), '/var/lib/mediaw...')
#18 /var/lib/mediawiki/includes/libs/lessc.inc.php(189): lessc->compileProp(Array, Object(stdClass), Object(stdClass))
#19 /var/lib/mediawiki/includes/libs/lessc.inc.php(829): lessc->compileImportedProps(Array, Object(stdClass), Object(stdClass), Object(lessc_parser), '/var/lib/mediaw...')
#20 /var/lib/mediawiki/includes/libs/lessc.inc.php(311): lessc->compileProp(Array, Object(stdClass), Object(stdClass))
#21 /var/lib/mediawiki/includes/libs/lessc.inc.php(305): lessc->compileProps(Object(stdClass), Object(stdClass))
#22 /var/lib/mediawiki/includes/libs/lessc.inc.php(220): lessc->compileRoot(Object(stdClass))
#23 /var/lib/mediawiki/includes/libs/lessc.inc.php(1927): lessc->compileBlock(Object(stdClass))
#24 /var/lib/mediawiki/includes/libs/lessc.inc.php(1950): lessc->compile('/*?** Catalyst ...', '/var/lib/mediaw...')
#25 /var/lib/mediawiki/includes/libs/lessc.inc.php(2022): lessc->compileFile('/var/lib/mediaw...')
#26 /var/lib/mediawiki/includes/resourceloader/ResourceLoaderFileModule.php(809): lessc->cachedCompile(Array)
#27 /var/lib/mediawiki/includes/resourceloader/ResourceLoaderFileModule.php(719): ResourceLoaderFileModule->compileLESSFile('/var/lib/mediaw...')
#28 /var/lib/mediawiki/includes/resourceloader/ResourceLoaderFileModule.php(692): ResourceLoaderFileModule->readStyleFile('vectorcatalyst/...', false)
#29 /var/lib/mediawiki/includes/resourceloader/ResourceLoaderFileModule.php(321): ResourceLoaderFileModule->readStyleFiles(Array, false)
#30 /var/lib/mediawiki/includes/resourceloader/ResourceLoader.php(812): ResourceLoaderFileModule->getStyles(Object(ResourceLoaderContext))
#31 /var/lib/mediawiki/includes/resourceloader/ResourceLoader.php(546): ResourceLoader->makeModuleResponse(Object(ResourceLoaderContext), Array, Array)
#32 /var/lib/mediawiki/load.php(43): ResourceLoader->respond(Object(ResourceLoaderContext))
#33 {main}
*/

To fix this, make sure you have these defined in your skin's less variables file (usually variables.less) e.g.

@collapsible-nav-heading-color: #4d4d4d;

Someone on stack exchanged fixed it by modifying $wgServer in LocalSettings.php. Changing the $wgServer from localhost to the static IP of the machine, eg:

## The protocol and server name to use in fully-qualified URLs
## $wgServer = "http://localhost";
$wgServer = "http://123.123.12.12";

Seemed to do the trick for me! This was using version 1.23.5 (latest version as of 10/30/14).

Along with the $wgServer = "http://123.123.12.12"; fix, I had to set $wgUsePathInfo = false; also

great replacing localhost with ip address worked for me

This worked for me as well!

Remember to copy the trailing semicolon.

It works only for short periods of time.

Each time I touch LocalSettings.php it starts working again.

That could be because you have a dynamic IP that changes every time you restart your router, or automatically every few hours. Register a dyndns name and use it instead of your IP.

Old question, I know, but all solutions as not equal. In my case, I was hosting a personal wiki at my home listening on port 8080 as my residential ISP blocks port 80. It worked fine within my local network, but served no styles when used from the WAN. I had to specify $wgServer = "http://my.domain.com:8080"; in /etc/mediawiki/LocalSettings.php for any external browser to find the style sheets.

(1) Use a dynamic IP service (zoneedit, e.g.) to keep your IP/domain up to date.

(2) Forward the port on which you listen (8080, e.g.) to your internal server (192.168.1.20, e.g.)

(3) Ensure the machines on your local network also resolve the domain name to the server IP internally. This can be as simple as an entry in /etc/hosts (192.168.20 my.domain.com, e.g.)

I have same problem, but none of early described silutions didnt work for me.

I upgrade my server from Fedora 24 to Fedora 25 and from this time, I cant get mediawiki to display correctly. I check all recomended settings from https://www.mediawiki.org/wiki/Manual:Errors_and_symptoms#The_wiki_appears_without_styles_applied_and_images_are_missing, i modify .htaccess, change wgScriptPath, wgserver and still the same situation. CSS was ignored due to mime type mismatch I deploy new virtual machine with clean install of Fedora 25 and install Mediawiki from Fedora repository, made basic settings for Mediawiki and I again get same results. CSS was ignored due to mime type mismatch. Can anybody advice me, how can I identify problem ? I am totaly frustrated from this situation.

So, if you open the CSS URL on your browser, can you see the CSS rules there? Is there any error message like a PHP warning? What content-type header is returned for that URL?