Regular Expression Routing for dynamically generated Images in Zend Framework

In one of my previous blog posts, i covered how to use Zend Framework in combination with an Image Processing Library to achieve flexible and dynamic image resizing possibilities. I briefly mentioned the use of Zend Frameworks Routing System in order to also create nice URLs for such dynamically generated Images.

A Broken Promise?

A request for dynamically generated images will take some GET variables, in order that we can submit the different parameters that are necessary to create the desired image. How big is it gonna be? How should it be cropped? Do i need to preserve possible transparency with PNGs? This would potentially lead to complicated urls such as:

A bit ugly and not looking like an image file at all. Wouldn’t it be nice to have something more like this?

With the Routing possibilites of Zend Framework, we’re gonna take care of that. While most of the time it doesn’t really matter how the image URLs are going to look like, it’s actually cool to have this feat because the links don’t look like server generated images at all, which gives you extra bragging rights.

Read the whole story here…

This was what i wrote. One of the readers of that post, Nicholas Dunbar pointed out, that i didn’t cover the routing part, which i sort of promised here. I feel kinda guilty about it now, as i always try to live up to the standards and sharing knowledge on this blog – so i’ll try to make up for it with this article.

Faking it with routing

Routing allows us to kinda fake our URLs – what looks like an image or a static .html page to the visitor might actually be a piece of dynamic generated content. Usually such a task is accomplished by modifying the .htaccess file with some sneaky mod_rewrite extensions. I recommend you to read this great article by DK Lynn if you want to get familiar with the concept of URL rewriting and using Regular Expressions to that end.

With a tiny addition to our bootstrap file, we’ll achieve the possibility to access all our dynamically generated images – cached or not – via an URL that actually looks like we had our image stored right on our server in a plain view path – only that there is more than meets the eye.

There is more information about routing with the Zend Framework on the official Documentation, but let me try and wrap up the above example for you:
First, we’ll define a Regular Expression that will try and match any given URL entered inside our ZF-based application/website.

The regular expression is made up of different elements:

  • image_rendered: The static portion of the URL – meaning that the routing will only kick when the URL starts with “image_rendered” after the Domain Root
  • (\w*?): This will match any “word character” (letters, digits, and underscores) until the next slash – we use it to define the filepath – as a filepath can contain slashes, we’ll replace them as underscores in the route – they’ll be converted to slashes again later in the ImageController./li>
  • ([\w\-\.]*?): This defines the filename – we’ll allow “word characters as before” but additionally also dots and dashes, characters which are comminly used in filenames
  • ([0-9]*?)x([0-9]*?)_([a-z]*?)\.(jpg|png|gif): This last part is the most complex one – we do the “faking” bit here, trying to piece together a string that looks like a filename but is actually a set of parameters used by the server to calculate the dimensions and conversions of our generated image. The first two numeric elements separated by an x ([0-9]*?)x([0-9]*?) make up the images dimensions (width x height) – then an underscore and another string ([a-z]*?) that defines the type of resizing to be done (in the case of our example crop, ration or fill) – the last bit is then only “pro forma” – .(jpg|png|gif) gives our URL a file ending, thus making it look like your regular ol’ picture, carefully uploaded to the webserver with Microsoft FrontPage’s Publish Function.

Now all we have to do is map all these matched elements to a Zend Framework internal route that will lead the request to our ImageController who will then take care of all the resizing. This is being done by submitting an array to the route:

The first one defines the plain MVC routing that we find in all Zend Framework Pages, in our case to use the ImageController’s index action in the default module. The second array does the actual mapping of the Regular Expression Matches to what will finally be submitted as GET-Parameters to the ImageController.

The last bit of the Routing Constructor Call is then used to instruct Zend Framework on how to reversely create URLs – in case we want to create a “Rewritten” URL from a set of parameters that we get from the Controller or from a Database.

And that’s the whole routing magic! If you want to know more about the process of actual Dynamic Image Resizing with Zend Framework, you might find what you’re looking for on my blog post about that topic – which started the whole thing here.

So long and thanks for all the reading!


  1. A little more information on where to put the code and how the bootstrap.php file works.

    “should custom initialization be necessary, you have two choices. First, you can write methods prefixed with _init to specify discrete code to bootstrap. These methods will be called by bootstrap(), and can also be called as if they were public methods: bootstrap(). They should accept an optional array of options.”


  2. Also the example url:


    Does not fit with

    “image_rendered: The static portion of the URL – meaning that the routing will only kick when the URL starts with “image_rendered” after the Domain Root”

    You rock. Thanks a bunch.

  3. Hi,

    I’ve been doing something very similar to this and came across this and the original post because I have a 404 file not found entries in my apache error logs for the image, even though it is routing through zf just fine. Is that the case for you too or do you have something that means apache doesn’t log it as not found, .htaccess or virtualhost settings etc.?


    • Hi Mark
      I don’t exactly understand the issue at hand. When exactly would you get a 404 error? When trying to open such dynamic images? Can you maybe give an example of your use case? I’d be glad to help – in my codebase, i use a fallback placeholder image in case a non existing image is being accessed.


Leave a Comment.