Thumbnails didn't work since Update to 1.19
Hey, I seem to be having the same problem, but the patch doesn't help: No matter what I do, I get the same error message.
It's a brand new MW installation, 1.19.0, in a shared hosting environment. I have php 5.3.10 (apache2handler) and GD library enabled. My "upload_tmp_dir" in phpinfo.php says "/tmp", and the /tmp directory on my server has rights drwxrwxrwt.
This is what I have in LocalSettings.php - uncommenting the ImageMagick variables has no effect:
$wgEnableUploads = true;
- $wgUseImageMagick = true;
- $wgImageMagickConvertCommand = "/usr/bin/convert";
I have tried to get some more error messages out of the php, using:
error_reporting( E_ALL ); ini_set( 'display_errors', 1 ); $wgShowExceptionDetails = true;
in LocalSettings.php, but that doesn't produce anything either.
Any ideas???
Forgot to say, but the images directory in the MW installation has rights 777, as do all the subfolders.
Are you able to write to /tmp from your web process? Could you write a test script to verify this? If you don't know how, could you install a test I write to verify it?
Good question. Sure, pass me the script if you have one! (I think I could figure it out myself, but not without some effort...)
Some more info that I guess is relevant: I have another, older mediawiki installation running on the same server, where file uploads work fine. That is MW 1.15.1 though. I also just realized that php safe mode is enabled on our server. Is that a likely cause for trouble?
CORRECTION: I just realized that, although file uploading has worked fine for the purposes I have had till now, *thumbnailing* does not seem to work in any of the MW installations on our server. (Haven't had the need for thumbnailing until now.) So I guess this issue is not related strictly to version 19 of MW, but is a general issue with either MW or our server. Sorry about that.
Still, if anyone has any idea about how to diagnose this problem, I'd be thankful!
I tried the following:
<?php
$handle = fopen("/tmp/test.txt", "x");
if ($handle) echo "Success!";
else print_r(error_get_last());
?>
...which returns "failed to open stream: No such file or directory". According to php.net the 'x' flag should cause the file to be created if it doesn't exist, so I guess there is something wrong somewhere? I have allow_url_fopen=off in phpinfo, but that shouldn't matter, right?
Sorry for spamming the thread - I'm a noob. I changed the above script to point to the images directory, and then i get success. Could this be a php bug? (Or at least a very misleading error message...)
My open_basedir has "no value".
Excellent work on reproducing the problem since I took too long to get back to you. Could you try this script?
<?php
function dirTest( $label, $dir ) {
echo "Test for $label: $dir\n";
if( file_exists( $dir ) ) {
echo "Dir exists\n";
$s = @stat( $dir );
if( $s === false ) {
echo "Stat failed: $php_errormsg\n";
} else {
echo "Permissions: ". decoct( $s[2] ) ."\n";
echo "Is dir: ". ( is_dir( $dir ) ? "true" : "false" ) ."\n";
echo "Is writable: ". ( is_writable( $dir ) ? "true" : "false" ) ."\n";
$file = tempnam( $dir, "test" );
echo "Attempting to create: $file\n";
$fh = fopen( $file, "w" );
if( $fh !== false ) {
$written = fwrite( $fh, "stuff" );
if( $written === false ) {
echo "Error when writing: $php_errormsg\n";
} else {
echo "Wrote $written bytes.\n";
if( fclose($fh) === false ) {
echo "Error when closing: $php_errormsg\n";
}
}
if( unlink( $file ) === false ) {
echo "Error removing $file: $php_errormsg\n";
} else {
echo "Sucessfully removed $file\n";
}
} else {
echo "Error opening for writing: $php_errormsg\n";
}
}
} else {
echo "Directory does not exist!\n";
}
echo "\n";
}
dirTest( "Unix tmp dir", "/tmp" );
dirTest( "Window temp dir", "c:/windows/temp" );
dirTest( "sys_get_temp_dir", sys_get_temp_dir() );
dirTest( "upload_tmp_dir", ini_get( 'upload_tmp_dir' ) );
btw, on my laptop this gives:
Test for Unix tmp dir: /tmp Dir exists Permissions: 41777 Is dir: true Is writable: true Attempting to create: /tmp/testjmWbDE Wrote 5 bytes. Sucessfully removed /tmp/testjmWbDE Test for Window temp dir: c:/windows/temp Directory does not exist! Test for sys_get_temp_dir: /tmp Dir exists Permissions: 41777 Is dir: true Is writable: true Attempting to create: /tmp/test6nrzCk Wrote 5 bytes. Sucessfully removed /tmp/test6nrzCk Test for upload_tmp_dir: Directory does not exist!
Thanks for getting back to me! The above script returns:
Test for Unix tmp dir: /tmp Directory does not exist! Test for Window temp dir: c:/windows/temp Directory does not exist! Test for sys_get_temp_dir: /tmp Directory does not exist! Test for upload_tmp_dir: /tmp Directory does not exist!
For the record, there IS a directory that appears to me as '/tmp' in my command line. But I posted this question on stackoverflow, and a commenter suggested the problem could have to do with 'chroot'. This server is part of a large university network, so I am sure the setup is fairly complex.
It seems odd though, given that the user 'nobody' - which I am almost certain is the user running php scripts - is able to write to /tmp.
Is there any way to have the thumbnailing process use some other tmp folder, for instance one under the images folder - where I know i can write?
To be more precise: the reason I believe the php user can write to /tmp is that I find lots of files in that directory which have "nobody" as their owner, which is the same owner as I saw on the subfolders that the mediawiki system created under the images folder. The files I see in the /tmp folder all start with "sess_" followed by something that look like a hash, I assume they are some kind of temporary files created by the webserver. Unfortunately I do not at the moment have access to the apache error logs.
Interesting. There is $wgTmpDirectory, but wfTempDir() ignores it. Instead of trying to track this down further, go to your includes/GlobalFunctions.php and replace the body of wfTempDir() with:
function wfTempDir() {
global $wfTmpDirectory;
return $wfTmpDirectory;
}
I'll investigate why wfTempDir() ignores this. I'm sure there is a good reason, I just don't know it.
I assume that's a typo, the variable name should have a 'g' as in $wgTmpDirectory, right? That doesn't quite fix the problem, though. There is a small change: Before the image that I'm trying to upload didn't show up at all on the File:Filename.jpg page (the one that comes up after you click upload) - even though the full version of the image did get uploaded, where it should show on the page was just the error message. Now the full version of the picture is shown, but in the "File History" table below the same error message is shown under "thumbnail". so I guess this modification made the script crash a little later in the process?
Looking in the "thumb" directory there are now empty directories, which each have the same filename as an image I have tried to upload. (E.g. 'images/thumb/PICT0157.jpg/').
If I switch over to using ImageMagick, I get a different error message, saying something about safe mode preventing an external program to be called. Which I guess supports the hypothesis that this fix removed one problem, but the script still crashes later on.
Thank you very much for taking an interest in my problem - will still be grateful if you have any other ideas for a solution...
Sorry, yes, a typo.
> where it should show on the page was just the error message
What is the error message?
> so I guess this modification made the script crash a little later in the process?
I don't think so. I think you just need to regenerate the thumbnail. Try adding "?action=purge" to the File:Filename.jpg url. New files should upload with no problem.
> What is the error message?
I was referring to the same error message as we've been talking about all the time: "Error creating thumbnail" etc. Before it showed up two places: Where the picture should come, and in the "File history" table. Now it only comes in the table.
> New files should upload with no problem.
Nope. I always test with new files - the errors I am reporting apply to new files that I have not previously tried to upload.
Could you try this patch?
I'd love to try it, but I don't know how to get it in a format so I can apply it to my installation. I can't use the command that comes up if I click on "patch", because my environment doesn't let me run git (two of my machines say "command not found", the third says "not a git repository").
I emailed a patch to you. Let me know if it doesn't work.
