Image Resize Filter may create broken paths if height/width attributes are not available

Great.....

Thanks for the report. I'll look into this soon, but any other users experiencing this problem that are capable of fixing it, I'd encourage them to submit patches to get this fixed quicker.

I see a similar error with drupal 7.0 and image resize filter 7.x-1.12. It appears that the destination is not getting set properly to the local path of the image?

I see this on any page where there is a small icon for printer friendly pages, as well as any admin page, where there is a small icon to add/remove from default shortcuts. That is, the error shows up even if I have not added any images to the page:

Warning: imagegif() [function.imagegif]: Unable to open '://resize/image-10x11.gif' for writing: No such file or directory in image_gd_save() (line 281 of /home/myusername/public_html/modules/system/image.gd.inc).

The issue seems to appear from links with the following form on my site:

http://mysitename/sites/all/modules/print/icons/print_icon.gif

Which I think would probably be linked to the code in image_resize_filter.module around line 332 . There is no match to 'system/files' so the local path does not get set properly. ???

 // Convert to a file system path if using private files.
      elseif (preg_match('!^(\?q\=)?' . $lang_codes . 'system/files/!', $local_path)) {
        $local_path = 'private://' . preg_replace('!^(\?q\=)?' . $lang_codes . 'system/files/!', '', $local_path);
      }
      $local_path = rawurldecode($local_path);
    }

    // If this is an Image preset, generate the source image if necessary.
    // Formatted as "uri://styles/[style-name]/[schema-name]/[original-path]".
    $image_style_matches = array();
    $scheme = file_uri_scheme($local_path);
    if (!file_exists($local_path) && preg_match('!^' . $scheme . '://styles/([a-z0-9_\-]+)/([a-z0-9_\-]+)/(.*)$!i', $local_path, $image_style_matches) && function_exists('image_style_path')) {
      $style_name = $image_style_matches[1];
      $original_path = $scheme . '://' . $image_style_matches[3];

Getting hundreds of these warnings a day now.

Warning: imagejpeg() [function.imagejpeg]: Unable to open '://resize/Pete_with_Joe_F-550x448.jpg' for writing: No such file or directory in image_gd_save() (line 272 of /mnt/stor2-wc1-dfw1/394720/www.ivaw.org/web/content/modules/system/image.gd.inc).

Might my file system setup have something to do with it?
http://awesomescreenshot.com/009hdxsdc

This may look like a mess, but it's a backtrace of a blog post that is throwing this warning.

Warning: imagejpeg() [function.imagejpeg]: Unable to open '://resize/Maggie_Martin-106x189.JPG' for writing: No such file or directory in image_gd_save() (line 272 of /mnt/stor2-wc1-dfw1/394720/www.ivaw.org/web/content/modules/system/image.gd.inc). Backtrace:
imagejpeg(Resource, '://resize/Maggie_Martin-106x189.JPG', 75) image.gd.inc:272
image_gd_save(Object, '://resize/Maggie_Martin-106x189.JPG') 
call_user_func_array('image_gd_save', Array) image.inc:97
image_toolkit_invoke('save', Object, Array) image.inc:391
image_save(Object, '://resize/Maggie_Martin-106x189.JPG') image_resize_filter.module:500
image_resize_filter_process_images(Array, '

--BODY TEXT--
[empty-para]
--BODY TEXT--

', Array) image_resize_filter.module:68
image_resize_filter_process_filter('

-- REPEAT BODY TEXT--
[empty-para]
-- REPEAT BODY TEXT--

', Object, Object, 'und', , '') filter.module:758
check_markup('

-- REPEAT BODY TEXT 2--


', '1', 'und') text.module:319
_text_sanitize(Array, 'und', Array, 'value') text.module:264
text_field_formatter_view('node', Object, Array, Array, 'und', Array, Array) field.default.inc:211
field_default_view('node', Object, Array, Array, 'und', Array, Array, NULL) field.attach.inc:198
_field_invoke('view', 'node', Object, Array, NULL, Array) field.attach.inc:375
_field_invoke_default('view', 'node', Object, Array, NULL, Array) field.module:900
field_view_field('node', Object, 'body', Array, 'und') views_handler_field_field.inc:749
views_handler_field_field->set_items(Object, 4) views_handler_field_field.inc:602
views_handler_field_field->post_execute(Array) view.inc:564
view->_post_execute() view.inc:941
view->execute(NULL) view.inc:960
view->render() views_plugin_display.inc:2362
views_plugin_display->preview() view.inc:1103
view->preview() views_panes.inc:291
views_content_views_panes_content_type_render('group_content_teaser_listing-panel_pane_1', Array, Array, Array, '') content.inc:278
ctools_content_render('views_panes', 'group_content_teaser_listing-panel_pane_1', Array, Array, Array, Array) panels_renderer_standard.class.php:532
panels_renderer_standard->render_pane_content(Object) panels_renderer_standard.class.php:473
panels_renderer_standard->render_pane(Object) panels_renderer_standard.class.php:454
panels_renderer_standard->render_panes() panels_renderer_standard.class.php:375
panels_renderer_standard->render_layout() panels_renderer_standard.class.php:346
panels_renderer_standard->render() panels.module:706
panels_display->render(Object) panels.module:1034
panels_render_display(Object, Object) panel_context.inc:285
panels_panel_context_render(Object, Array, Array) context-task-handler.inc:103
ctools_context_handler_render_handler(Array, '', Object, Array, Array) context-task-handler.inc:44
ctools_context_handler_render(Array, '', Array, Array) node_view.inc:88
page_manager_node_view_page(Object) 
call_user_func_array('page_manager_node_view_page', Array) menu.inc:503
menu_execute_active_handler() index.php:21

Does the problem persist while updating to 7.7? I was thinking of upgarding my site from 7.2 to 7.7....if this problem persists, then may be i will have to wait till a solution is found!!

Haven't been able to upgrade yet, not sure.

I'm going to spend some time today to try and figure out the cause of this.

I have a copy of my site from a few weeks ago and everything works fine on it. So I've compared the enabled modules between the broken and working site. On the broken site I has these modules enabled, that were not enabled on the working site.

Commerce Devel
Hacked
Reroute emails
Field Permissions
Fielfield Soucces
Pathologic
Better Formats
Fast 404
Forgotten Login
Redirect
Rules
Rules Scheduler
Rules UI
Google Analytics
Views Bulk Operations
Webform
Webform Validation

I'm going to start playing around with them to see if I can get this bug to go away.

Turned out to be the Fast 404 module. AJ2 re-open this if you are still having problems.

#1200876: Image Previews not being generated

Turns out I was wrong. Fast 404 was causing problems with images, but it was not this problem. Back to the testing grounds :)

I've figured this out!

Node Edit

<img alt="" class="caption" src="http://www.ivaw.org/sites/default/files/images/users/Jose_Vasquez/Brian_Hannah.jpg" style="width: 688px; height: 416px;" title="Warriors for Peace by Jon Orlando" />

Node View

<img alt="" class="caption caption-processed quimby_search_image" src="http://www.ivaw.org/%3A//resize/Brian_Hannah-688x416.jpg" title="Warriors for Peace by Jon Orlando" style="width: 688px; height: 416px; ">

The problem lies in the style="width: 688px; height: 416px;". If I remove that then the problem goes away!

It does not appear that this module is properly handling height and width settings when they are set inline on the image with the styles tag.

Now that we know the root of the problem, how can we fix it?

Adding summary

Cleanup

Cleanup

Date correction

Note about WYSIWYG editors

Cleaning up the title and added an issue summary at the top.

I recently upgrade my site from D6 to D7.

The nodes on D6 were created using the CKEditor module.
The nodes on D7 are created using WYSIWYG - CKEditor.

On D7 I'm running with WYSIWYG 7.x-2.1 and CKEditor v3.6

Let me know if there is any more information I can provide or testing I can do to help out.

On D6 I was using the CKEditor 6.x-1.1 with CKEditor v3.2.1

However I had been using CKEditor since nearly the day it was released for drupal, so I'm sure I wasn't always on v3.2.1.

Image Resize Filter should work fine with style attributes, but you have to make sure that Image Resize Filter runs after the "HTML Filter", which strips out "style" attributes. If you could double-check the ordering of your filters, that might provide some additional insight. The ordering of filters is more clearly explained in the README.txt file.

I'm using the wysiwyg filter module and I was allowing the style's attribute to pass on purpose. I've gone ahead and disallowed it. Obviously that has resolved the issue :)

I guess it's just a limitation of Image Resize Filter, not a big deal but it did drive me crazy for a couple days.

I am also using the wysiwyg module with the CKEditor, but the error I see appear on admin pages and other pages where I have never used the CKEditor. I should mention that the errors only appear if Configuration -> Development -> Logging and Errors -> Errors and Warnings are set to be displayed.

I guess it's just a limitation of Image Resize Filter, not a big deal but it did drive me crazy for a couple days.

As I said in #20, Image Resize Filter works perfectly well with style attributes. You just have to make sure that Image Resize Filter comes before other HTML filters that remove the style attribute. Obviously we can't use height/width style properties if they've already been stripped out by other filters.

Turns out spamspan was ahead of the image resize filter for the Filter processing order for all of my text formats and that was causing the issue. May be good to add to the README, that the image resize filter must be run before spamspan.

spamspan isn't part of core. Adding that to the readme.txt would make users who didn't install that module look for something they don't have.

This is a fairly common issue with filters and needing to place them in a logical order.

All users in this issue with this problem should test moving the filter around. For example, setting it near the top of the chain. If it works as expected at that point then continue to move it down the chain until it stops working.

Yes, finding a logical order can be a bit tedious but there's little that can be done about that in each module that provides extra filters.

There also appears to be another weird problem, possibly related. I noticed that my RSS feed was throwing some of these errors. It appears if you access a page like this "www.mywebsite.com" the image URL's can become malformed like in #13. But if you access it from "mywebsite.com" then everything looks fine. For now I've changed my htaccess file to redirect people to the non-www version.

In the last hour I've had no more errors. Looks like this does has something to do with the www being present.

Agreed that it makes sense, that if it is not part of core then to not list the filter. I was just following the example already in the readme and webpage. I did not realize that BBCode and Pathologic were part of core, which are listed in the readme with respect to filter order.

patches to the readme.txt are welcome and a great way to learn and get started with making the changes you want.

I actually disagree with the other non core modules that provide filters being listed in the readme.txt for the reason I've already given. ;)

For anyone curious and too lazy to open README.txt, here's the current description:

4) IMPORTANT: Re-order your enabled filters under "Filter processing order".

   If using the Image Resize Filter on the "Filtered HTML" text format, you
   MUST ensure A) that the <img> tag is in the list of allowed tags and B) The
   "Image resize filter" is run BEFORE the "HTML filter".

   If using the Image Resize Filter with BBCode or some other non-HTML filter,
   the "Image resize filter" must be run AFTER the BBCode filter. If using
   Pathologic (http://drupal.org/project/pathologic), Image Resize Filter must
   be run AFTER the Pathologic filter too, since Pathologic must correct image
   path locations for Image Resize Filter to find the images.

I'm not very concerned with updating the README further personally. I think if you can't figure it out with this much information then adding more isn't going help. I'm more concerned with how we can prevent the completely broken paths described in #13.

Hmm, okay upon trying to reproduce this I still can't figure out what causes the problem. I need more information on how to reproduce this from a clean install. @animelion mentions that he's using WYSIWYG Filter, but I don't know what configuration of that module in conjunction with Image Resize Filter is causing the problem.

So basically, I don't think we know the root of the problem yet. Attempting to reproduce the problem as described in #13 I don't have any problem at all. It must be the use of style attributes in conjunction with configuration from another module.

I have the same bug "Unable to open ://resize/ ..." but i have no clue what is causing this problem. I deactivated everything around filter exept image resize filter but without success. On a second site with same installed modules i have no problems. It's a little bit strange.

I was getting those resize notices when my URL's were being accessed with www in them, so I changed my htaccess to redirect people to pages without the www and most of these "resize" problems cleared up.

In my case i could find out the problem. Broken images were not located in the defined directory for public or private files. Because of this file_uri_scheme() always returns false and image_resize_filter_pathinfo() builds incorrect pathes.

Runnin 1.13 with Drupal 7.12, version 1.6 of the ckeditor module, and version 3.6.2 of ckeditor, and I get the error message for any image added to a node via ckeditor that is a smaller size than the original.

Warning: imagejpeg() [function.imagejpeg]: Unable to open '://resize/pic1.jpg' for writing: No such file or directory in image_gd_save() (line 272 of /opt/apache/htdocs/drupal/modules/system/image.gd.inc).

My filters are arranged as such:

Image resize filter
Convert URLs into links
Convert line breaks into HTML
Correct faulty and chopped off HTML

I cannot seem to figure out what module might be causing this issue. Where does the "://resize/" come from? Is there supposed to be a resize directory underneath my files directory? There wasn't, but I created one with full perms and that didn't help. All of the images that are in ckeditor are using paths of the format "/sites/sitename/files/pictures/pic1.jpg". Is there anything that seems out of place with my setup?

Thanks - this looks like exactly what I need for a client, but I just cannot seem to get it to work. With so many people using it, however, it would seem this problem is only affecting a minority of people.

Hmmm... well I seem to have fixed my problem. I must admit, I was not using the proper method to troubleshoot - i.e. trying one thing and retesting to figure out what exactly fixed the issue. However, I believe changing my "public file system path" (under /admin/config/media/file-system) fixed the issue. I run multi-site, and I tend to make symbolic links under the sites directory for the sake of ease. For example, I might have a client whose domain is www.myverylongcompanyname.com. In that example, I would probably create the site under the "sites/mvlcn" and then create a symbolic link "myverylongcompanyname.com" that points back to "mvlcn" in the same sites directory.

In my "public file system path" setting, I had put in "sites/myverylongcompanyname.com/files" (in other words, I used the symbolic link to get to the directory). I changed this to "sites/mvlcn/files" (the actual directory instead of the symbolic link).

I tweaked other things at the same time, unfortunately, but thinking back, I really think this is the only change that could've done the trick. Is it possible this fixed the issue? Is the problem simply with symbolic links in the public file system path?

Well, I wrote all of that out and then decided "DUH!" I can switch it back and retest. So I did just that. Things seemed to still be ok (before the images wouldn't show up at all while viewing a node - now they were still showing). But as soon as I added another image to the node and resized it, the errors and missing images returned. I then set my file path back to the non-symbolic path, and everything worked beautifully once again.

So, I do not know if this is the cause of the issue for everyone else running into this problem, but it sure was the cause for mine. I am not entirely sure if it was the fact that there was a symbolic link in the path, or maybe it was just that my public file path was different from the path that my images were using from within ckeditor, but all is well now! Hope this helps - perhaps there is a way to fix the module to prevent this problem, or else perhaps just a note in the readme will suffice.

I will leave that up to the professionals. Thanks - this truly IS a great project!

I am having this same problem and it's not symbolic links, because I am not using those. I am using CKEdior with WYSIWYG and KCFinder (all the latest versions for Drupal 7). I'm trying to get something launched and can't seem to find a solution. At this point I'm just going through the code to see if I can hard code the upload URL I want for now.

It would be nice, for future releases, to provide an option where we can specify the upload directory manually. Thank you!

PS Here are the two lines I edited to make it work for my site, at line 481 (note I am not using remote files):

// $local_file_path = 'resize/' . ($local_file_dir ? $local_file_dir . '/' : '') . $path_info['filename'] . '-' . $image['expected_size']['width'] . 'x' . $image['expected_size']['height'] . '.' . $path_info['extension'];
// $image['destination'] = $path_info['scheme'] . '://' . $local_file_path;
$local_file_path = 'path/to/images/resize/' . ($local_file_dir ? $local_file_dir . '/' : '') . $path_info['filename'] . '-' . $image['expected_size']['width'] . 'x' . $image['expected_size']['height'] . '.' . $path_info['extension'];
$image['destination'] = $local_file_path;

I know it's not a long-term fix or pristine code, I just needed to get something up right now.

hi
i have
drupal 7.11 core
ckeditor
ckfinder

i install your module but my first question is, where i can set widht and height ?? in admin module just 3 option
1) local
2) remote
3) style

anyway after the upload the html cose is

why not apply a changes??

ps
i have many module and all work fine

thanks

Like the OP, I had this same issue with my image resize filtered paths containing "/%3A//resize/" despite my filters being in the right order as quicksketch suggested.

Ultimately the cause of my issue was the path of the original images was set to the old site's files path - even though the image still existed there, the path of the resized images must of got fubared somehow (my guess is, imageresize_filter uses the path to work out the storage path perhaps).

The reason the old path was in there, was because I did a clone of the site in Aegir, which itself, isn't going to filter image paths in node content?

The fix was just to edit each node and fix the image path to be of the actual site's path. If you have a large site, you could probably fix this with a mysql replace() query.

So, just a FYI for others out there, cloning in aegir and using this module. Cheers, and great module btw!

The suggested patch in #39 solve my problem... i know it is not clean but if someone could provide a patch who grab the files path of Drupal it could work on any installation. I have not the skill for that but if someone could check to make it work it would be nice...

We also have the same error after do an export from another drupal 7 site, and import the node datas to the current drupal 7 site.

Here is my quick solution (developers needs to be checked):

/sites/all/modules/image_resize_filter/image_resize_filter.module this is from line 469 to 484
affected line: 482 $image['destination'] = $path_info['scheme'] . '://' . $local_file_path;
quick fix line: 483 $image['destination'] = $image['local_path'];

    if ($image['location'] == 'remote') {
      $local_file_path = 'resize/remote/' . md5(file_get_contents($image['local_path'])) . '-' . $image['expected_size']['width'] . 'x' . $image['expected_size']['height'] . '.'. $image['extension'];
      $image['destination'] = variable_get('file_default_scheme', 'public') . '://' . $local_file_path;
    }
    // Destination and local path are the same if we're just adding attributes.
    elseif (!$image['resize']) {
      $local_file_path = '';
      $image['destination'] = $image['local_path'];
    }
    else {
      $path_info = image_resize_filter_pathinfo($image['local_path']);
      $local_file_dir = file_uri_target($path_info['dirname']);
      $local_file_path = 'resize/' . ($local_file_dir ? $local_file_dir . '/' : '') . $path_info['filename'] . '-' . $image['expected_size']['width'] . 'x' . $image['expected_size']['height'] . '.' . $path_info['extension'];
//    $image['destination'] = $path_info['scheme'] . '://' . $local_file_path;
      $image['destination'] = $image['local_path'];
    }

I hope this will help you :)

Have fun!
András

Had the same problem, hope to find time to fix it permanently!

From what I can see in #34, #35, and #41, this problem still only occurs when the original file has been moved/deleted. Anyone that is having this problem *please* describe how to reproduce the issue. For now I'm still in the dark about the source of this problem, other than in situations where files can't be found to begin with.

We encountered the problem when changing a multisite from sites/domain.ext to sites/domain with it's full domain name in sites.php.

0. Create a node with an inline image, filtered by Image Resize Filter
1. Rename the site folder
2. Change the file_public_path to the new name
3. Create a symlink to the old name to prevent missing inline images

This works for sites without Image Resize Filter. With the filter enabled, the image won't show in the front-end until you change the file location to the new path in the body of the node.

Disclaimer: I've written this from memory. Unfortunately, I can't double check it right now ...

I had the same error, here is a small patch that worked for me.
You can try it out and see.

Clarity

I am also affected by this bug (or so I think), but only when I call the image from a VB application or Linux wget (and I get a "HTTP request sent, awaiting response... 503 Service unavailable").
When I load them in a browser (even just the image, e.g. right click, "view image") they works fine.
What I found:
- if I left the image without width/height they works fine;
- If I (cck-editor) set the width/height, either to a lower number so that the image is actually resized, or it leaves to the natural image size, so that the image is not actually resized, I got the 503 error on direct download.

I am on a FreeBSD system.

[EDIT] I found the cause leading to this behaviour, I post it here as it may be useful for other people.
In my case the problem was putting the site under maintenance mode and then putting it back to normal.
To have the images be downloadable by wget I had to, after putting the site back to normal, unckeck the options is site optimisation under /admin/config/development/performance, save and then I could put them back again.

checker in #35 nails it. Image resize filter will only resize images from a known file_get_stream_wrappers() location. For typical Drupal, that is one of the following:

Public files
Private files
Temporary files

If image_resize_filter_pathinfo() exits with scheme set to false (i.e., it could not determine which stream wrapper to use) then ca. line 482 naively builds the path with 'false' as the stream wrapper:

$image['destination'] = $path_info['scheme'] . '://' . $local_file_path;

The patch in #48 solves this problem by essentially setting the default scheme to be the Public files directory.

Which is fine unless you are running a private-files-only scenario.

Just found an interesting situation where this issue is occurring. We recently upgraded to CKEditor 4.3.3, and noticed we started receiving this error message:

Warning: imagegif(): Unable to open '://resize/regular_smile-20x20.gif' for writing: No such file or directory in image_gd_save() (line 280 of /modules/system/image.gd.inc).

It seems as though in CKEditor 4.3, they changed their smiley emoticons to be .png files rather than .gif. The .gifs still exist in same directory (/ckeditor/plugins/smiley/images), but if a user attempts to insert a smiley into a post, it uses the .png files by default.

If we open an existing post and delete the .gif smiley, re-insert from CKEditor, and save the post, we no longer see the error. The error also goes away if we remove the height/width values on the .gif smiley image. However if we manually edit the post and point to the original .gif file, and have height/width set, the errors return as soon as the post is saved. This is what we see rendered in the HTML when we get the errors:

<img width="20" height="20" title="smiley" style="width: 20px; height: 20px;" src="http://www.domain.com/%3A//resize/regular_smile-20x20.gif" alt="smiley">

We are running a version of the site with CKEditor 4.1.2 and the exact same Image Resize Filter configuration (listed first in the input formats), and have no issues there.

OK, finally I think I have a scenario to reproduce. In fact I have two - an easier one that maybe isn't so realistic and a more complex one that's the one I actually hit.

The problem seems to be that image_resize_filter_pathinfo assumes it will find a scheme but it won't for "shipped files" (see file_create_url documentation second bullet).

1) Easier.

• Create text format that has image resize filter, but nothing that would filter out tags.
• Create some content using this text format.
• Add in an image with source equal to the theme default logo and specify a width. (Example below, but not sure if it will work as it's full of HTML tags.)

<p><img src="/themes/bartik/logo.png" style="height: 84px; width: 88px;" /></p>

• Click save and the error appears.

2) Less simple but maybe more likely in real life.

• Install modules simplenews and mimemail plus dependencies.
• On /admin/config/system/mailsystem set Simplenews module class to MimeMailSystem.
• On /admin/config/system/mimemail set a text format that includes image resize filter.
• On /admin/config/services/simplenews/settings select format = HTML.
• Possibly some more newsletter config steps - I can't say for sure I have a definite list.
• Edit simplenews-newsletter-footer.tpl.php to include the site logo with a width.
• Create content of type newsletter.
• Click newsletter tab and then send a test message and the error appears.

Another scenario is linking to one of the core File module's icons, such as "/modules/file/icons/application-pdf.png". This is also common if you use the Media module and embed a file link in a WYSIWYG.

I think this may be solved by committing #2474757-2: Empty getDirectoryPath causes issues in image_resize_filter_pathinfo.

@joelstein thanks for the patch.

I can confirm it solves scenario 1) from #52.

You cannot set it to "Reviewed and tested" if the patch is in another issue.

#2474757: Empty getDirectoryPath causes issues in image_resize_filter_pathinfo