Bug with TimberImage resize if image from URL

[EugeneCib]

There is a bug in TimberImage after last update (0.20.10) when used with URL.
Example TimberImage('url_here').src|resize(330,330)

For first time, image will be resize correctly and in uploads folder shows up resized versions of image. Next time, when line executed for same image - error occur: Warning: fopen(http://domain//content/uploads/2015/03/6a76a3a54df99852db8f759b974d7384-330x330-c-default.jpg): failed to open stream: HTTP wrapper does not support writeable connections in directory\wp-includes\class-wp-image-editor.php on line 424

Many random simbols are printed in same time.

[lmartins]

I've seen this also yesterday and couldn't figure out what was happening. The way I get around it was by removing and adding the affected images back. From that point onwards it worked fine, so not sure what is going on.

[lmartins]

Im having a lot of issues today with this problem, any updates please...

Complete error message from New Relic:

Error message
E_WARNING: fopen(http://flux.webipack.com/mw-public/uploads/sites/72/2015/03/17bb0b3b68b053d5835e342adafb0db1-65x65-c-default.jpg): failed to open stream: HTTP wrapper does not support writeable connections

Stack Trace:

Stack trace
…fopen called at /srv/wordpress/wordpress/wp-includes/
class-wp-image-editor.php (424)
…ge called at /srv/wordpress/wordpress/wp-includes/
class-wp-image-editor-gd.php (464)
…ge called at /srv/wordpress/wordpress/wp-includes/
class-wp-image-editor-gd.php (397)
…ve called at /srv/wordpress/wordpress/wp-includes/
class-wp-image-editor-gd.php (362)
…s/mw-public/plugins/timber-library/lib/image/
timber-image-operation-resize.php (104)
…rdpress/wordpress/mw-public/plugins/timber-library/lib/
timber-image-helper.php (414)
…rdpress/wordpress/mw-public/plugins/timber-library/lib/
timber-image-helper.php (40)
in TimberImageHelper::resize called at ? (?)
…ress/mw-public/plugins/timber-library/vendor/twig/twig/lib/Twig/
Environment.php(332) : eval()'d code (27)
…dpress/mw-public/plugins/timber-library/vendor/twig/twig/lib/Twig/
Template.php (289)
…dpress/mw-public/plugins/timber-library/vendor/twig/twig/lib/Twig/
Template.php (263)
…dpress/mw-public/plugins/timber-library/vendor/twig/twig/lib/Twig/
Template.php (274)
…ess/mw-public/plugins/timber-library/vendor/twig/twig/lib/Twig/
Environment.php (293)
…srv/wordpress/wordpress/mw-public/plugins/timber-library/lib/
timber-loader.php (69)
…called at /srv/wordpress/wordpress/mw-public/plugins/timber-library/
timber.php (287)
…called at /srv/wordpress/wordpress/mw-public/plugins/timber-library/
timber.php (321)
…lled at /srv/wordpress/wordpress/mw-public/themes/wip-roots/mdf/dash/
lists.php (66)
…losure} called at /srv/wordpress/wordpress/mw-public/plugins/jigsaw/
jigsaw.php (171)
in Jigsaw::{closure} called at ? (?)
…call_user_func_array called at /srv/wordpress/wordpress/wp-includes/
plugin.php (496)

[lmartins]

Just to add up to this.
I've also noticed that the first time the image it's shows it loads correctly, but after that it always shows the issue above.

[EugeneCib]

Same here. Because at first time cropped image version isn't in uploads folder, so (i think) it doesn't try reading it from there. When cropped version appears in uploads - error shows up.

[EugeneCib]

Same problem in this post, which marked as bug - following in there now #506

[lmartins]

The way I got around the issue for now is by using built-in image sizes, that is image.src('thumbnail'). It might no be a practical solution for your case but worths mentioning.

[JoaoSaleiro]

I'm having exactly the same issue.
My code:

    <img src="{{TimberImage(testimonial.get_field('picture')).src|resize(180,180)}}">

[gillesgoetsch]

I just wrote an update about my progress with this issue, independent of using output-buffering or not #506

[laurentvd]

Judging from the source code, I think 'something' else goes wrong and then

if($op->run($old_server_path, $new_server_path)) {
    return $new_url;
} else {
    // in case of error, we return source file itself
    return $src;
}

is run from timber-image-helper.php. I'm not 100% sure I understand everything correctly, but it seems it is loading the binary data of the image if the image is external content (line 434) and then returns that binary instead of the original value of $src which is a path.

[palmiak]

Is this bug still active? Please respond in two weeks or we'll close this thread.