Package Watch: Image Management

Sorry if I sound like a broken record, but packages are f**king brilliant. I've mentioned before that packages are the future of PHP and plenty of other developers are thinking the same thing.

For years I was locked into using the same frameworks for everything, mainly because my clients were hiring me specifically to use CodeIgniter based on my reputation within the community.

Now that is not the case and I can build things however I damn well like, so I am doing it properly and that is using Composer.

No Framework?

Any project needs some sort of base; something needs to handle your HTTP requests, route them to a callback, or a controller, or something.

This is one of the most basic objectives of a framework, and really it should be one of it's primary concerns. I could write all of this myself, but I have more interesting things to do so I needed to pick a framework.

If this was an API I would have used Slim or Silex, but this project needed a lot of CRUD, form validation and database interaction so I decided to use something that had a lot of that already: Laravel 4.

Why Laravel 4?

Taylor Otwell gets PSR packages. Laravel 4 is entirely built on top of Composer. The validation, sessions, database (Query Builder and Eloquent ORM), routing, etc are ALL Composer packages so I can pick and chose the bits that I need.

It makes the choice of framework considerably less important, because I can use the Laravel ORM with… anything.

But X framework doesn't do Y

A PHP framework should focus its attention on its core responsibilities, like routing, request, response, sessions, views, etc and NOT on random edge-case stuff. Much like the CodeIgniter Cart library which I want to see killed off, ORM's or even in this case image management.

Laravel 4 doesn't handle it, so I had to use some extra packages.

Image Uploads & Management

To get this extra functionality I added two packages to my composer.json:

The first is Upload by Josh Lockhart (who built Slim and started PHP The Right Way). It's currently very basic as it's not been alive long, but for the job I needed to do it worked perfectly:

Perfect. It's helped me validate size and mime-type with much less boilerplate code than native PHP would have required. This same package will work anywhere, and soon enough it will have other storage drivers so this file can go straight to S3 when I hit upload. Nice.

Moving on, one it's uploaded I want to resize it and add a watermark to the corner. Erf, ok so getimagesize() then check if the height or width is larger, then try to resize in ratio if its bigger than a certain size, then add a new image by calculating the size of the new image, minus 10 pixels to offset it and… IM SO BORED ALREADY!

Let's use a package:

Phew, I almost had to think for a minute there. Thanks Clément Guillemain.

The think I love is that all of these packages fit into my application perfectly, and there is no "I wonder if they've updated recently, I'd better go back to their blog and check to see". Even more recently with GitHub managing all of those as Git submodules would have been a ballache.

Here is my entire composer.json for this project:

Easy right?

Final Thoughts

I know it's early days but this is PHP renaissance. People are building an ActiveMerchant port (payment with 12+ gateways that will work perfectly in any framework), Alex Bilbie is combining all of our OAuth 2 client and server logic for CodeIgniter and FuelPHP to make one epic OAuth 2 package that will do everything, there are Asset pipelines, command line controllers, IMAP inbox readers, and all sorts of crazy and useful things.

Start using Composer on your next project and say "fuck you" to the frameworks that lock you in. If you spend all your time using that one framework, you'll have a horrible time using a different one. If you use packages you can take them with you to whatever framework you use for the next project. That reduces time wasted re-learning how YetAnotherORM works, or how YET ANOTHER ASSET LIBRARY works, helps reduce wasted code, help reduce bullshit tribalism in framework users, and helps PHP move forward as an ecosystem.