Image variations (image aliases) enable you to define and use different versions of the same image. You generate variations based on filters which modify aspects such as size and proportions, quality or effects.
Image variations are generated with LiipImagineBundle, using the underlying Imagine library from avalanche123. This bundle supports GD (default), Imagick or Gmagick PHP extensions, and enables you to define flexible filters in PHP. Image files are stored using the
IOService, and are completely independent from the Image Field Type. They are generated only once and cleared on demand (e.g. on content removal).
LiipImagineBundle only works on image blobs (no command line tool is needed). See the bundle's documentation to learn more on that topic.
Images from a DAM system¶
If your installation is connected to a DAM system, you can use images directly from a DAM system in your content.
The specific configuration will depend on the DAM system in question.
Images in Rich Text¶
The Rich Text Field allows you to embed other Content items within the Field.
Content items that are identified as images will be rendered in the Rich Text Field using a dedicated template.
You can determine which Content Types will be treated as images and rendered using this template in the
ezplatform.content_view.image_embed_content_types_identifiers parameter. By default it is set to cover the Image Content Type, but you can add other types that you want to be treated as images, for example:
The template that is used when rendering embedded images can be set in the
ezplatform.default_view_templates.content.embed_image container parameter:
Code injection in image EXIF
Resolving image URLs¶
You can use LiipImagine's
liip:image:cache:resolve script to resolve the path to image variations generated from the original image, with one or more paths as arguments. See LiipImagineBundle documentation for more information.
Note that paths to repository images must be relative to the
var/<site>/storage/images directory, for example:
Setting placeholder generator¶
Placeholder generator enables you to download or use generated image placeholder for any missing image. It might be used when you are working on an existing database and you are not able to download uploaded images to your local development environment because of their large size
PlaceholderAliasGenerator::getVariation method generates placeholder (by delegating it to the implementation of
PlaceholderProvider interface) if original image cannot be resolved and saves it under the original path.
In Ibexa DXP there are two implementations of
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
\eZ\Bundle\EzPublishCoreBundle\Imagine\PlaceholderProvider\GenericProvider generates placeholder with basic information about original image - example 1.
Generic image example:
Full page example:
|fontpath||n/a||Path to the font file (.ttf). **This option is required.*|
|text||"IMAGE PLACEHOLDER %width%x%height%\n(%id%)"||Text which will be displayed in the image placeholder. %width%, %height%, %id% in it will be replaced with width, height and ID of the original image.|
|fontsize||20||Size of the font in the image placeholder.|
|foreground||#000000||Foreground color of the placeholder.|
|secondary||#CCCCCC||Secondary color of the placeholder.|
|background||#EEEEEE||Background color of the placeholder.|
\eZ\Bundle\EzPublishCoreBundle\Imagine\PlaceholderProvider\RemoteProvider allows you to download placeholders from:
Full page example:
|url_pattern||''||URL pattern. %width%, %height%, %id% in it will be replaced with width, height and ID of the original image.|
|timeout||5||Period of time before timeout, measured in seconds.|
Placeholder generation can be configured for each
binary_handler under the
1 2 3 4 5 6
If there is no configuration assigned to
binary_handler name, the placeholder generation will be disabled.
Example 1 - placeholders with basic information about original image
1 2 3 4 5 6 7 8 9 10
Example 2 - placeholders from remote source
1 2 3 4 5 6 7
Example 3 - placeholders from live version of a site
1 2 3 4 5 6 7
You can resize all original images of a chosen Content Type using the
You need to provide the command with:
- identifier of the image Content Type
- identifier of the Field you want to affect
- name of the image variation to apply to the images
ibexa:images:resize-original <Content Type identifier> <Field identifier> -f <variation name>
ibexa:images:resize-original photo image -f small_image
Additionally you can provide two parameters:
iteration-countis the number of images to be recreated in a single iteration, to reduce memory use. Default is
useris the identifier of a User with proper permission who will perform the operation (
publish). Default is
This command publishes a new version of each Content item it modifies.
If you use image files with unprintable UTF-8 characters in file names, you may come across a problem with images not displaying.
In that case, run the
ezplatform:images:normalize-path command to normalize them:
You can store images in the media library as independent Content items of a generic Image Content Type to reuse them across the system. It is achieved by uploading images to an ImageAsset Field Type.
For an ImageAsset Field to be reused you have to publish it. Only then is notification triggered stating image has been published under the Location and can now be reused. After establishing media library you can create object Relations between the main Content item and the image Content item being used by it.
To learn more about ImageAsset Field Type and its customization see Field Type Reference.
Handling SVG images¶
Currently, Ibexa DXP does not allow you to store SVG images by using the Image or ImageAsset Field Type. Until the full support for this MIME type is in place, you can work things around by relying on the File Field Type and implementing a custom extension that lets you display and download files in your templates.
First, enable adding SVG files to content by removing them from the blacklist of allowed MIME types.
To do it, comment out the relevant line under
Then, add a download route to the
1 2 3
It points to a custom controller that handles the downloading of the SVG file.
The controller's definition (that you place in the
config/services.yaml file under
services key) and implementation are as follows:
1 2 3 4 5 6 7 8
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82
To be able to use a proper link in your templates, you also need a dedicated Twig extension:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45
Now you can load SVG files in your templates by using generated links and a newly created Twig helper:
1 2 3