`ActiveStorage::Variant`, the class used to handle untracked variants,
is lacking some methods to make it compliant with
`ActiveStorage::Representations::ProxyController#send_blob_stream`.
This commit fixes the proxying of untracked variant by adding the
missing methods.
These methods were added in b221a4dc43368a1b6f00476f7c5f6047c5c7eea4
But they don't seem to be used by Rails internally or have any tests, so
I assume they were added by accident?
As they both seem to be marked as :nodoc: on ActiveStorage::Blob, we can
remove them without a deprecation warning.
If we decide to keep these methods, they should be added to
ActiveStorage::VariantWithRecord as well. No one complaining about there
methods missing on ActiveStorage::VariantWithRecord is another reason
these methods aren't used.
Pluses cannot be used to create code blocks when the content includes a
space.
Found using a regular expression:
```bash
$ rg '#\s[^+]*\+[^+]*\s[^+]*\S\+'
```
Background:
When creating active storage variants, `ActiveStorage::VariantRecord` is
inserted, then a file is uploaded. Because upload can be failed, the
file can be missing even though `ActiveStorage::VariantRecord` exists.
When a file is missing, we need to delete the corresponding
`ActiveStorage::VariantRecord` but there's no API to delete just one
variant e.g., `blob.variant(resize_to_limit: [100, 100]).destroy`.
Co-authored-by: Yuichiro NAKAGAWA <ii.hsif.drows@gmail.com>
Co-authored-by: Ryohei UEDA <ueda@anipos.co.jp>
Add `config.active_storage.web_image_content_types` to allow applications
to add content types (like `image/webp`) in which variants can be processed,
instead of letting those images be converted to the fallback PNG format.
### Steps to reproduce
Using Rails 5.2.0
When following this example:
http://api.rubyonrails.org/classes/ActiveStorage/Variant.html
`avatar.variant(resize: "100x100", monochrome: true, flip: "-90")`
### Expected behavior
Image should be rendered as flipped.
### Actual behavior
I get an error:
> failed with error: gm mogrify: Unrecognized option (-90).
### Fix:
According to: https://github.com/minimagick/minimagick the option should be called rotate:
`avatar.variant(resize: "100x100", monochrome: true, rotate: "-90")`
So **flip** changed to **rotate**.
### System configuration
**Rails version**: 5.2.0
**Ruby version**: ruby 2.5.1p57 (2018-03-29 revision 63029) [x86_64-darwin17]
ImageProcessing gem is a wrapper around MiniMagick and ruby-vips, and
implements an interface for common image resizing and processing. This
is the canonical image processing gem recommended in [Shrine], and
that's where it developed from. The initial implementation was extracted
from Refile, which also implements on-the-fly transformations.
Some features that ImageProcessing gem adds on top of MiniMagick:
* resizing macros
- #resize_to_limit
- #resize_to_fit
- #resize_to_fill
- #resize_and_pad
* automatic orientation
* automatic thumbnail sharpening
* avoids the complex and inefficient MiniMagick::Image class
* will use "magick" instead of "convert" on ImageMagick 7
However, the biggest feature of the ImageProcessing gem is that it has
an alternative implementation that uses libvips. Libvips is an
alternative to ImageMagick that can process images very rapidly (we've
seen up 10x faster than ImageMagick).
What's great is that the ImageProcessing gem provides the same interface
for both implementations. The macros are named the same, and the libvips
implementation does auto orientation and thumbnail sharpening as well;
only the operations/options specific to ImageMagick/libvips differ. The
integration provided by this PR should work for both implementations.
The plan is to introduce the ImageProcessing backend in Rails 6.0 as the
default backend and deprecate the MiniMagick backend, then in Rails 6.1
remove the MiniMagick backend.
VariantsController has been merged to RepresentationsController, this
PR fixes outdated references to VariantsController in ActiveStorage documentation.
If a variant has a large set of options associated with it, the generated
filename will be too long, causing Errno::ENAMETOOLONG to be raised. This
change replaces those potentially long filenames with a much more compact
SHA256 hash. Fixes#30662.
