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.

In T119934#1841477, @Ryan7273 wrote:

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.

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.

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

Thanks
Mike

Wondering if https://www.mediawiki.org/wiki/Topic:Stvdbhcbttk5aa9d is the same issue.

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

All seem related to 1.26 release

@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?

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.

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.

In T119934#1923356, @Icerat wrote:

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.

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

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.

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?

In T119934#1938014, @Ryan7273 wrote:

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.

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.

In T119934#1939690, @Ciencia_Al_Poder wrote:

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.

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

In T119934#1945578, @ananayarora wrote:

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/

In T119934#1945873, @ananayarora wrote:

@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?

@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/

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

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