Make ImageAPI/ImageCache PHP 4 compatible

Did you run update.php after upgrading imagecache?

Is there anything in the watchdog logs?

Hello. I am having the same issue although I get '66 is not a valid image resource...' I thought I would post here rather than having two threads with the same issue.

It should have modified the imagecache tables.... If it didn't it could cause a lot of problems... Can you revert back to your old db and update again and see if the updates happen to the table?

Hello dopry!

I have this problem too :(

warning: imagejpeg(): 55 is not a valid Image resource in z:\home\im22\www\modules\imageapi\imageapi_gd.module on line 173.
warning: htmlspecialchars() expects parameter 1 to be string, array given in z:\home\im22\www\includes\bootstrap.inc on line 631.

New drupal installation, ImageCache 5.x-2.0-beta, Image Field 5.x-2.0-rc2, ImageAPI 5.x-1.0-beta, Windows
ImageCache-1 - is work well.

I try to create avery preset - imagecache not work.
Problem is in the imagecache_actions.inc or in ImageField module, because then I create empty preset - all are work well.
Or if I comment line 336 in imagecache.module - all are work well, but images have original size.

function _imagecache_apply_action($action, &$image) {
  $actions = imagecache_action_definitions();
 
  if ($definition = imagecache_action_definition($action['action'])) {
//    return call_user_func($action['action'] .'_image', $image, $action['data']);
  }
  // skip undefined actions.. module probably got uninstalled or disabled.
  watchdog('imagecache', t('non-existant action %action', array('%action' => $action['action'])), WATCHDOG_NOTICE);
  return TRUE;
}

Files in the tmp directory are appear and disappear, but in files/imagecache/preset1/ dirrectory files not appear.

to dorpy

I found error:
PHP 4.4.4
imageapi_gd.module
code is not work :

    imageDestroy($image->res);
    $image->res = $res; 

for
function imageapi_gd_image_desaturate(&$image) {
this code is work:

//    imageDestroy($image->res);
//    $image->res = $res;
    imagecopy ( $image->res, $res, 0, 0, 0, 0, $image->info['width'], $image->info['height']);
    imageDestroy($res);

You should to change all function imageapi_gd_image_***

has this been reviewed and/or commited yet?

@artycul:
Is then any mention of it being reviewed or comitted in the comments, NO!. How about reviewing it if it is something you're concerned about? I'm much quicker to commit patches that have some initial review... I only have a limited amount of time and about 300 issues I need to close. Assistance is greatly appeciated... Not just from the people who can write the patches, but also from the ones who can test them.

@dimm:
can you roll a patch so it is easier to test? I like the suggested fix and I think it will solve a lot of issues, but I have a good amount of code I am working on right now, and imagecache/imagefield has dropped on my priority list for the time being.

I tested this fix and it seems to work on the imagejpeg() issues above. I will upload it when I get home (I keep getting errors trying to upload from work).

On another note, now that I seem to have imagecache and imageapi playing nicely together, I am aware of another issue. I am not sure if this is related to the original problem, so I am not opening a new thread just yet.

Basically, when I use the scale function, it doesn't shrink correctly. This is difficult to explain, so I will give you an example. (I can't upload anything at the moment so I will do my best to describe it).

I have two imagecache presets set up, both using scale.
blog_main (320x240) and blog_teaser (160x120) used for the node and teaser view respectively.

If I upload an image at 640x480, on the node I am left with a black box that is 640x480, with the original picture resized to 320x240 in the top-left corner.
The teaser is the same, except the original is shrunk down to 160x120.

Hope that makes sense.

I get the same problem. Huge black box, with a little images

Here is the file as promised.

file didn't solved this error:

"warning: imagejpeg() [function.imagejpeg]: Unable to open 'files/imagecache/full/Picture 006.jpg' for writing: Permission denied in public_html/modules/i/imageapi/imageapi_gd.module on line 177.
warning: imagejpeg() [function.imagejpeg]: Unable to open 'files/imagecache/full/Picture 006.jpg' for writing: Permission denied in public_html/modules/i/imageapi/imageapi_gd.module on line 177.
warning: preg_match() expects parameter 2 to be string, array given in public_html/includes/bootstrap.inc on line 670. "

permision for directory is 775

file didn't solved this error:

"warning: imagejpeg() [function.imagejpeg]: Unable to open 'files/imagecache/full/Picture 006.jpg' for writing: Permission denied in public_html/modules/i/imageapi/imageapi_gd.module on line 177.
warning: imagejpeg() [function.imagejpeg]: Unable to open 'files/imagecache/full/Picture 006.jpg' for writing: Permission denied in public_html/modules/i/imageapi/imageapi_gd.module on line 177.
warning: preg_match() expects parameter 2 to be string, array given in public_html/includes/bootstrap.inc on line 670. "

permision for directory is 775

Was it supposed to?

Also, did this occur before using this patch or was it introduced by the patch?

@tomceek, your issue is not related. Please open a new support issue. It sounds like you have permissions errors.

@tomkun, please provide a patch, you can find out how @ http://drupal.org/patch/create.

With contrib unlike core create the patch from the module directory. In this case in the imageapi folder.

In image_gd_crop and image_gd_resize You want to use width and height as the last 2 arguments to imagecopy or move it after the image is resample... Those dimensions are the target buffer size and you're using the original width and height which is why you get the big black box.

.darrel.

I can't figure it out. This is really above my level. I have managed to output many psychadelic effects, but I never seem to be able to lose the original dimensions.

I'll say it does look pretty cool. :) I'll probably get this in the next few days... I want to get this module released and out of my hair so I can convince some other poor schmoe to help maintain it. :)

tomkun are you on php4 as well?

Yes, 4.4.7

I have tried altering every variable in the imagecopy, but to no avail. Although as you can see the image is being resized, the old dimensions are still stuck in there. I believe therefore that it is not a problem with the imagecopy line itself. Unfortunately, I know very little about PHP (trying to help you here has been my first attempt), so I have no idea how to test my theory!

I'm looking into this issue at the moment and I believe I know what the issue is, I just haven't figured out why it's occurring and how to fix it as of yet.

I dumped some debug code inside both imagecache and imageapi to dump the $image array both before and after each action was processed and this is what is happening:

ImageCache before action:

stdClass Object (
  [source] => files/pictures/picture-13.jpg
  [info] => Array (
    [width] => 150
    [height] => 147
    [extension] => jpg
    [file_size] => 42703
    [mime_type] => image/jpeg
  )
  [toolkit] => imageapi_gd
  [res] => Resource id #144
)

ImageAPI at the start of action:

stdClass Object (
  [source] => files/pictures/picture-13.jpg
  [info] => Array (
    [width] => 150
    [height] => 147
    [extension] => jpg
    [file_size] => 42703
    [mime_type] => image/jpeg
  )
  [toolkit] => imageapi_gd
  [res] => Resource id #144
) 

Nothing has changed as expected.

ImageAPI at the end of action:

stdClass Object (
  [source] => files/pictures/picture-13.jpg
  [info] => Array (
    [width] => 16
    [height] => 16
    [extension] => jpg
    [file_size] => 42703
    [mime_type] => image/jpeg
  )
  [toolkit] => imageapi_gd
  [res] => Resource id #147
) 

Image has changed as expected

ImageCache after action:

stdClass Object (
  [source] => files/pictures/picture-13.jpg
  [info] => Array (
    [width] => 150
    [height] => 147
    [extension] => jpg
    [file_size] => 42703
    [mime_type] => image/jpeg
  )
  [toolkit] => imageapi_gd
  [res] => Resource id #144
) 

Image reverted to original information - this is the problem as Resource id #144 no longer exists.

It's apparent that the information is not being passed back from ImageAPI to ImageCache, which is strange is it works fine with other sites on other servers I have setup. I will keep looking into this, but if anyone knows of why this would happen it would be extremely helpful.

Edit: I would suggest returning $image rather than TRUE in ImageAPI, but as it's an API this may have side-effects for anything else using it. As I said, it does currently work on other sites/servers, so it shouldn't be necessary to do so, but it would certainly be a way to get around the issue in the short term.

Attached is a couple patches with the temporary fix described above.

I do not suggest using these patches unless you are desperate, utlimately I would like to get to the cause of this issue. This has only been tested quickly, I tested 'scale', 'crop' and 'scale and crop' succesfully in GD, I did not test any of the other actions.

Deciphered are you using php4 or php5 on the site you're having trouble with. I'm starting to think this is a php 4 specific issue. If it is I'm going to close it as won't fix and add php5 to the requirements for imageapi.

Hi Dopry,

Yup, I certainly am and I'm sure you are right. I'm using PHP 4.4.4, however I would hope you don't take this option as Drupal itself officially supports 4.3.5+ and it would be a shame if not all Drupal users could use all Drupal Modules.

As I showed with the above patch there is way to fix this issue, while admittedly it's not the best solution it is a start.
I would be more than happy to work with you to keep this great module PHP 4 compatible.

Cheers,
Deciphered.

Just to let you know that I asked my host to update the PHP on my site to version 5. Actually it was already there, I jsut had to reference it in .htaccess. Anyway, updating it to version 5 seems to have solved the issue so it looks that your instinct was correct Dopry.

Thanks for the help!

P.S. Even though my problem has now been solved, I do agree with Deciphered that it would be a pity to deprive the PHP4 users of such a useful module. If there is anything I can do to help you out, let me know.

Sorry PHP4 users.... You gotta goPHP5, http://gophp5.org/

I'll add it to the requirements for imageAPI.

Very disappointed with the outcome as one of the sites I'm working on does not have the liberty to do an upgrade to PHP5. I will still look at an alternate solution to my previous patch that fixes the issue more elegantly and hopefully you'll consider rolling that in.

Submitted as a DROP Task: http://drop.cwgordon.com/node/37

Sorry no, I will not consider adding support for PHP4 just to support PHP4.

Appreciated that we want to drop PHP4, but I've now encountered it on PHP5 also.

The calls throughout to call_user_func do NOT reliably modify the image passed by reference in cases where the image resource is discarded then replaced. call_user_func() does not support pass-by-reference. It just happens to work OK when the image passed by handle is simply changed, so much of the time the problem is not visible, but it was killing some of the scale_and_crop processes.

Also, sometimes it DOES just work, for reasons that are unclear. On my dev site with [5.2.3-1ubuntu6.3] It was all coolness, all the time.
On a host site with [PHP Version 5.2.5] it was killing me with a hundred errors, and the images came out the old proportions.

fix

As per php.net, using call_user_func_array() gives the desired results!

 function imageapi_image_crop(&$image, $x, $y, $width, $height) {
-  return call_user_func($image->toolkit .'_image_crop', $image, $x, $y, $width, $height);
+  // Needs to be passed by reference
+  return call_user_func_array($image->toolkit .'_image_crop', array($image, $x, $y, $width, $height));
 }

... Maybe this is a new issue, and I need to try the most recent release or something and post a clean patch, so just call this troubleshooting fix an FYI for anyone who finds this thread when wondering why their public server barfs on code that was working at home :)

But it IS replicable behaviour on PHP5 ... just not every version of PHP5 :-{

Dman, just like you said, my public server is barfing on code that went down smooth on a dev server last week. I came across this on PHP 5.2.6 (linux). Bummer is, your fix isn't working out for me. I've got no skill in writing a solution but I can test the crap out of it if you have anything to try.

EVERY instance of call_user_func() needs to be modified with this fix.
There's a dozen or more throughout the code, and I only found them depending on which filter I was using.

Here's the patch I'm currently using (against imageapi 30 Mar 2008) on one site that has the fixes I needed + heaps of graceful debugs I added to track the problem down

If it doesn't apply clean, sorry, I edited out a few other irrelevant changes that are in other queues

This does not patch cleanly for me when patching imageapi_gd.module. Anyone else out there that can test these?

marked #269552: Getting error: not valid image resource on imageprocessing as a duplicate