From time to time I've come across images that fail -- creating a list here to see if we can't fix them eventually

• https://www.staysafe.org/files/2018/01/unplugged.jpg

Fixes #16.

It turns out that even when cURL is installed, the curl_multi_init() function may be disabled on some hosts who are seeking to guard against DDoS attacks. See https://github.com/ampproject/amp-wp/pull/2183#issuecomment-491506514.

This PR modifies FasterImage::batch() to check if cURL multi is available, and if not, it falls back to doing plain curl_init() calls to obtain the images sequentially.

I have a image that is EXIF orientation 49. That is obviously an invalid value, and the image itself has the correct dimensions otherwise. It should report it as not rotated, but is reporting it as rotated. I think https://github.com/willwashburn/fasterimage/blob/master/src/FasterImage/ExifParser.php#L74 should be changed from return (! empty($this->orientation) && $this->orientation >= 5); to return (! empty($this->orientation) && $this->orientation >= 5 && $this->orientation <= 8); to better handle all of the bogus images out there.

The AMP plugin for WordPress patches FasterImage to add support for extracting dimension information from SVG images:

https://github.com/ampproject/amp-wp/blob/4228eee8332c109eff62df5dba0ae4d7c4137ef2/patches/fasterimage-fixes.diff#L51-L115

It is admittedly somewhat non-sensical to obtain dimensions from SVGs since they are vector images. Nevertheless, when there is an SVG image like:

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 36 36" width="36" height="36"><circle fill="#FFCC4D" cx="18" cy="18" r="18"/><path fill="#664500" d="M10.515 23.621C10.56 23.8 11.683 28 18 28c6.318 0 7.44-4.2 7.485-4.379.055-.217-.043-.442-.237-.554-.195-.111-.439-.078-.6.077C24.629 23.163 22.694 25 18 25s-6.63-1.837-6.648-1.855C11.256 23.05 11.128 23 11 23c-.084 0-.169.021-.246.064-.196.112-.294.339-.239.557z"/><ellipse fill="#664500" cx="12" cy="13.5" rx="2.5" ry="3.5"/><ellipse fill="#664500" cx="24" cy="13.5" rx="2.5" ry="3.5"/></svg>

And it is added to a page without width or height attributes:

<img src="http://wordpressdev.lndo.site/content/uploads/smiley.svg">

It will get rendered with those dimensions defined in the SVG file:

The FasterImage library is used in the AMP plugin to supply width and height attributes for any img that lacks it in the HTML document. By supplying the dimensions, a better user experience results by avoiding content shifting as images are loaded into the page. (This is why AMP requires the dimensions.) Including support for SVG helps to this end.

Note that this PR not only extracts the width and height attributes from the SVG image, but it also falls back to inferring (i.e. guessing) a width/height from the SVG viewBox.

~⚠️ There are two outstanding issues with this PR, however, and that has to do with SVG images that are extremely small. It turns out that the Stream library doesn't like handling SVG images that are smaller than 1024 bytes. I took a shot at working on a patch in https://github.com/ampproject/amp-wp/pull/1807/files but you probably have a better approach in mind. Notes from that PR:~

The problem turns out to be an issue with FasterImage and how it was modified in https://github.com/ampproject/amp-wp/pull/1150 to allow extracting pixel dimensions from SVG images. The problem is that it is attempting to read 1024 bytes of data from the image, but the above SVG is only 525 bytes long. This results in a WillWashburn\Stream\StreamBufferTooSmallException exception being thrown, and the image size failing to be obtained, and thus the fallback image size is being used (which is obviously too big).

Todo

• [x] Add tests.
• [x] Address issue with reading tiny SVG images.

Starting a new PR from branch on origin repo. See #17.

Fixes #16.

It turns out that even when cURL is installed, the curl_multi_init() function may be disabled on some hosts who are seeking to guard against DDoS attacks. See https://github.com/ampproject/amp-wp/pull/2183#issuecomment-491506514.

This PR modifies FasterImage::batch() to check if cURL multi is available, and if not, it falls back to doing plain curl_init() calls to obtain the images sequentially.

It turns out that even when cURL is installed, the curl_multi_init() function may be disabled on some hosts who are seeking to guard against DDoS attacks. See https://github.com/ampproject/amp-wp/pull/2183#issuecomment-491506514.

Would it be feasible to check if this function exists in FasterImage::batch(), and if not, fallback to doing plain curl_init() calls to obtain the images sequentially?

http://gluesticksgumdrops.com/wp-content/uploads/2015/03/how-to-find-more-time-to-read-to-your-kids.jpg

Could not be parsed for some reason. Something isn't right in the exif parsing. The byte order is showing up as * here: https://github.com/willwashburn/FasterImage/blob/master/src/FasterImage/ExifParser.php#L80

In the AMP plugin for WordPress, the user agent, buffer size, and SSL host/peer verification are overridden.

The user agent is overridden to indicate the actual source as opposed to emulating Chrome:

https://github.com/ampproject/amp-wp/blob/158855dc3349e1e18099dba959ab49dedf806ff6/includes/utils/class-amp-image-dimension-extractor.php#L216-L217

(Disregard the @todo comment as we have implemented in a patch we apply.)

This PR applies the patch to fasterimage itself so that it can be passed via a new setUserAgent() setter method.

Similarly, the AMP plugin is patching the buffer size, SSL peer verification, and SSL host verification:

https://github.com/ampproject/amp-wp/blob/4228eee8332c109eff62df5dba0ae4d7c4137ef2/patches/fasterimage-fixes.diff#L35-L40

By class member variables and setter methods, patching in this way will no longer be required.

We have an image that has an orientation of 49 which isn't even a valid value. I am not able to give the image because it is a customer's image and I do not have permission to share it.

An issue has come up a couple times in the AMP plugin:

• https://wordpress.org/support/topic/server-error-5xx-from-google-search-console/
• https://wordpress.org/support/topic/fatal-error-require-failed-opening-required-file/

The issue is that when someone has a large number of images in their content, FasterImage ends up triggering a “Too many open files” warning. This then eventually tries to throw an StreamBufferTooSmallException exception, but at this point there are too many files open and the autoloader is not able to load the class. The result is then a fatal error due to the the StreamBufferTooSmallException class not being found, as seen in these notices:

1. Warning: include(/home/meaganpu/public_html/wp-content/plugins/amp/vendor/willwashburn/stream/src/Stream/Exception/StreamBufferTooSmallException.php): failed to open stream: Too many open files in /home/meaganpu/public_html/wp-content/plugins/amp/vendor/composer/ClassLoader.php on line 444
2. Warning: include(): Failed opening ‘/home/meaganpu/public_html/wp-content/plugins/amp/vendor/composer/../willwashburn/stream/src/Stream/Exception/StreamBufferTooSmallException.php’ for inclusion (include_path=’.:/usr/local/php71/pear’) in /home/meaganpu/public_html/wp-content/plugins/amp/vendor/composer/ClassLoader.php on line 444
3. Warning: curl_multi_exec(): Could not call the CURLOPT_WRITEFUNCTION in /home/meaganpu/public_html/wp-content/plugins/amp/vendor/fasterimage/fasterimage/src/FasterImage/FasterImage.php on line 119
4. Fatal error: Uncaught Error: Class ‘WillWashburn\Stream\Exception\StreamBufferTooSmallException’ not found

A mitigation of this issue would seem to be ensure that the exception class is loaded up-front to prevent triggering that fatal error. This would be a bit better, but since the max files are open at this point another error could happen further in the process.

It seems the best thing would be to prevent opening too many files in the first place, perhaps batching them in chunks of 32, or else attempt to find some way of detecting how many more files can be opened and open one less than that for a batch. The batches of images would then need to be processed synchronously one after the other until all images are processed.