function.getimagesize error

I don't think I have ever worked on a site with private download, but I will look into what might need to be done - at the very least, an error message.

This is also an issue for hosting infrastructure's with security protocols which do not allow file access via URL. Without this access getimagesize() fails when passed a URL rather than a file directory path.

Please introduce a check for this and fall back to a file-system level read if possible.

Thanks!

Jer

At line 268, you will see

//    $img = getimagesize($image[$tid]->path);
    $img = getimagesize($image[$tid]->url);

Please change it to

//    $img = getimagesize($image[$tid]->path);
    $img = getimagesize($fullpath . $image[$tid]->path);
//    $img = getimagesize($image[$tid]->url);

And let me know if the problem is solved.

Great, thanks for checking it out for me. I can commit this now.

Committed. It's always nice to have someone actually test a fix.

Thanks NancyDru, patch in #4 worked!

It is now part of the -dev release so it does not need to be patched.

I'm having issues on a multi-site install, even after the patch #4.

using on line 266:
dpm(array('fulpath' => $fullpath, 'path' => $image[$tid]->path));

I get

'fullpath' => 'sites/domain.tld/files/category_pictures/'
'path' => 'sites/domain.tld/files/category_pictures/cinza_laranja.jpg'

which still doesn't work.

Same issue if using taxonomy_image_attach module because path stored in image NOT relative to category_image folder

Patch from #4 is a quick fix but problem is deeper

as #437814: Images won't load and site "crashes" after upgrade from 1.5 to 1.6 not duplicate but dependable

Suppose images can be stored in any location but displayed propertly

Another issue with image_attach if term delete so image deletes too but it breaks original image-node

Upon testing the dev-Version w/ the fix above I must mention that this breaks the functionality of loading the default image.
Instead of

$image[$tid]->url = url($fullpath . $image[$tid]->path, array('absolute' => TRUE));

It should be

$image[$tid]->url = file_create_url($fullpath.$image[$tid]->path);

Also the description must be changed, so the users only specify the filename of the default image. If you want to keep this option (a completly different path for the default-category image) the above replacement should read:

$image[$tid]->url = file_create_url($image[$tid]->path);

Why not url()? Because URL creates language-aware paths which might include a language prefix, e.g. 'en'. You won't be able to load the file from that location.

While submitting this fix you did not realise that it was reported as separate bug #454414: failed to open stream: no suitable wrapper could be found. Please look better and fix it in the right issue! I started fixing the duplicate issue and discovered too late that your fix was submtted to dev version already.

Upgraded from 1.4 to 1.6 today, hit lots of these messages even after running update.php, using public files.

#4 fixes this, neck-deep in work atm so have not checked this out any further.

I get a warning:

warming: getimagesize() [function.getimagesize]: URL file-access is disabled in the server configuration in ... sites/all/modules/taxonomy_image/taxonomy_image.module on line 267. 

#4 fixes this problem for me. But ...

On the taxonomy_image project page "Development version status" the solution of this problem is refered to as "Support private downloads".
I don't think this has anything to do with either private or public download. Private/public download is abaut how images are presented to the visitor of a website. The access we are talking abaut is direct acces to the image file by a php file function. This should always be done via a path. As my warning message shows, some servers do not allow URL-file access.

Regards,
hovel

change at #4 fixes for me. subs

I could replicate the problem described at #15

The 'default image' path is left behind by the new path+filename method.
EITHER always put the default image alongside the rest and only give the filename
OR leave the default image as a special case requiring the full path.
(I favor option A)

but right now, release 1.6 does not behave as described with default images.

(Also - when testing, we need to flush the cache agressively under admin-performance. One failed lookup gets remembered, so it's hard to see when you've 'fixed' it)

I had this problem. I found that it only occurs when I upload an image with a space in the file name. I.e. 'trees in new forest.jpg' fails, but 'trees_in_new_forest.jpg' is just fine.

Can I suggest that on upload, the file needs to be renamed with spaces replaced by underscores?

#4 fixes the problem on D6

subscribing

subscribing
#4 fixes the problem

After research on Google came across this in the php help for getimagesize: 'If your image name has spaces in it you will need to use rawurlencode() and NOT urlencode() as this function (at least in 4.3.4) does not accept spaces as + signs.'

So:

Change line 267 in taxonomy_image.module from:

 $img = getimagesize($image[$tid]->url);

to:

 $img = getimagesize(rawurlencode($image[$tid]->url));

Fixed it for me.

My post #25 doesn't work. rawurlencode should only be used on the filename, not on the entire URL.

This is what I did, and it 'seems' to be working OK:

Leave line 267 as:

$img = getimagesize($image[$tid]->url);

Rather change line 243 to include rawurlencode only on the filename:

$image[$tid]->url = file_create_url($mypath . rawurlencode($image[$tid]->path));

Hi, I was getting this error and none of the fixes posted above worked.

warning: getimagesize(http://www.mydomain.com/sites/default/files/category_pictures/sites/default/files/category_pictures/download-icon.gif) [function.getimagesize]: failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found in /var/www/virtual/www.mydomain.com/htdocs/sites/default/modules/taxonomy_image/taxonomy_image.module on line 267.

download-icon.gif is my default image. I noticed only that image was missing on my page and found that in the above URL, the "sites/default/files/category_pictures" is duplicated. So, I changed:

Line 261 of taxonomy_image.module from

$image[$tid]->url = url($fullpath . $image[$tid]->path, array('absolute' => TRUE));
to:
$image[$tid]->url = url($image[$tid]->path, array('absolute' => TRUE));

... and the error disappears, my default image now loads.

Info:
Drupal 6.13
Taxonomy Image 6.x-1.6

This one (#27) didn't work for me.
#4 works OK on Drupal 6.14

The attached patch implements #4 (tested on drupal 6.14); the code, probably needs, some clean up.

BTW why we don't use image_get_info here?

Side note: if you use the url you can have problems if you use the module in an apache protected site. Moreover with the url (remote file) getimagesize needs to download the file before recovering the info...

why we don't use image_get_info here?

Because it won't accept SWF files.

Let's see some testing and reviewing on the actual patch and someone mark it RTBC.

subscribe
#4 fixes the problem

Many thanks it works for me

We were experiencing this issue with one of my clients' servers (Rackspace) and the patch in #29 fixed the issue for us.

The symptoms were pretty severe! We couldn't load the taxonomy image admin page or the pages where the taxonomy images where being displayed. It would just timeout.

A number of people have now confirmed this works for them so I think it would be safe to commit.

Edit: I see that it's been committed already, thanks ;)

Hi ...

I got the same issue ... and did some manual fixes in the code ...
The image file path were corrupt builded like http://<domain>/sites/<domain>/files/category_pictures/sites/<domain>/files/image/file>.jpg).
The path part was duplicated. With little debugging I discovered that $image[$tid]->path contains the whole path information. So no path building seems to be necessary.

// $mypath = variable_get('taxonomy_image_path', 'category_pictures') .'/';         // - Original
    $mypath = variable_get('taxonomy_image_path', 'category_pictures');              // - changed by aSoahc
    $fullpath = file_directory_path() .'/'. $mypath;

// $image[$tid]->url = file_create_url($mypath . $image[$tid]->path);               // - Original
   $image[$tid]->url = $image[$tid]->path;                                          // added by aSoahc

//    $img = getimagesize($image[$tid]->url);                                        // - Original 
//    $img = getimagesize($image[$tid]->fullpath);                                   // added by patch
      $img = getimagesize($image[$tid]->path);                                       // added by aSoahc

Maybe this issues will be fixed in a newer version.

Regards, aSoahc

#4 worked for me! thanks!

Perhaps make this fix (from #4) a configurable option for the module? I have just run into an issue with a site hanging for a minute or more which turned out to be this line when combined with load balancing after a little research with Xdebug and Webgrind. It would be nice to allow this to be configured.

I am glad that we're accessing the file via the local filesystem, not via HTTP now. Thanks for that - it's a lot more efficient to skip the extra request handling.

I'm afraid that a small fix is still required here, because the module will still show an error (even to anonymous users) if the image doesn't exist, and that isn't ideal IMO.

Checking for the existence of the file is only a partial fix, as the image might be unreadable (permissions) or invalid (corruption). Suppressing the error in case of failure (using the @ operator, eg @getimagesize) is what happens in image_get_info(). That's a simple fix really.

This patch checks for existence of the file. It's fairly trivial so I'll leave it up to the maintainer to change status if this needs further review or discussion. Patch is against CVS 6.x-1.x-dev.

I have no issue with simply making the call @getimagesize() if that's preferable.

Scratch that. Setting "needs review" to make sure that NancyDru catches the updated patch above.

@xurizaemon - are you looking for is_readable() ?

@dman - you're right, is_readable is a better way. Thanks.

Two patches attached - please pick one.

One checks if the file can be read, but will still show errors in the event of corrupted images being uploaded.

The other simply suppresses the error message, as per image_get_info().

Here is a version of the is_readable patch that works with 6.x-1.6

The patch in #41 worked perfectly for me on 6.x-1.6 behind htauth and with language switching by path prefix enabled. Thanks!

ran into the same problem after updating, patch #41 works for me, thanks

is readable patch in #40 works for me

subscribing

So many patches... Which one do we use?

Hello,

When this patch will be applied to this great module. Is there anyone here to maintain it?

Subscribing

So there are actually two people that tested #41?

And worst, we have this error for nothing !
Image size seems not to be used.
Height and width are never writen in HTML output.
See #707850: Missing Height & Width attributes

@Niels Hackius: yes, see comments #42 and #43 :)

@srobert72: that's an unrelated bug and shouldn't hold up this patch.

@Niels Hackius: yes, see comments #42 through #45

#41 patch works for me as well.

Patch #41 worked for me great. Thanks.

Have been using 6.x-1.6 for a while but saw this error for the first time today.
(all my images are already readable, and I have no spaces in filenames)
Patch #41 apparently fixed it. Tank you.

Patch #41 works a treat. Thanks alot.

#41 on 6.x-1.6 worked perfectly. Thanks much!

Thankyou thankyou thankyou! #41 worked for me too.

cheers, joe

Patch in #41 works for me too. Can has new release pls?

Im going to give this a try now, looks promising though =D

#41 works for me on multilanguage website

Have raised this issue with NancyDru directly, she said she'd try to take a look at it today. Thanks Nancy!

patch in #41 works for me on a multisite install

Patch in #41 worked. Drupal 6.16

Patch in #41 worked. Drupal 6.16

I think it's clear now that the patch works. We're just waiting on the maintainer to accept it at this point.

It may be that Nancy would appreciate someone stepping forward and offering to co-maintain the module in the meantime - I understand she still has a lot on her plate and her availability to handle contributed module maintenance might be impaired for a while yet. This module is one Nancy adopted from another contributor, and the support of another taxonomy_image user/maintainer would probably be a big help.

If you think you might be able to help, please read dealing with abandoned projects and then put your name forward via #783486: Offers to co-maintain Taxonomy Image. I'm hoping that we won't need to follow the abandoned module process and that Nancy will invite a co-maintainer herself.

NancyDru, if you're following taxonomy_image still, I'm sure many of us would appreciate hearing back from you via that issue to clarify how you feel we can best support you as module maintainer.

Committed to 6.x-1.x-dev.

Thanks.......

// $img = getimagesize($image[$tid]->path);
$img = getimagesize($fullpath . $image[$tid]->path);
// $img = getimagesize($image[$tid]->url);

it works ..........
Amit

Maybe a note about this problem in the readme or on the module's page? It was the first thing to happen to me after install, a lot of wasted time would have been saved with a simple "install dev or apply patch from http://drupal.org/node/438378 @41 if you run into this"

Thanks for what I assume will be a great module!

Is the current -dev stable enough as-is to be an official release? Or do we need some more patches applied?

I think I've been using this -dev successfully for a while. Not been pushing at the edges though.
And this being a 'critical' fix on the last 'stable' sorta pushes a release into being a necessary bugfix.
IMO

@NancyDru
It would be nice if we could include a patch for this simple issue
#707850: Missing Height & Width attributes

Sorry, I'm not sure if I am following this thread entirely.

Does this patch address the issue I'm having of being unable to upload a term image with a space in the filename?

Just closed two duplicates of this, #602716: problem with "Use external image" and #861334: image should only be opened over HTTP if it is external.

@aaronbauman, this fix is in 6.x-1.x-dev already and yes it should fix your filename issues (but you probably already established that, that I'm sure).

@NancyDru, may I suggest a release coordination issue be opened if you're not yet confident of pushing out a new stable?

That way we can discuss whether or not 6.x CVS is ready for prime time without needing to divert this already lengthy thread from its topic.

Current dev still has problems. I had to change false code around lin 244.
$image[$tid]->url = file_create_url($mypath . $image[$tid]->path);
should read
$image[$tid]->url = file_create_url($fullpath . $image[$tid]->path);

#78 works for me

I downloaded the most recent dev version and I've applied that patch as suggested in #78 but the images are still not displaying. It's the first time I've tried using this module. Is there something else I'm overlooking?

Thank you Nancy,
#4 works for me. Great Tips!!!

Patch in #41 works for me too.
I'm running Drupal 6.17.
Thanks!

Kudos for the patches, works like a charm now..

The developer should fix this already

I keep getting this error at 6.20 dispite the patches.. I've try'd several boxes withoy luck.. i think i'm lost ....

Have you tried #4

Thank you so much, man.

one more thanks !

#41 works perfect for my installation: 6.20

Take a look at #69.

subscribing

I've got the same problem.

getimagesize(path/to/site/sites/default/files/category_pictures/image.png) [function.getimagesize]: failed to open stream: HTTP request failed! HTTP/1.1 401 Authorization Required in path/to/site/sites/all/modules/taxonomy_image/taxonomy_image.module on line 267.

This is what i got when i did this ,..
Please try yourself once before you submit a reply..

@nikhilmkumar that's a mysql related error and most likely not related to this problem.

Clear your cache and try again.

You may have a fast mysql connection timeout, or your query size limit is too small.

#4

i am using 6.x-1.6 taxonomy_Image module
and I have the same issue here

warning: getimagesize() [function.getimagesize]: URL file-access is disabled in the server configuration in C:\inetpub\vhosts\********.com\httpdocs\sites\all\modules\taxonomy_image\taxonomy_image.module on line 267

Where i should make this changes ?? on what file or folder ??

thank you

#4

i am using 6.x-1.6 taxonomy_Image module
and I have the same issue here

warning: getimagesize() [function.getimagesize]: URL file-access is disabled in the server configuration in C:\inetpub\vhosts\********.com\httpdocs\sites\all\modules\taxonomy_image\taxonomy_image.module on line 267

Where i should make this changes ?? on what file or folder ??

thank you

#4

Thank you , i got it now and it worked for me thank you :D

Thanks, It worked for me