liip / imagine-bundle
This bundle provides an image manipulation abstraction toolkit for Symfony-based projects.
Installs: 30 932 539
Dependents: 244
Suggesters: 40
Security: 0
Stars: 1 664
Watchers: 82
Forks: 378
Open Issues: 72
Type:symfony-bundle
Requires
- php: ^7.2|^8.0
- ext-mbstring: *
- imagine/imagine: ^1.3.2
- symfony/filesystem: ^3.4|^4.4|^5.3|^6.0|^7.0
- symfony/finder: ^3.4|^4.4|^5.3|^6.0|^7.0
- symfony/framework-bundle: ^3.4.23|^4.4|^5.3|^6.0|^7.0
- symfony/mime: ^4.4|^5.3|^6.0|^7.0
- symfony/options-resolver: ^3.4|^4.4|^5.3|^6.0|^7.0
- symfony/process: ^3.4|^4.4|^5.3|^6.0|^7.0
- twig/twig: ^1.44|^2.9|^3.0
Requires (Dev)
- ext-gd: *
- amazonwebservices/aws-sdk-for-php: ^1.0
- aws/aws-sdk-php: ^2.4|^3.0
- doctrine/cache: ^1.11|^2.0
- doctrine/persistence: ^1.3|^2.0
- enqueue/enqueue-bundle: ^0.9|^0.10
- league/flysystem: ^1.0|^2.0|^3.0
- phpstan/phpstan: ^1.10.0
- psr/cache: ^1.0|^2.0|^3.0
- psr/log: ^1.0
- symfony/asset: ^3.4|^4.4|^5.3|^6.0|^7.0
- symfony/browser-kit: ^3.4|^4.4|^5.3|^6.0|^7.0
- symfony/cache: ^3.4|^4.4|^5.3|^6.0|^7.0
- symfony/console: ^3.4|^4.4|^5.3|^6.0|^7.0
- symfony/dependency-injection: ^3.4|^4.4|^5.3|^6.0|^7.0
- symfony/form: ^3.4|^4.4|^5.3|^6.0|^7.0
- symfony/messenger: ^4.4|^5.3|^6.0|^7.0
- symfony/phpunit-bridge: ^7.0.2
- symfony/templating: ^3.4|^4.4|^5.3|^6.0
- symfony/validator: ^3.4|^4.4|^5.3|^6.0|^7.0
- symfony/yaml: ^3.4|^4.4|^5.3|^6.0|^7.0
Suggests
- ext-exif: required to read EXIF metadata from images
- ext-gd: required to use gd driver
- ext-gmagick: required to use gmagick driver
- ext-imagick: required to use imagick driver
- ext-json: required to read JSON manifest versioning
- ext-mongodb: required for mongodb components
- alcaeus/mongo-php-adapter: required for mongodb components
- amazonwebservices/aws-sdk-for-php: required to use AWS version 1 cache resolver
- aws/aws-sdk-php: required to use AWS version 2/3 cache resolver
- doctrine/mongodb-odm: required to use mongodb-backed doctrine components
- enqueue/enqueue-bundle: ^0.9 add if you like to process images in background
- league/flysystem: required to use FlySystem data loader or cache resolver
- monolog/monolog: A psr/log compatible logger is required to enable logging
- rokka/imagine-vips: required to use 'vips' driver
- symfony/asset: If you want to use asset versioning
- symfony/messenger: If you like to process images in background
- symfony/templating: required to use deprecated Templating component instead of Twig
- 3.x-dev
- 2.x-dev
- 2.13.2
- 2.13.1
- 2.13.0
- 2.12.3
- 2.12.2
- 2.12.1
- 2.12.0
- 2.11.0
- 2.10.0
- 2.9.0
- 2.8.0
- 2.7.6
- 2.7.5
- 2.7.4
- 2.7.3
- 2.7.2
- 2.7.1
- 2.7.0
- 2.6.1
- 2.6.0
- 2.5.0
- 2.4.0
- 2.3.1
- 2.3.0
- 2.2.0
- 2.1.0
- 2.0.0
- 1.x-dev
- 1.9.1
- 1.9.0
- 1.8.0
- 1.7.4
- 1.7.3
- 1.7.2
- 1.7.1
- 1.7.0
- 1.6.0
- 1.5.3
- 1.5.2
- 1.5.1
- 1.5.0
- 1.4.3
- 1.4.2
- 1.4.1
- 1.4.0
- 1.3.3
- 1.3.2
- 1.3.1
- 1.3.0
- 1.2.7
- 1.2.6
- 1.2.5
- 1.2.4
- 1.2.3
- 1.2.2
- 1.2.1
- 1.2.0
- 1.1.1
- 1.1.0
- 1.0.8
- 1.0.7
- 1.0.6
- 1.0.5
- 1.0.4
- 1.0.3
- 1.0.2
- 1.0.1
- 1.0.0
- 1.0.0-alpha7
- 1.0.0-alpha6
- 1.0.0-alpha5
- 1.0.0-alpha4
- 1.0.0-alpha3
- 1.0.0-alpha2
- 1.0.0-alpha1
- v0.21.1
- v0.21.0
- v0.20.2
- v0.20.1
- v0.20.0
- v0.19.0
- v0.18.0
- v0.17.1
- v0.17.0
- v0.16.0
- v0.15.1
- v0.15.0
- v0.14.0
- v0.13.0
- v0.12.0
- v0.11.1
- v0.11.0
- v0.10.1
- v0.10.0
- v0.9.4
- v0.9.3
- v0.9.2
- v0.9.1
- v0.9.0
- dev-2-to-3
- dev-new-architecture
- dev-refactor
This package is auto-updated.
Last update: 2024-11-04 13:48:51 UTC
README
This bundle provides an image manipulation abstraction toolkit for Symfony-based projects.
Overview
-
Filter Sets: Using any Symfony-supported configuration language (such as YML and XML), you can create filter set definitions that specify transformation routines. These definitions include a set of filters and post-processors, as well as other optional parameters.
-
Filters: Image transformations are applied using filters. A set of build-in filters are provided by the bundle, implementing the most common transformations; examples include thumbnail, scale, crop, flip, strip, and watermark. For more advances transformations, you can easily create your own custom filters.
-
Post-Processors: Modification of the resulting binary image file (created from your filters) are handled by post-processors. Examples include JPEG Optim, Moz JPEG, Opti PNG, and PNG Quant. Just like filters you can easily create your own custom post-processors.
Example
Suppose you defined a my_thumb
filter set, which can be configured to
perform any number of different transformations. The simplest invocation would
be to pipe the path of your image to the provided imagine_filter
Twig
filter.
<img src="{{ asset('/relative/path/to/image.jpg') | imagine_filter('my_thumb') }}" />
Contributor Code of Conduct
This project is released with a Contributor Code of Conduct. By participating in this project you agree to abide by its terms.
Attribution
-
Thanks to the many contributors who have dedicated their time and code to this project.
-
The standalone PHP Imagine Library is used by this bundle for image transformations.
-
This package was forked from AvalancheImagineBundle with the goal of making the code more extensible. Reference AvalancheImagineBundle#25 for additional information on the reasoning for this fork.
Setup
Installation
Using this package is similar to all Symfony bundles. The following steps must be performed
Detailed setup instructions can be found in the installation chapter of the documentation.
Configuration
Detailed information on all available configuration options can be found in the configuration chapter of the documentation.
Usage Primer
Generally, this bundle works by applying filter sets to images from inside
a template. Your filter sets are defined within the application's configuration
file (often app/config/config.yml
) and are comprised of a collection of
filters, post-processors, and other optional parameters.
We'll learn more about post-processors and other available parameters later, but for now lets focus on how to define a simple filter set comprised of a few filters.
Create Thumbnails
Before we get started, there is a small amount of configuration needed to ensure our data loaders and cache resolvers operate correctly. Use the following boilerplate in your configuration file.
# app/config/config.yml liip_imagine : # configure resolvers resolvers : # setup the default resolver default : # use the default web path web_path : ~ # your filter sets are defined here filter_sets : # use the default cache configuration cache : ~
With the basic configuration in place, we'll start with an example that fulfills a common use-case: creating thumbnails. Lets assume we want the resulting thumbnails to have the following transformations applied to them:
- Scale and crop the image to 120x90px.
- Add a 2px black border to the scaled image.
- Adjust the image quality to 75.
Adding onto our boilerplate from above, we need to define a filter set (which we'll
name my_thumb
) with two filters configured: the thumbnail
and background
filters.
# app/config/config.yml liip_imagine : resolvers : default : web_path : ~ filter_sets : cache : ~ # the name of the "filter set" my_thumb : # adjust the image quality to 75% quality : 75 # list of transformations to apply (the "filters") filters : # create a thumbnail: set size to 120x90 and use the "outbound" mode # to crop the image when the size ratio of the input differs thumbnail : { size : [120, 90], mode : outbound } # create a 2px black border: center the thumbnail on a black background # 4px larger to create a 2px border around the final image background : { size : [124, 94], position : center, color : '#000000' }
You've now created a filter set called my_thumb
that performs a thumbnail
transformation. The thumbnail
filter sizes the image to the desired width
and height (in this example, 120x90px), and its mode: outbound
option causes
the resulting image to be cropped if the input ratio differs. The background
filter results in a 2px black border by creating a black canvas 124x94px in size,
and positioning the thumbnail at its center.
Note: A filter set can have any number of filters defined for it. Simple transformations may only require a single filter while complex transformations can have an unlimited number of filters defined for them.
There are a number of additional filters,
but for now you can use your newly defined my_thumb
filter set immediately
within a template.
For Twig-based template, use:
<img src="{{ asset('/relative/path/to/image.jpg') | imagine_filter('my_thumb') }}" />
Or, for PHP-based template, use:
<img src="<?php $this['imagine']->filter('/relative/path/to/image.jpg', 'my_thumb') ?>" />
Behind the scenes, the bundle applies the filter(s) to the image on-the-fly
when the first page request is served. The transformed image is then cached
for subsequent requests. The final cached image path would be similar to
/media/cache/my_thumb/relative/path/to/image.jpg
.
Note:
*Using the dev
environment you might find that images are not properly
rendered via the template helper. This is often caused by having
intercept_redirect
enabled in your application configuration. To ensure
images are rendered, it is strongly suggested to disable this option:
# app/config/config_dev.yml web_profiler : intercept_redirects : false
Runtime Options
Sometime, you may have a filter defined that fulfills 99% of your usage scenarios. Instead of defining a new filter for the erroneous 1% of cases, you may instead choose to alter the behavior of a filter at runtime by passing the template helper an options array.
For Twig-based template, use:
{% set runtimeConfig = {"thumbnail": {"size": [50, 50] }} %} <img src="{{ asset('/relative/path/to/image.jpg') | imagine_filter('my_thumb', runtimeConfig) }}" />
Or, for PHP-based template, use:
<?php $runtimeConfig = array( "thumbnail" => array( "size" => array(50, 50) ) ); ?> <img src="<?php $this['imagine']->filter('/relative/path/to/image.jpg', 'my_thumb', $runtimeConfig) ?>" />
Path Resolution
Sometime you need to resolve the image path returned by this bundle for a filtered image. This can easily be achieved using Symfony's console binary or programmatically from within a controller or other piece of code.
Resolve with the Console
You can resolve an image URL using the console command
liip:imagine:cache:resolve
. The only required argument is one or more
relative image paths (which must be separated by a space).
$ php bin/console liip:imagine:cache:resolve relative/path/to/image1.jpg relative/path/to/image2.jpg
Additionally, you can use the --filter
option to specify which filter
you want to resolve for (if the --filter
option is omitted, all
available filters will be resolved).
$ php bin/console liip:imagine:cache:resolve relative/path/to/image1.jpg --filter=my_thumb
Resolve Programmatically
You can resolve the image URL in your code using the getBrowserPath
method of the liip_imagine.cache.manager
service. Assuming you already
have the service assigned to a variable called $imagineCacheManager
,
you would run:
$imagineCacheManager->getBrowserPath('/relative/path/to/image.jpg', 'my_thumb');
Often, you need to perform this operation in a controller. Assuming your
controller inherits from the base Symfony controller, you can take advantage
of the inherited get
method to request the liip_imagine.cache.manager
service, from which you can call getBrowserPath
on a relative image
path to get its resolved location.
/** @var CacheManager */ $imagineCacheManager = $this->get('liip_imagine.cache.manager'); /** @var string */ $resolvedPath = $imagineCacheManager->getBrowserPath('/relative/path/to/image.jpg', 'my_thumb');
Filters
This bundle provides a set of built-in filters and you may easily define your own filters as well. Reference the filters chapter from our documentation.
Use as a Service
If you need to use your defined "filter sets" from within your controller, you can fetch this bundle's FilterService from the service container to do the heavy lifting for you.
<?php class MyController extends Controller { public function indexAction() { /** @var FilterService */ $imagine = $this ->container ->get('liip_imagine.service.filter'); // 1) Simple filter, OR $resourcePath = $imagine->getUrlOfFilteredImage('uploads/foo.jpg', 'my_thumb'); // 2) Runtime configuration $runtimeConfig = [ 'thumbnail' => [ 'size' => [200, 200] ], ]; $resourcePath = $imagine->getUrlOfFilteredImageWithRuntimeFilters( 'uploads/foo.jpg', 'my_thumb', $runtimeConfig ); // .. } } ?>
Data Roots
By default, Symfony's web/
directory is registered as a data root to load
assets from. For many installations this will be sufficient, but sometime you
may need to load images from other locations. To do this, you must set the
data_root
parameter in your configuration (often located at app/config/config.yml
).
liip_imagine: loaders: default: filesystem: data_root: /path/to/source/images/dir
As of version 1.7.2
you can register multiple data root paths, and the
file locator will search each for the requested file.
liip_imagine: loaders: default: filesystem: data_root: - /path/foo - /path/bar
As of version 1.7.3
you ask for the public resource paths from all registered bundles
to be auto-registered as data roots. This allows you to load assets from the
Resources/public
folders that reside within the loaded bundles. To enable this
feature, set the bundle_resources.enabled
configuration option to true
.
liip_imagine: loaders: default: filesystem: bundle_resources: enabled: true
If you want to register some of the Resource/public
folders, but not all, you can do
so by blacklisting the bundles you don't want registered or whitelisting the bundles you
do want registered. For example, to blacklist (not register) the bundles "FooBundle" and
"BarBundle", you would use the following configuration.
liip_imagine: loaders: default: filesystem: bundle_resources: enabled: true access_control_type: blacklist access_control_list: - FooBundle - BarBundle
Alternatively, if you want to whitelist (only register) the bundles "FooBundle" and "BarBundle", you would use the following configuration.
liip_imagine: loaders: default: filesystem: bundle_resources: enabled: true access_control_type: whitelist access_control_list: - FooBundle - BarBundle
Permissions
Image locations must be readable by your web server. On a system that supports
setfacl
(such as Linux/BSD), use
HTTPDUSER=`ps axo user,comm | grep -E '[a]pache|[h]ttpd|[_]www|[w]ww-data|[n]ginx' | grep -v root | head -1 | cut -d\ -f1` sudo setfacl -R -m u:"$HTTPDUSER":rwX -m u:`whoami`:rwX /path/to/source/images/dir sudo setfacl -dR -m u:"$HTTPDUSER":rwX -m u:`whoami`:rwX /path/to/source/images/dir
See the Symfony Permissions documentation for commands compatible with macOS and other environments.
Using Apache
You need to grant read access for Apache by adding the following to your Apache VHost configuration
<VirtualHost *:80> <!-- Rest of directives like DocumentRoot or ServerName --> Alias /FavouriteAlias /path/to/source/images/dir <Directory "/path/to/source/images/dir"> AllowOverride None Allow from All </Directory> </VirtualHost>
Alternatively, you can place the directive in a separate file within your
project, and include it within your Apache VHost configuration. For example,
you can create the file app/config/apache/photos.xml
and add the following
to your VHost file
<VirtualHost *:80> <!-- Rest of directives like DocumentRoot or ServerName --> Include "/path/to/your/project/app/config/apache/photos.xml" </VirtualHost>
This method keeps the file with the rest of your code, allowing you to change it easily or create different environment-dependent configuration files.
Once you have configured Apache properly, the relative path to an image with
the following absolute path /path/to/source/images/dir/logo.png
must be
/FavouriteAlias/logo.png
.
Documentation
For more detailed information about the features of this bundle, refer to the documentation.