Utilising the fantastic sfImageTransformPlugin this plugin provides all means to configure any set of thumbnail formats with all possible transformations in a YAML file.
All these configured settings can be applied to any kind of source image using a nice URL schema.

Developers

License

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files
(the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge,
publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do
so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED
TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT
SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE
OR OTHER DEALINGS IN THE SOFTWARE

caefer: removed all example routes and left only default @sf_image all others are commented

caefer: added class check for sfImageSource classes as set on routes

caefer: adapted tests

Release 1.0.3 - 18/05/2010

This is a bugfix release. Remote image sources depending on their binary structure might not have been able to detect the mime type of. This was caused by getimagesize() seeking when mime information could not be read from the first chunk of data.

caefer: moved default http route upwards to avoid a conflict with the default file route

Release 1.0.1 - 28/04/2010

PLEASE NOTE!
In this release there is a bugfix of the autoboxing feature which requires you to change your thumbnailing.yml if you use transformations like overlay or alphamask.
In this case you have to prefix the overlay and mask parameters with "sfImage|". See http://trac.symfony-project.org/changeset/29292 for an example.

caefer: bugfix: autoboxing of parameters now limited to parameters prefixed with 'className|'

caefer: updated docblock comments for autoboxing related methods

Release 1.0.0 - 26/04/2010

caefer: bugfix: removed forgotten var_dump()s..

caefer: optimised the extension matching and file info code

caefer: reviewed, corrected and completed README

caefer: reviewed and updated some of the default resources used within this plugin

Release 0.9.0 - 14/03/2010

Image manipulation made even easier - sfImageTransformExtraPlugin

Introduction

On a website you ususally find lots of images and a set of formats.

For example let's say a user avatar is always 80x80 PNG while a homepage top image is always 320x140 JPG with round corners.

As it is far too costly to prepare all these different formats by hand there are automated ways to generate them from source images uploaded by a user. One of the best tools for this in the symfony world is the sfImageTransformPlugin which enables you to perform many sophisticated transformations on your images such as resizing, color manipulation, overlays and more.

Using such an automatism means you have to write code and perform all necessary transformation on upload, no matter if the generated files are ever requested. It also means that design changes that also change the formats lead to change of business logic rather than just templates.

This is where sfImageTransformExtraPlugin springs to action as it provides a way to configure formats with multiple transformations.
In your templates you only refer to the format by name which results in an SEO friendly image URL. The image itself will be generated on first request and (in production environments) written to the filesystem.

The thumbnail image is generated on the first request. All succeeding requests are coming from cache (per default the filesystem) and are served by Apache without spawning a PHP process.

The caching mechanism

Image generation is quite expansive in terms of CPU and memory. This is why sfsfImageTransformExtraPlugin by default stores generated images for the production environment on the filesystem.
For this the custom cache class sfRawFileCache is used which is basically a copy of sfFileCache but does not prepend the cached file with expire time information but instead saves only the generated image.

You can see the typical lifecycle of a generated image in the following Firebug screenshots.

The image is generated, saved to the filesystem and sent to the requesting browser.

The image is read directly from the filesystem without invoking a PHP process.

Apache automatically informs the browser that the image has not been modified by sending a 304 status.

As you can see the time needed to deliver a generated image after the second request is drastically reduced.
(The times will vary on different installations.)

The deletion of generated images use the sfCache interface and can be triggered by a task of a symfony event.

Installation

To install the plugin for a symfony project, the usual process is to use the symfony command line:

$ php symfony plugin:install sfImageTransformExtraPlugin

Alternatively, if you don't have PEAR installed, you can download the latest package attached to this plugin's wiki page and extract it under your project's plugins/ directory.