LiipImagineBundle

LiipImagineBundle is an image manipulation abstraction toolkit for Symfony projects. It allows you to define image transformations through three main components:

1. Filter Sets: Defined using Symfony-supported configuration languages (like YAML or XML), these specify a sequence of transformations.
2. Filters: Built-in routines for common image transformations such as thumbnail, scale, crop, strip, and watermark. You can also implement custom filters.
3. Post-Processors: Routines that modify the resulting binary file after filters have been applied. Built-in examples include JpegOptim, OptiPNG, MozJpeg, and PngQuant. Custom post-processors are also supported.

LiipImagineBundle is an image manipulation abstraction toolkit for Symfony-based projects. It operates using three main concepts:

• Filter Sets: Defined using Symfony-supported configuration languages (like YAML or XML), these specify a sequence of transformation routines.
• Filters: The individual transformations applied to an image. Built-in filters include thumbnail, scale, crop, flip, strip, and watermark. You can also create custom filters.
• Post-Processors: These handle modifications to the resulting binary image file after filters have been applied. Examples include JPEG Optim, Moz JPEG, Opti PNG, and PNG Quant. Custom post-processors can also be implemented.

The CacheResolver is a wrapper designed to add a caching layer around another resolver. It cannot be used on its own; it must wrap an existing resolver (e.g., an AmazonS3Resolver).

Warning: This resolver is deprecated because it relies on the discontinued Doctrine Cache library. It is highly recommended to use the PsrCacheResolver instead.

In LiipImagineBundle, it is important to distinguish between filters and post-processors:

• Filters modify the image itself (e.g., resizing, cropping, rotating).
• Post-processors modify the image binary (e.g., compression, optimization).

Post-processors run after all filters have completed. The resulting image binary is passed through all configured post-processors in sequence. You can safely chain multiple post-processors, even if they operate on different mime-types, making them ideal for image optimization pipelines.

The Chain data loader acts as a wrapper that delegates the loading of image binaries to a sequence of other configured data loaders. It does not load the binary itself but iterates through a list of loaders in the order they are defined.

It returns the image binary from the first loader in the chain that successfully responds to the provided file path. If a file exists in multiple loaders, the one defined earliest in the chain's configuration will be used.

liip_imagine:
    loaders:
        qux:
            chain:
                loaders:
                    - foo
                    - bar
                    - baz

A DataLoader is responsible for the first step of the image processing pipeline: fetching the raw image data.

• Interface: Liip\ImagineBundle\Binary\Loader\LoaderInterface
• Responsibility: It must find a single image based on a given identifier and return a ready-to-use Imagine\Image\ImageInterface object.
• Default Implementation: Liip\ImagineBundle\Binary\Loader\FileSystemLoader reads files from the local filesystem.
• Management: They are typically managed by the DataManager via dependency injection.

A CacheResolver manages the storage and retrieval of the final, filtered images to avoid redundant processing.

• Interface: Liip\ImagineBundle\Imagine\Cache\Resolver\ResolverInterface
• Responsibility: It uses a path (the identifier used to address the original image, e.g., in a template) to:
  1. Resolve a given path into a Response if the cached version exists.
  2. Store the filtered content under a given path for future requests.
  3. Generate a URI to address the cached image directly.
  4. Remove a cached image.
• Default Implementation: WebPathResolver, which caches images as static files in the web directory, allowing the web server to serve them directly without invoking the application stack.

Filters are used to perform image transformation operations (e.g., resizing, cropping, rotating). You can define filter sets in your configuration that consist of a single filter or a chain of multiple filters to achieve complex transformations.

Built-in filters are available for common use cases, including sizing, orientation, and general transformations.

The WebPathResolver allows you to cache generated images directly on your local filesystem within your Symfony application's web root. This enables your web server (e.g., Nginx, Apache) to serve the cached images directly, bypassing Symfony for subsequent requests.

Important considerations for URL generation:

• The resolver uses the Symfony request context to determine the HTTP scheme (HTTP vs HTTPS) and the port.
• If you use a proxy for TLS termination, ensure you have configured Symfony's trusted proxies correctly so the resolver generates https:// URLs.
• If you use embedded controllers in templates, you must add localhost to your trusted proxies configuration.

The FlysystemLoader allows you to load images using the League\Flysystem\Filesystem abstraction layer. This enables LiipImagineBundle to work with any storage source supported by Flysystem (e.g., local, S3, Azure, etc.).

To use it, you must provide a service ID for a League\Flysystem\Filesystem service via the filesystem_service configuration key within a loader profile.