forum.coppermine-gallery.net
Support => cpg1.5.x Support => cpg1.5 upload => Topic started by: flapane on June 08, 2012, 12:34:55 pm
-
Critical error
Unable to create thumbnail or reduced size image.
File: /[.foo..]/gallery/db_input.php - Line: 699
It has worked well until some weeks ago, and I haven't uploaded photos, changed cpg core files or any settings from then on.
I tried with different jpg files bigger and smaller than 1285px (my max size for original pic).
I've read the troubleshooter and created a test account.
username: cpg_test
pwd: problem
-
Please post a link to the affected gallery.
-
The one in the signature (as per forum rule).
-
Link to gallery: http://www.flapane.com/gallery/
The script dies at line 699, which means that add_picture returned something different than "true". I guess you already checked the directory permissions? If so, we'd need to debug the function add_picture by commenting out some code parts to find the issue (in include/picmgmt.inc.php).
-
Thanks. Sure, I checked folder permissions while reading the troubleshooter, and found nothing weird.
-
I cannot upload photos. I followed the instructions very carefully and they will not upload. this is the message I receive:
critical error
unable to create thumbnail or reduced size image
File: /home/academi/public_html/CFC/db_input.php - Line: 666
http://www.academicangler.com/CFC/db_input.php
-
Different code line. You'd better open a new thread.
-
I have exactly the same issue as you flapane, if you find a solution I would be pleased to know what it is. If I have any luck sorting it out will let you know.
-
I'm waiting for Andrč to suggest me which lines to comment for debugging purposes.
-
Have a look at include/picmgmt.inc.php. Within the
} elseif (is_image($filename)) {block you'll find a couple of if-blocks. Try to comment them out one by one to find out which one doesn't work as expected. It's hard to explain how to find the cause, it's probably easier to give me FTP access to your gallery. But I'm currently quite busy and don't know when I'll find time to work on that issue.
-
Tried with no luck (the if blocks end at line 101).
I've also set up an account for you. Check PM.
-
err... no PM folders for admins.
-
Just sent you a PM.
-
It has worked well until some weeks ago, and I haven't uploaded photos, changed cpg core files or any settings from then on.
I tried with different jpg files bigger and smaller than 1285px (my max size for original pic).
I've read the troubleshooter and created a test account.
username: cpg_test
pwd: problem
I know I have had this issue before, can't remember, it has been a while... something to do with theme validation...
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.flapane.com%2Fgallery%2F&charset=%28detect+automatically%29&doctype=Inline&group=0
(your theme is making the browser take it's best guess)
Maybe change theme to a standard out of the box theme, and test it...?
Hope this helps
-PCK
-
Hi, for whatever reason, today w3c fails to read the doctype of the theme which is xhtml transitional indeed, which leads to 10 errors. They're non-critical, though.
I tried using a vanilla theme without custom header and footer, however nothing changed. Thanks
-
You're currently using ImageMagick as resize method. Please try GD2.
-
GD2 does is work flawlessy.
Before writing the OP, I asked my hosting if there was something wrong with imagemagik, because I couldn't resize images, and they told me that nothing changed.
I've been using IM since a couple of years or so for resizing images in the gallery. I wonder what's wrong.
-
I've received an answer from my hosting, they told me that the error is due to line 71 of db_input.php, because this line of code doesn't use ImageMagik.
if (!$superCage->get->keyExists('event') && !$superCage->post->keyExists('event')) {
cpg_die(CRITICAL_ERROR, $lang_errors['param_missing'], __FILE__, __LINE__);
Honestly, I don't know what to say.
-
That doesn't make sense to me, sorry.
-
Yep, actually it doesn't for me neither, but I had to report the answer they gave me... I'm waiting for a new answer from my hosting.
I wonder what could cause Imagemagik to stop working all of a sudden.
-
They keep saying that the error is related to line 71 and not to Imagemagik.
I don't understand how they found something wrong with line 71, if cpg clearly states that the problem is on line 699.
-
I don't understand how they found something wrong with line 71
I assume they just put that URL into their browser: http://www.flapane.com/gallery/db_input.php and of course get the following error message
Critical error
Script called without the required parameter(s).
File: /home/flapanec/public_html/gallery/db_input.php - Line: 71
....... :o ::)
-
oh my...
They didn't even bother reading what I wrote.
-
They told me another time that they don't have any problems and I'd better contact cpg developer (as if I hadn't already told them what we wrote in this thread...).
"Disappointed" is the right word, I guess. I may consider migrating elsewhere when the annual subscription expires.
-
I've also just tried reinstalling 1.5.20 on the top of itself and disabling the plugins. Needless to say, nothing changed (after all, the problem first appeared all of a sudden without any changing to the code, so reinstalling cpg couldn't have helped).
-
Maybe a test with a different software that also uses ImageMagick will approve our assumption that there's something wrong with ImageMagick on your hosts part. But I don't know such a software.
-
That's a good idea. I'll keep you updated in case I found some PHP script which uses IM.
-
This code succesfully created a thumbnail:
<?php
/*
A simple example demonstrate thumbnail creation.
*/
/* Create the Imagick object */
$im = new Imagick();
/* Read the image file */
$im->readImage( 'test.jpg' );
/* Thumbnail the image ( width 100, preserve dimensions ) */
$im->thumbnailImage( 100, null );
/* Write the thumbail to disk */
$im->writeImage( 'th_test.jpg' );
/* Free resources associated to the Imagick object */
$im->destroy();
?>
-
But Imagick isn't ImageMagick, right?
-
PHP.net: IMagick is a native PHP extension to create and modify images using the ImageMagick API.
Provides a wrapper to the ImageMagick library.
should I try a different php script?
-
What do you have for the setting in Config >> File settings >> Additional command line options for ImageMagick ?
Could the value have been corrupted in the db?
Please attach a screenshot of that setting.
-
Yep, one of the first thing I did was deleting every additional CLI setting (which has been -antialias -unsharp 0.7x0.5+0.7+0.008 for the last couple of years or so) from that textfield, but nothing changed.
I wonder if the setting still remained in the sql dbase and eventually corrupted. Do I have to search for a specific sql db field in order to check this?
Thanks
-
Do I have to search for a specific sql db field in order to check this?
That setting is stored in the config table. Search for the row with the name "im_options".
-
It looks empty as it should be
-
As GD2 works as expected, isn't that thread already solved? I just wanted to debug $output and $retval in your gallery, but unfortunately it seems that my FTP account to your gallery doesn't exist anymore. Of course IM must be chosen in the config if you want me to debug that values. Maybe it brings some light into the darkness.
-
FTP account was temporary disabled for security reasons, please try again.
Maybe the title should be changed to "IM: Problem resizing or creating thumbnails", because the control granted to the user by IM command line options is vital.
The weird things are that it stopped working all of a sudden a couple of weeks ago, and IM *seems* to work using a test script, and that reinstalling cpg on top of itself didn't solve.
Thanks
-
PHP tries to execute the following command:
/usr/bin/convert -quality 80 -geometry 100x74 -unsharp 0.5x0.707106781187+1.2+0.03
As you can see, both the source and destination file strings are missing. The reason is the function escapeshellarg:
if (preg_match("#[A-Z]:|\\\\#Ai", __FILE__)) {
// get the basedir, remove '/include'
$cur_dir = substr(dirname(__FILE__), 0, -8);
$src_file = '"' . $cur_dir . '\\' . strtr($src_file, '/', '\\') . '"';
$im_dest_file = str_replace('%', '%%', ('"' . $cur_dir . '\\' . strtr($dest_file, '/', '\\') . '"'));
} else {
$src_file = escapeshellarg($src_file);
$im_dest_file = str_replace('%', '%%', escapeshellarg($dest_file));
}
For some reason that function returns empty strings. Please ask your host about that function. Here's a test script and its output:
$test = "test";
var_dump($test);
echo "\n";
var_dump(escapeshellarg($test));string(4) "test"
NULL
-
Thanks, I'm gonna write them another message.
-
They said that escapeshellarg() has always been disabled because of security reasons, so probably I never noticed the problem because Coppermine started using on the latest release only.
---
I wonder if it's actually been introduced in 1.5.20 only.
-
I don't know when it has been introduced, but it hasn't been introduced recently, as it's also been used in cpg1.4.x.
-
So I guess they lied for whatever reason. I understand their security concerns, but the fact that it's always been disabled is clearly a lie.
I guess I have to stick to GD as soon as I find another hosting. That's annoying, I'm not satisfied at all with the sharpness of the images produced by GD.
Out of curiosity, do we have any other ways for passing arguments to the shell via PHP? It seems that quite a few hostings around the world disabled escapeshellarg() in the last years.
Andre, thanks for your support.
-
do we have any other ways for passing arguments to the shell via PHP?
It's not a matter of how to pass arguments, but how to escape specific characters in arguments. In that particular case it should be save to escape some characters like the single quote and put the whole argument in single quotes (at least that's what I understand what escapeshellarg does) if you're the only person who has permissions to upload pictures to your gallery. Regarding the security issue I found this (http://osvdb.org/show/osvdb/6737) article, which says that the security flaw has been fixed in PHP 4.3.7.
-
Who knows, maybe they don't trust of the customers themselves, I guess (customers could launch heavy load processes or whatever).
-
Then they have to disable the exec function. escapeshellarg seems to be the number one choice for shell arguments what mysql_real_escape_string is for whole MySQL query strings.
-
Bingo. In fact I had to use mysql_real_escape_string in the guestbook I recently wrote for my website in order to avoid injections. I'm gonna tell them, but I suspect that things won't change.