Page MenuHomePhabricator

MW 1.26.0: Vector stylesheet doesn't load if temporary directory is unwritable
Closed, ResolvedPublic

Description

I just did a fresh installation of MediaWiki and used the new 1.26.0. The installer didn't look the way I was used to, but everything went smoothly and there were no errors or warnings.
Once LocalSettings.php was created, I logged in and everything still looked wrong; almost as though there were no CSS being loaded, but not quite. I checked via Firebug and CSS is indeed being loaded.
I went into the preferences and tried the other three themes and they all displayed correctly. I am using a Firefox browser on Mint with a freshly-cleared cache, in case it is some kindof browser issue.
I am attaching a screenshot of how Vector currently looks for me.

Here's the error that the console shows:

GCI task: https://codein.withgoogle.com/tasks/6298836838383616/

Event Timeline

Ryan7273 created this task.Dec 1 2015, 5:42 AM
Ryan7273 raised the priority of this task from to High.
Ryan7273 updated the task description. (Show Details)
Ryan7273 added a project: Vector.
Ryan7273 added a subscriber: Ryan7273.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptDec 1 2015, 5:42 AM
Aklapper raised the priority of this task from High to Needs Triage.Dec 1 2015, 11:37 AM

Hi @Ryan7273, thanks for taking the time to report this!

Has this been brought up on https://www.mediawiki.org/wiki/Project:Support_desk already?

Restricted Application added a subscriber: StudiesWorld. · View Herald TranscriptDec 1 2015, 11:37 AM
Aklapper renamed this task from MediaWiki 1.26.0 Vector not displaying. to MW 1.26.0: Vector not displaying but other skins load correctly.Dec 1 2015, 11:37 AM
Aklapper set Security to None.

It looks like it or a similar problem has been posted there since I posted this. They don't seem to have made it very far in regards to identifying what's wrong.
https://www.mediawiki.org/wiki/Topic:Stoyg4hvurar8zvj

As suggested by the Support Desk thread, I looked at https://www.mediawiki.org/wiki/Manual:Errors_and_symptoms#The_wiki_appears_without_styles_applied_and_images_are_missing.
Everything mentioned checks out as correct.

I forgot to tell you in the original ticket that I installed 1.25.3 on November 23 on the same server without running into this problem. That install was completely removed before starting this one, because there was no content yet.

Following the next bit of advice in the thread, I looked at URLs containing "only=styles" and did see errors.

Less_Exception_Parser: Less.php cache directory couldn't be created: /tmp in ..../vendor/oyejorge/less.php/lib/Less/Parser.php:441

I am on a shared hosting environment, so I created a new directory with chmod 777 and pointed $wgTmpDirectory to it. The error changed to point to the new directory. Unsure why it wouldn't be able to create something when it has full permissions.

Interestingly, I looked at the same file when using the MonoBook skin and I see the identical errors. This despite the site loading correctly. Unsure if it is actually part of this issue.

Krinkle added a subscriber: Krinkle.Dec 1 2015, 3:07 PM
Less_Exception_Parser: Less.php cache directory couldn't be created: /tmp in ..../vendor/oyejorge/less.php/lib/Less/Parser.php:441

I am on a shared hosting environment, so I created a new directory with chmod 777 and pointed $wgTmpDirectory to it.

If the error you pasted here is in fact the error you got, then it would seem the directory you configured in $wgTmpDirectory is not being used. The permission are probably fine, but Less Parser is using the default /tmp (at the root of your hosting space) instead of the directory you configured.

Ryan7273 added a comment.EditedDec 1 2015, 3:21 PM

That was the error I received before setting $wgTmpDirectory. Afterwards, it changed to

Less_Exception_Parser: Less.php cache directory couldn't be created: /home/thegymnc/wm_tmp in ..../vendor/oyejorge/less.php/lib/Less/Parser.php:441

which is the directory I created for it.

Apologies for the confusion and thanks for the quick response.

matmarex added a subscriber: ori.Dec 1 2015, 5:00 PM

I am experiencing the same issue. If there is anything I can do or add, please let me know.

Thanks
Mike

Jdlrobson triaged this task as Normal priority.Dec 2 2015, 5:58 PM
Jdlrobson added a subscriber: Jdlrobson.

Another report: Topic:Su6n4ru38vpr8xe0, fails in Windows, other skins work fine

All seem related to 1.26 release

saper added a subscriber: saper.EditedDec 15 2015, 9:32 AM

@Ryan7273 can you check the output of <?php phpinfo(); Is there some open_basedir or some other restriction in place?

There are open_basedir restrictions in place, but the root of the wikimedia install is included. Which other restrictions would you like me to check?

saper added a comment.EditedDec 19 2015, 9:25 PM

Looks like a perfect candidate to be a reason.

open_basedir is tricky, I haven't yet had time to figure out all the things that need to go in there. Is your $wgCacheDirectory in you open_basedir as well? I think all base dir violations should be nicely logged.
This might be also an explanation why Vector does not work - it uses LESS for stylesheets (but not only vector). (T121519 is related a bit)

The LESS parser may be using /tmp to store temporary data to build the stylesheets, which may not be in open_basedir

Check this post to get a useful error message that may give the reason of the failure.

Icerat added a subscriber: Icerat.Jan 10 2016, 1:47 PM

Same issue, 1.26 on IIS8 with PHP5.6. I have open_basedir disabled. MW is successfully creating a file I10n_cache-en.cdb in the cache directory, so that doesn't seem to be the issue.

Same issue, 1.26 on IIS8 with PHP5.6. I have open_basedir disabled. MW is successfully creating a file I10n_cache-en.cdb in the cache directory, so that doesn't seem to be the issue.

Can you check what's the PHP's temp directory (it's usually C:\WINDOWS\TEMP), and be sure MediaWiki has permissions to write on it? http://forums.iis.net/post/1910468.aspx

It's windows\temp and has write permissions. file uploads are working, so don't think that's the problem. Where can I found out more about the less implementation, since that seems to be where it's happened? Trying to implement a vector-based skin (metro) and it does the same thing not surprisingly.

Icerat added a comment.EditedJan 10 2016, 7:22 PM

scratch that about uploads working - they're not any more -

Could not create directory "mwstore://local-backend/local-public/7/72"

checking all the permissions .....

ETA: uploads permissions fixed, still no Vector. Running procmon to see if I can find any problems creating less files

Icerat added a comment.EditedJan 10 2016, 8:30 PM

As others reported, chrome/edge console reports the following error -

Internal error

Internal error

Problematic modules: {
    "startup": "error"
}
load.php (10,39)

However I note it appears with Monobook as well, and it appears to load fine.

I've been tracking file access with ProcMon and there's no ACCESS DENIED errors occurring, so I don't think it's a simple write permission problem.

Checking each of the CSS files loaded in the generated HTML page, the following fail -

/load.php?debug=true&lang=en&modules=mediawiki.sectionAnchor&only=styles&skin=vector

/*
Internal error
Problematic modules: {

"mediawiki.sectionAnchor": "error"

}
*/

/load.php?debug=true&lang=en&modules=skins.vector.styles.responsive&only=styles&skin=vector

/*
Internal error
Problematic modules: {

"skins.vector.styles.responsive": "error"

}
*/

/load.php?debug=true&lang=en&modules=startup&only=scripts&skin=vector

/*
Internal error

Internal error

Problematic modules: {
    "startup": "error"
}
*/
if (window.console && console.error) {console.error("Internal error\n\nInternal error\n\nProblematic modules: {\n    \"startup\": \"error\"\n}");}

FYI, a completely fresh install is working fine, so clearly this is either (a) a clash with something existing loaded in localsettings.php or (b) a problem in the upgrade process.

Ciencia_Al_Poder added a comment.EditedJan 15 2016, 10:46 AM

Another report on Windows server: Topic:Swgv71jb3lxl4huq. Cause was permissions on C:\Windows\TEMP

Sorry for the delay in replying. I had reverted back to a previous version to avoid the bug and had to re-install to try things out.

A fresh installation of 1.26.2 still presents the problem I reported. I am on Linux, so the Windows-related suggestions do not apply.

The problem is indeed related to my open_basedir. When I commented it out in the php.ini, everything seems to work perfectly. This is not a good long-term solution, but I plan to spend the next hour or so figuring out exactly which of the directories suggested above need to be included. I'll report back when I know more.

The solution is the add /tmp to the open_basedir. As I am going to be deploying to a shared hosting environment, I would strongly prefer NOT to do that long-term. Any chance I can designate a different location for the temp directory?

The solution is the add /tmp to the open_basedir. As I am going to be deploying to a shared hosting environment, I would strongly prefer NOT to do that long-term. Any chance I can designate a different location for the temp directory?

That's what I found in the code:

$parser->SetCacheDir( $config->get( 'CacheDirectory' ) ?: wfTempDir() );

So basically, set up $wgCacheDirectory to a folder writable by MediaWiki. That, of course, is not an option during the installer.

That said, not having a working temp dir could break applications. Be sure the TMPDIR env var is set correctly (on unix systems) and see also this stack oferflow question that also tells how to override it in a PHP script.

ananayarora raised the priority of this task from Normal to High.Jan 17 2016, 11:53 AM
Victorbarbu closed this task as Invalid.Jan 17 2016, 12:19 PM
Victorbarbu claimed this task.
Victorbarbu added a subscriber: Victorbarbu.

I downloaded the MediaWIki 1.26.2 from mediawiki.org. I completed the normal installation process and my Wiki works perfectly. (see the screenshot).

I think this problem comes from simply mis-configuring the wiki.

Victorbarbu reopened this task as Open.Jan 17 2016, 12:24 PM

Marking it back as "Open" so people don't get offended.

Looking at the reports, I'd also say the cause is a misconfiguration of PHP, either because of open_basedir restriction not including the default temp directory, or permission issue on the temp directory. If that's true, this task could be closed as invalid.

Still, maybe there's something MediaWiki could do to detect this situation and give a reasonable error message about the problem, or make the LESS parser work without cache at all, etc. For example, the installer may detect this issue on the prerequisites check and warn the user about not having access to the default PHP directory, because $wgCacheDirectory can't be changed during the installer.

Still, maybe there's something MediaWiki could do to detect this situation and give a reasonable error message about the problem, or make the LESS parser work without cache at all, etc. For example, the installer may detect this issue on the prerequisites check and warn the user about not having access to the default PHP directory, because $wgCacheDirectory can't be changed during the installer.

I would strongly suggest to add such an error message, so the user knows what to do, or has, at least, some information to google a solution :)

So basically, set up $wgCacheDirectory to a folder writable by MediaWiki. That, of course, is not an option during the installer.

I can change open_basedir during installation and then use this afterwards. This is a good solution I can live with.

I would strongly suggest to add such an error message, so the user knows what to do, or has, at least, some information to google a solution :)

Since my problem was caused by a PHP configuration issue, i would agree with either a useful error message or a note in the installation instructions or FAQ.

Aklapper removed Victorbarbu as the assignee of this task.Jan 17 2016, 11:09 PM
Aklapper lowered the priority of this task from High to Normal.

Hi everyone, The solution I've come up is to create a directory 'less-cache' in /includes/resourceloader/ and create /includes/resourceloader/less-cache so that everytime the less.php parser needs to store cache, it can. :)

Nemo_bis removed a subscriber: Nemo_bis.Jan 19 2016, 8:56 PM
Reedy added a comment.Jan 19 2016, 9:08 PM

Hi everyone, The solution I've come up is to create a directory 'less-cache' in /includes/resourceloader/ and create /includes/resourceloader/less-cache so that everytime the less.php parser needs to store cache, it can. :)

I really wouldn't put it there. It's somewhere like /tmp or in the cache folder in mw

@Reedy I can't find a way to get the mediawiki cache directory

$parser->SetCacheDir( __DIR__ . "/../../cache" );

ain't working. Any way I could refer to it? For now I'm using this -

$parser->SetCacheDir(  __DIR__."/less-cache" );

and it's working perfectly fine

Change 265132 had a related patch set uploaded (by Ananay):
MW 1.26.0: Vector not displaying but other skins load correctly

https://gerrit.wikimedia.org/r/265132

@Reedy, this was pretty easy to fix. Just removed the SetCacheDir line, so it Less.php to use it's own default config for the Cache Directory. This seems to be working fine. :) https://gerrit.wikimedia.org/r/#/c/265132/

@Reedy, this was pretty easy to fix. Just removed the SetCacheDir line, so it Less.php to use it's own default config for the Cache Directory. This seems to be working fine. :) https://gerrit.wikimedia.org/r/#/c/265132/

What if people have file permissions locked down?

ananayarora added a comment.EditedJan 19 2016, 10:01 PM

@Reedy, tested this on my AWS Instance which had the same problem. I had file permissions locked down too, removed this line, worked :)

Jenkins-bot's Unit Testing should confirm it

What if the webserver user can't write to the folder?

SELinux?

@Reedy, Modified my previous comment.

Also, When I had setCacheDir() in place and create less-cache, Jenkins-bot failed it's Unit Testing. Remove that line in the code, Jenkins-bot gave a green tick

Here's the Patch Set. Please review this :: https://gerrit.wikimedia.org/r/#/c/265132/

Jdlrobson lowered the priority of this task from Normal to Lowest.Jan 20 2016, 7:59 PM
Jdlrobson added a subscriber: Jdlrobson.
Krinkle renamed this task from MW 1.26.0: Vector not displaying but other skins load correctly to MW 1.26.0: Vector stylesheet doesn't load if temporary directory is unwritable.Jan 20 2016, 8:56 PM
Krinkle raised the priority of this task from Lowest to Low.

Change 265132 merged by jenkins-bot:
Improve wfTempDir() fallback sequence

https://gerrit.wikimedia.org/r/265132

ananayarora closed this task as Resolved.Jan 21 2016, 4:00 PM
ananayarora added a subscriber: tstarling.

Thank you @tstarling @Krinkle @Florian for your support :)

I like how this was recognized as a bug in the Vector Skin, and then ended up being fixed as a major problem in MediaWiki.