Last modified: 2014-02-28 12:56:35 UTC
I got this error for some time from mediawiki 1.19+ j'ai cette erreur depuis un certain temps sur mediawiki 1.19+ Erreur lors de la création de la miniature : Impossible d'enregistrer la vignette sur la destination Error creating thumbnail: Unable to save thumbnail to destination Find this corrector on the web j'ai trouver cette correction sur le web http://www.mediawiki.org/wiki/Thread:Talk:MediaWiki_1.19/Thumbnails_didn%27t_work_since_Update_to_1.19 with this code the thumbnail work avec ce code la vignette fonctionne fichier /includes/GlobalFunctions.php remplacer la function wfTempDir() par file /includes/GlobalFunctions.php replace function wfTempDir() by 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'; }
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.