Wikimedia Bugzilla is closed!

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?

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?

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.

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.

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)

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.