I can't seem to stop my bloggers from using file names with spaces and other dubious characters in them, and when they do, I get the following error in the log over and over:

file_get_contents() [<a href='function.file-get-contents'>function.file-get-contents</a>]: Filename cannot be empty in /home/smartphonemag.com/public_html/iphone/sites/all/modules/image_resize_filter/image_resize_filter.module on line 464.

Adding a test just inside the foreach loop at line 461 solved the problem:

  foreach ($images as $image) {
    if (!$image['local_path']) continue;

(where the foreach is line 461 and the following line is added.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

quicksketch’s picture

Thanks, I'll have a try at this next time I'm working on Image Resize Filter. In the mean time, I suggest you install http://drupal.org/project/transliteration.

quicksketch’s picture

Status: Active » Fixed
FileSize
877 bytes

I'm not able to directly reproduce this problem, though I found a few similar problems caused by strange file names. The initial problem you're having is because the IMG tags used are not properly formed. I filed an issue over in the Insert queue if that's what you're using to insert images: #800524: Files with strange characters do not show up, URL-encode inserted URLs.

However even if image URLs are properly encoded in the HTML, Image Resize Filter does not encode the new image tags properly, causing the image not to show up even if it was successfully resized.

I'm marking this issue as fixed as I believe this corrects the problem as far as Image Resize Filter is responsible. If you can provide explicit instructions on how to reproduce the problem you're experiencing with the latest version of Image Resize Filter I'd be happy to take another look.

quicksketch’s picture

Title: file_get_contents argument cannot be empty in line 464 » Resized image URLs need to be encoded

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Jim Kirkpatrick’s picture

Title: Resized image URLs need to be encoded » Resized image URLs need to be encoded/sanity checked
Status: Closed (fixed) » Needs work

Hi, I'm still getting a very similar error with filenames in 6.x-1.9 so am re opening...

Essentially, some of my client's contributors are pasting content OR content is being pulled in via RSS and put into nodes. Some of this content has images embedded that have the strange filename problems above...

The error is:
warning: file_get_contents() [function.file-get-contents]: Filename cannot be empty in [snip]/sites/all/modules/image_resize_filter/image_resize_filter.module on line 500.

And the HTML in the body causing the error is:
<p><img alt="" style="display: none;" width="1" height="1" src="http://transitionculture.org/wp-content/plugins/feed-statistics.php?view=1&amp;post_id=3820"></p>

Looking at line 500, the problem is that if an image comes in without a name - due to whatever snaffu happens along the way - this module isn't sanity checking the filename before sending it to file_get_contents(). Perhaps just add an if around the whole inner of the for loop to throw out these broken images and make the module robust?:

...
  foreach ($images as $image) {
    if (!empty($image['local_path'])) {
...
...
    }
  }

Or you may have a better idea... Anyway, sorry to re-open a not-quite-identical issue but the same chunk of code is still broken at present. Can certainly move to a new issue if you ask.

Jim Kirkpatrick’s picture

Status: Needs work » Needs review
FileSize
6.87 KB

Attached is a patch of my above comment - it kills the errors on our site. Most of the changes are from the indentation of the extra IF, there's actually only 2 lines changed.

quicksketch’s picture

Title: Resized image URLs need to be encoded/sanity checked » Resized image URLs need to be encoded
Status: Needs review » Closed (fixed)

We already have the following checks in place:

    // Get the image size.
    if (is_file($local_path)) {
      $image_size = @getimagesize($local_path);
    }

    // All this work and the image isn't even there. Bummer. Next image please.
    if (empty($image_size)) {
      image_resize_filter_delete_temp_file($location, $local_path);
      continue;
    }

This means that it should be impossible for $local_path to be empty, since if the file isn't found we immediately stop processing.

However, we had a problem where we weren't resetting $image_size for each image, meaning that if $local_path was empty or failed, the previous image's size would be used. This has been fixed in #981082: May attempt to resize non-existent images and should by effect prevent this problem also. I'm closing this issue directly since I do think it's largely unrelated to the original issue here.