In a previous article I talked about a method to resize images on demand. The article (from October 2009) was written with extensibility in mind, but (of course) not with the counterparts we found out after a while. On-demand resizing of images server-side is very nice, because:
- Browsers are less capable to resize images
- Bandwidth is minimalized for unnecessary large images
Nevertheless we ran into two drawbacks with this method:
- Images are rendered on each request
- Every width or height is possible to resize
The first one is bad because it has a huge impact on performance. Every render costs processing time, so images should actually be cached. Preferably this should be done without interference of php processing: when a resized version is already available, Apache should be able to serve this file directly without required work of php.
The second drawback is more a silent attack: you don't notice the problem until you get pointed to it yourself (or get attacked with this method). When you cache the resized versions (but you allow all different widths and height) it is still easy to program an attack. A computer will request an image with a width of 100, 101, 102, 103 etc. Every request, the image is different and therefore the server has to resize the image to the right size over and over again.
Therefore, we now use an image process method which includes the following benefits:
- Server-side resize of images
- Images are cached after resize
- Only a few variations are possible
- All variations are grouped into one directory
The last point is also very useful, because when you update the original image, you'd like to remove all old variations of the old original at once. With the hassle of spreaded variations of images, you never get this done properly.
In the new versions of Zend Framework (since 1.11.0, released 2 November 2010) it is possible to detect devices with the new Zend_Http_UserAgent component. The component detects the User-Agent of a client and the corresponding capabilities. This with the help of WURFL, Tera_WURFL or DeviceAtlas.
In my case the WURFL library is the easiest solution and sufficient for my use cases. With Zend_Http_UserAgent and WURFL, the possibility is availble to detect a mobile device and switch the layout and/or the view accordingly. Nonetheless it is not easy to accomplish this in a generic way. This article suggest the usage of a frontController plugin to detect the mobile devices and switch the layout. An action helper is also introduced to switch to mobile view scripts on an actionController's action base.
I work more and more with web applications where users persist personal data and realize the functions to access this data requires a secured connection. Currently I do not use SSL for login, but for next projects I would like to incorporate this into the Soflomo system. 
To enable an SSL config with Apache2 on a Linux system (in our case Ubuntu Linux) the Ubuntu wiki provides a very good tutorial how to complete this in a couple of minutes with self-signed certificates. The certificates can be bought by certified organizations of course, but in my development environment, self-singed certificates are good enough. 
Next, I want to create the control for http/https environments in the Zend Framework as easy as possible. Therefore I create an action helper for the Zend Framework's action controllers to force pages to be served in https and, when necessary, in http. There are a few assumptions/requirements for this helper:
- Determine http/https requirements on action basis
- By default, no redirect happens (the action accepts both http and https access)
- When necessary, http and https can be forced for specific actions
To fulfill this list, an action helper is created which is small in lines of code, but does exactly what it must do.
The navigation component of the Zend Framework was introduced at version 1.8. From my perspective, the navigation is besides the MVC stack one of the most useful components of the system. All menu bars, breadcrumbs, meta links, sitemaps and all their variations can be created with this powerful and flexible component.
Nevertheless, some people find it difficult to use Zend_Navigation because of the complex hierarchy of objects. In this blog article I explain a few tips and tricks which I use in my projects. It eases the creation of more complex navigation structures and hope others find it useful too.
It's -for me- a pain in the ass to write too much code when it isn't necessary. For example, you're able to fetch a view helper simply by using the magic method Zend_View_Helper_Abstract::__call(), but when you try to magically load an action helper in an action controller, this is (by default) not possible.
This article is just a small talk how to call the direct() method of the action helper and get the instance of the helper.