TAG | sfImageTransformExtraPlugin
Thanks to Googles image search websites can gain a significant amount of traffic by their images. When overhauling your website with a redesign you might want to change your image formats though making them bigger or smaller or rounded or whatever.
Now what has to be considered not to loose on this traffic?
github has many great features but so far I rely on the README when it comes to documentation. Of course there is the wiki and I’m sure it’s great but somehow it never attracted me.
Wouldn’t it be cool to be able to easily create a website including introduction, documentation and demos and letting it reside near the repository?
Next year I will be starting on a new project which could be awesome. The plan is to roll it out in several countries and languages and to keep it skinnable to some extend. The site itself will be editorial for the best part but with the participation of its community.
I’m not going to tell more about the project itself but I present the current technology setup I am thinking about which will very likely be reflected in next years posts. Maybe you can add some experiences and thoughts?
Following yesterdays post I want to demonstrate in detail what I think was a bit cryptic.
This is limited to whether you know the maximum depth of your folder structure or not. Let me explain.
Yesterday only two days after the previous release I uploaded sfImageTransformExtraPlugin version 1.0.12 to the symfony plugin page. Despite my efforts the optimisation for removing generated thumbnails whose original source was changed did still not meet the performance expectations.
But I had another idea which got rid of the expensive recursion of RecursiveDirectoryIterator and replaced it with something else entirely.
sfImageTransformExtraPlugin is an ORM independent symfony plugin which utilizes sfImageTransformPlugin to generate all sorts of thumbnails and perform other image manipulations. Instead of providing an API it allows you to configure each desired format in a configuration .yml file. This enables you to separate design and function and simplifies format changes. It also decouples the generation process from the uploading process which ensures a clean user experience with no hickups.
It’s been a little over three months now since sfImageTransformExtraPlugin saw the last release. Yesterday I fired up version 1.0.11 which solves a few problems around caching.
Apart from this being a stylish cool site to by bikes from I am more than flattered by Christofs email and quite proud that something I worked on helped him with this project.
If you happen to have used this plugin on another site as well please send me a note as well.
So here it is.
Assuming that you store an image path in a Doctrine or Propel model: this is what you should do.
I must admit that I have been lazy with my efforts on continuous integration lately. Eventually my server crashed unnoticed and I didn’t get any emails about broken builds anymore and by now I think I’ve stacked up some work to do.
First of course I’ve got to get my CI server up and running again, that’s why I installed Hudson again.
But there is room for improvement too. Sebastian Bergmann of PHPUnit fame spent some time on a template Hudson job for PHP projects that includes much more than PHPUnit. So I decided to use that!
But you will have realised that all images generated have ugly path and file names. That might not matter much to your backend application but it will to what the user sees. So today I will focus on those nice URLs.
I’m going to use Doctrine in this post but everything will work exactly the same for Propel.