function.getimagesize error
castawaybcn - April 19, 2009 - 17:47
| Project: | Taxonomy Image |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | reviewed & tested by the community |
Description
All of the sudden I am getting this error when accessing a view with taxonomy images
warning: getimagesize(http://www.mydomain.com/system/files/category_pictures/tasks_prio_01_urg...) [function.getimagesize]: failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found in /myinstalldirectory/sites/all/modules/taxonomy_image/taxonomy_image.module on line 267.
I just have no idea why this is happening, but in my case a table view shows some pictures in a row and then the same picture is not showing in other rows.
Any help will be much appreciated.
#1
UPDATE:
I just found out that the error disappears when you change the file download method to "Public - files are available using HTTP directly"
in admin/settings/file-system.
#2
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.
#3
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
#4
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.
#5
It worked, the error messages are gone!!
Thanks for such a quick reply!!
PS it was on line 266 however
#6
Great, thanks for checking it out for me. I can commit this now.
#7
my pleasure, thanks for such a quick and effective fix
#8
Committed. It's always nice to have someone actually test a fix.
#9
Thanks a lot for the patch, not only the error messages are gone, in our case it also dealt with random displaying-or-not of taxonomy images in lists!
#10
Thanks NancyDru, patch in #4 worked!
#11
It is now part of the -dev release so it does not need to be patched.
#12
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.
#13
Same issue if using taxonomy_image_attach module because path stored in image NOT relative to category_image folder
#14
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
#15
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
<?php$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:
<?php$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.
#16
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.
#17
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.
#18
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
#19
change at #4 fixes for me. subs
#20
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)
#21
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?
#22
#4 fixes the problem on D6
#23
subscribing
#24
subscribing
#4 fixes the problem
#25
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:
<?php$img = getimagesize($image[$tid]->url);
?>
to:
<?php$img = getimagesize(rawurlencode($image[$tid]->url));
?>
Fixed it for me.
#26
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:
<?php$img = getimagesize($image[$tid]->url);
?>
Rather change line 243 to include rawurlencode only on the filename:
<?php$image[$tid]->url = file_create_url($mypath . rawurlencode($image[$tid]->path));
?>
#27
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/defa...) [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
#28
This one (#27) didn't work for me.
#4 works OK on Drupal 6.14
#29
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...
#30
Because it won't accept SWF files.
Let's see some testing and reviewing on the actual patch and someone mark it RTBC.
#31
subscribe
#4 fixes the problem
#32
Many thanks it works for me
#33
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 ;)
#34
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]->pathcontains 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
#35
#4 worked for me! thanks!
#36
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.
#37
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.#38
Scratch that. Setting "needs review" to make sure that NancyDru catches the updated patch above.
#39
@xurizaemon - are you looking for is_readable() ?
#40
@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().
#41
Here is a version of the is_readable patch that works with 6.x-1.6
#42
The patch in #41 worked perfectly for me on 6.x-1.6 behind htauth and with language switching by path prefix enabled. Thanks!
#43
ran into the same problem after updating, patch #41 works for me, thanks
#44
is readable patch in #40 works for me
#45
#41 works for me, thanks!
#46
subscribing
#47
So many patches... Which one do we use?
#48
#41
#49
Hello,
When this patch will be applied to this great module. Is there anyone here to maintain it?