Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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.
Comment | File | Size | Author |
---|---|---|---|
#6 | image_resize_filter_empty-filename.patch | 6.87 KB | Jim Kirkpatrick |
#2 | image_resize_filter_encoding.patch | 877 bytes | quicksketch |
Comments
Comment #1
quicksketchThanks, 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.
Comment #2
quicksketchI'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.
Comment #3
quicksketchComment #5
Jim Kirkpatrick CreditAttribution: Jim Kirkpatrick commentedHi, 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&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?:
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.
Comment #6
Jim Kirkpatrick CreditAttribution: Jim Kirkpatrick commentedAttached 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.
Comment #7
quicksketchWe already have the following checks in place:
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.