Images won't be optimized when used with s3fs [#2759277]

When processing an image through ImageAPI Optimize virtual toolkit and using as destination Amazon S3 (using s3fs module), image will get saved directly to s3fs without ever running through the optimizers. Tried with png image + optipng.

A debugging session showed that image_gd_save() will put the image in s3, then image_imageapi_optimize_save() will get a URL with 's3://' stream wrapper for $dst. Calling drupal_realpath() on that URL won't return a valid path/URL. This means ImageAPI Optimize doesn't support stream wrappers. Yet ;).

Comment	File	Size	Author
#10	imageapi_optimize-2759277-10.patch	1.55 KB	Steven Jones
#10	7.x-2.x: PHP 5.6 & MySQL 5.5, D7 No tests found
#2	2759277-support-remote-stream-wrappers-02.patch	1.36 KB	jedihe
#2

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

1 July 2016 at 13:56

jedihe created an issue. See original summary.

Comment #2

jedihe CreditAttribution: jedihe as a volunteer commented 1 July 2016 at 14:09

Status:

Active

» Needs review

File	Size
2759277-support-remote-stream-wrappers-02.patch	1.36 KB

image_gd_save() uses a workaround to properly support remote stream wrappers. I just took the code handling that and transplanted into image_imageapi_optimize_save(). Quick testing showed it working just fine (optipng, with an image style not applying any effect to just get it going through the pipeline).

Patch is attached.

Comment #3

Steven Jones CreditAttribution: Steven Jones at ComputerMinds commented 3 July 2017 at 05:57

Status:

Needs review

» Needs work

This is pretty cool!

Needs a little clean up, because we can ignore the $success return value from our attempt at saving I think.

Comment #4

3 July 2017 at 05:57

Steven Jones committed 2d65789 on 7.x-1.x authored by jedihe

Issue #2759277 by jedihe: Images won't be optimized when used with s3fs

Steven Jones committed 72c58fc on 7.x-1.x

Issue #2759277 by Steven Jones: Images won't be optimized when used with...

Comment #5

Steven Jones CreditAttribution: Steven Jones at ComputerMinds commented 3 July 2017 at 05:57

Status:

Needs work

» Fixed

Comment #6

Vacilando CreditAttribution: Vacilando as a volunteer commented 4 July 2017 at 19:49

This may be needed for 7.x-2.x — or isn't it?

Comment #7

Steven Jones CreditAttribution: Steven Jones at ComputerMinds commented 5 July 2017 at 05:53

Version:	7.x-1.x-dev	» 7.x-2.x-dev
Status:	Fixed	» Patch (to be ported)

@Vacilando Yep, spot on. We have the same issue in 7.x-2.x.

Comment #8

Steven Jones CreditAttribution: Steven Jones at ComputerMinds commented 5 July 2017 at 09:45

And likely 8.x-2.x too.

Comment #9

Steven Jones CreditAttribution: Steven Jones at ComputerMinds commented 6 July 2017 at 05:57

For 7.x-2.x I think we should modify imageapi_optimize_optimize_file so that if the file is in a remote filesystem we copy it to the temporary one, then let the processors process, and then save it back to the remote filesystem after all processing.

Some of the processors could probably copy with being passed a remote file and still work fine, but it's probably an implementation detail best hidden from them.