Thanks for taking the time to report this!

What does "1.19+" mean? With which exact version(s) (see the "Special:Version" page) did you test this?

As written in http://www.mediawiki.org/wiki/Thread:Talk:MediaWiki_1.19/Thumbnails_didn%27t_work_since_Update_to_1.19 this should be covered by bug 36475 already?

sgaudette wrote:

I think the problem begin at mediawiki 1.19 version and still there at 1.20.2
.Each new version i corrected the file.

Je croix que le problème à commencer à la version 1.19 et le problème est toujours là à la version 1.20.2 . À chaque version j'ai corrigé le fichier.

Does this happen with any image file?
What are the exact steps (click by click) to reproduce the error?

I have the same problem under MediaWiki 1.20.2. I did not have this problem before I upgraded the wiki from MediaWiki 1.19.2. This happens to only a small subset of the images on the wiki. Some of the problematic images are local while others are hosted on a foreign repository. I cannot determine a common denominator between the images that have problems. Applying the fix described above corrects the problem for me. From a web search, this appears to be a common problem.

(In reply to comment #4)

This happens to only a small subset of the images on the wiki.

Could you paste some filenames of such images here, if possible?

ingo wrote:

I can only add that it also broke one of our wikis with the upgrade to 1.20.2 (from 1.19.x, forgot the exact one).
Interestingly we have 3 wikis sharing the same sources, just with different cache/image directories.
Permissions are all the same on each of them though.
You can see the error on http://community.kde.org/index.php?title=Special:ListFiles, so it affects a lot of the images.

ingo wrote:

After fiddling with several patches that can be found over the net, this one seems to have helped from http://www.mediawiki.org/wiki/Thread:Talk:MediaWiki_1.19/Thumbnails_didn%27t_work_since_Update_to_1.19:

Replace function wfTempDir() with

function wfTempDir() {

foreach( array( 'TMPDIR', 'TMP', 'TEMP' ) as $var ) {
        $tmp = getenv( $var );
        if( $tmp && file_exists( $tmp ) && is_dir( $tmp ) && is_writable( $tmp ) ) {
                return $tmp;
        }
}
if (ini_get('upload_tmp_dir')!==false) {
        $tmp = ini_get('upload_tmp_dir');
        if( $tmp && file_exists( $tmp ) && is_dir( $tmp ) && is_writable( $tmp ) ) {
                return $tmp;
        }
 
}
if( function_exists( 'sys_get_temp_dir' ) ) {
        $tmp = sys_get_temp_dir();
        if( $tmp && file_exists( $tmp ) && is_dir( $tmp ) && is_writable( $tmp ) ) {
                return $tmp;
        }
}
# Usual defaults
return wfIsWindows() ? 'C:\Windows\Temp' : '/tmp';

}

Even though this was meant for 1.19 (where i never had that problem) it works for 1.20.2 as well.

-> NEW major per above.

ingo wrote:

Some additional information:
Made some debugging on the original function, like:

if ( $wgTmpDirectory !== false ) {

		var_dump($wgTmpDirectory);
            return $wgTmpDirectory;

}

This showed me paths like "<installpath>/images.community/tmp" or "<installpath>/images.techbase/tmp" (for another wiki). For some reason this directory doesn't exist for that certain wiki. It does for the others though. community.kde.org does habe images.community/temp, same for the others, but the others also have the images.xxx/tmp directory.

Additionally, none of the wikis do have $wgTmpDirectory set, so it obviously falls back to the default.

Last change to wfTempDir() was 99fdc6e838d4c7f6a7135a06b58d0bb232ca611c by Mark to fix bug 24985, hence CC'ing him, and Chad.

Mark / Chad: Any comments on above applied code changes?

I haven't had a chance to look at it yet, but this bug has been an open tab in my browser for a few days. I do plan to look at it.

This looks like something we should fix in the installer -- make sure the tmp directory exists.

$wgTmpDirectory default to 'false' in includes/DefaultSettings.php.

Then LocalSettings.php lets you override it.

Then Setup.php is invoked, if at that stage $wgTmpDirectory is still false, we call wfTmpDir(). This attempt to find a temp directory as defined by the environment variables TMPDIR, TMP or TEMP. If any are existent writable directory, they are used, else we fallback to PHP sys_get_temp_dir().

That is for the logic.

To debug the issue, can you look at your LocalSettings.php and find out whether there is a $wgTmpDirectory variable defined there ?

Then I would need more details. You can run commands using php maintenance/eval.php, at the prompt enter the following commands and paste us the result:

var_dump( wfTempDir() );
var_dump( $wgTmpDirectory() );
var_dump( array_map( "getenv", array( 'TMPDIR', 'TMP', 'TEMP' ) ) );
var_dump( sys_get_temp_dir() );
var_dump( file_exists( wfTempDir() ) );
var_dump( is_dir( wfTempDir() ) );
var_dump( is_writable( wfTempDir() ) );

That would give us all the informations we need to actually debug your issue.

I suspect one of the environment (TMPDIR, TMP or TEMP) is set to a directory which is NOT writable by your webserver. In such a case, you have to set $wgTmpDirectory in your LocalSettings.php to a directory writable by your webserver.

I agree with hexmode. The installer should definitely try to write something to the temp ditectory and complain loudly/let the user override if it cannot. (To be honest im surprised it doesnt already)

(In reply to comment #14)

I agree with hexmode. The installer should definitely try to write something
to the temp ditectory and complain loudly/let the user override if it cannot.
(To be honest im surprised it doesnt already)

This should be a new bug (enhancement request)

ingo wrote:

Can't speak for for the bug opener or other pre commenters, but i can try to give some feedback from my POV.
Even though the problem was already fixed (simply adding the tmp dir and making it writable solved it), i am able to replicate the situation in our wiki sandbox. The images dir is empty and writable by webserver user.

The debug output(note, there was a typo, $wgTmpDirectory is a var, not a function):

var_dump( wfTempDir() );

string(51) "/<path_to_install>/mediawiki_git/images.sandbox/tmp"

var_dump( $wgTmpDirectory );

string(51) "/<path_to_install>/mediawiki_git/images.sandbox/tmp"

var_dump( array_map( "getenv", array( 'TMPDIR', 'TMP', 'TEMP' ) ) );

array(3) {

[0]=>
bool(false)
[1]=>
bool(false)
[2]=>
bool(false)

}

var_dump( sys_get_temp_dir() );

string(4) "/tmp"

var_dump( file_exists( wfTempDir() ) );

bool(false)

var_dump( is_dir( wfTempDir() ) );

bool(false)

var_dump( is_writable( wfTempDir() ) );

bool(false)

This made me aware that wgTmpDirectory indeed must be set, and it is, in our Commonsettings file for all wikis($wgTmpDirectory = "{$wgUploadDirectory}/tmp";
).
However, that file didn't change during the last upgrades. And it worked before. So my guess is before it just has fallen back to sys_get_temp_dir() while it fails now, as it honors the setting in any case, even if non-existant.

Changing to enhancement request. wfTempDir() should have better fallbacks. Possibly installer should pre-select a temp directory.

Change 284528 had a related patch set uploaded (by Addshore):
wfTempDir try harder to get a tmp dir on Windows

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

Change 284528 merged by jenkins-bot:
wfTempDir try harder to get a tmp dir on Windows

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

Change 288456 had a related patch set uploaded (by Addshore):
wfTempDir try harder to get a tmp dir on Windows

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

Change 288456 merged by jenkins-bot:
wfTempDir try harder to get a tmp dir on Windows

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

Change #1281985 had a related patch set uploaded (by Krinkle; author: Krinkle):

[mediawiki/core@master] FileBackend: Remove outdated Windows hack from TempFSFile

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

Change #1281985 merged by jenkins-bot:

[mediawiki/core@master] FileBackend: Remove outdated Windows hack from TempFSFile

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