If your website allows users to upload photos, image cropping/resizing functionality certainly comes in handy. But users might not have access to image manipulation tools like Photoshop, so by providing a cropping/resizing feature you can allow users to upload photos from any device (e.g. tablets or phones) without them having to worry about the the final size. Furthermore, you can create different versions of the same image and also allow users to crop specific portions of uploaded picture. In this article I'll show you how to create an image cropping tool with the help of the ImageMagick PHP extension.

The post shows the use of the "cropimage" function to trim down an image from its original size and "thumbnailImage" to shrink down the image to make a thumbnail. Also included is the code (both the PHP and the HTML form) to handle file uploads and automatically create a thumbnail image. It outputs the image to the browser and asks the user to select the portion they want thumbnailed (with this jQuery plugin helping).

Apache ZooKeeper is the coolest technology I recently came across. I found it when I was doing a research about Solr Cloud features. [...] Running multiple application as one logical program is nothing new. In fact creating such a software was one of my first jobs many years ago. This type of architecture is confusing and very tricky to work with. Apache ZooKeeper tries to provide a generic set of tools to manage such a software.

He shows you how to get the PHP extension for Zookepper (along with needed libraries) compiled and installed in your server setup. He includes a sample class that shows you how to connect to the Zookepper server and add a "watcher" your PHP script will respond to when changes happen. The post also has a "Watcher" class example, showing how to use Zookeeper as part of a distributed application. There's some links at the bottom of the post that can also help you get more details on Zookeeper and the PHP interface.

So why do you need a search engine, is database not enough? If you create a small website it might not matter. With medium or big size applications it's often wiser to go for a search engine. Saying that, even a small websites can benefit from Solr if you desire a high level of relevance in search results.

Their example involves an ecommerce website and a search for a term (iPhones) and how difficult it could be to match against the possible multiple variations on the models. Solr makes this kind of searching easier. He shows you how to get a Solr instance all set up and configured as well as the PHP PECL extension from here. A sample PHP script is also included showing connecting to Solr, inserting a new document and searching for a simple query of "hello".

What troubles me though is that its being proposed very late in the game for PHP 5.5, therefore causing a likely delay of 5.5 of at least about 2 months in the best case scenario if it were included. The other option of including it in 5.6 does not seem to be as popular at this point. This saddens me quite a bit since I believe that predictable release cycles would carry several advantages

He points out some things that come along with having predicability around the software releases like developers knowing when/if their changes will make it into the next release. It also makes it easier for end users to plan their releases of their own software, knowing when they'll be getting a feature. In this particular case, though, he doesn't quite understand the delay as the Zend Optimizer+ isn't a change to core, it's an addition:

What is even stranger for this case is that we are just talking about an extension here. Its not a language feature, there is no engine level integration. So even if its not added to core, people can easily get Optimizer+ via PECL. So in this case we are not talking about people having to wait another 10-11 months. Don't get me wrong I think getting an opcode cache into core is awesome, but the reality is that shared host users will probably still not have access to it [...] and the rest can still get it, albeit with a bit more effort.

At the End of 2012 I had my first contact with a C-based PHP frameworks, namely YAF. Coincidently, some day afterwards Bruno from phpmaster.com pointed me towards Phalcon - a more modern interpretation of the same idea. So I was hooked.

In his "good idea" category he notes that it's faster because it's already loaded in on the request (no long list of includes) and the memory footprint is less than a PHP equivalent. The "bad" side of things mentions some pretty major hurdles though, including the small communities vs larger ones on PHP-based frameworks and the issues that could come with debugging/upgrading.

The PDO extension supports twelve drivers, enabling it to connect to a variety of relational databases without the developer having to learn a number of different APIs. It does this by abstracting the database interaction calls behind a common interface, enabling the developer to utilize a consistent interface for different databases. This of course gives it a major advantage over both the MySQL and MySQLi extensions who are limited to only one database.

Included in the post are examples of some of the basics - connecting, executing queries, getting the results - as well as more compelx things like binding parameters and transaction support. There's also a bit about changing the default behavior of the PDO object through config options. He finishes off the article talking some about some of the issues that could come from using an abstraction layer like this and the need to still write good, compatible SQL depending on the database.

Experienced developers eschew the original MySQL extension because of its abandoned status in PHP. Nascent web developers, however, may be completely oblivious to its dormant past and dying future. [...] It is therefore the intention of this two-part article to raise awareness among developers who still use the MySQL extension, inform them of its problems, and to help them switch over to an alternative extension.

They start with a brief look at the "what's wrong" with the MySQL extension (including its upcoming deprecation). The article then gets into the basics of MySQLi and how to do things like make a connection and run a few queries. There's also a bit about prepared statements and the built-in ability to do "multi-queries" (complete with rollbacks).

My idea is to store this information within a Service Container (we will use Symfony's DIC). For example here we can [define] our routes.yml. [...] We need to implement one Extension for the alias "routes". We only will implement the needed functions for YAML files in this example.

He includes the code for the extension ("SilexRouteExtension") that can be used to parse the "routes.yml" file to inject the custom routing into your application. This includes the pattern to match, the controller to route it to and the target method. You can also set some requirements like the request method (in this case "GET").

One of our more recent projects has given the team exposure to MongoDB. As such, we needed an easy way to test the models that utilize mongo in a similar fashion to how we test models that talk to mysql. Using this framework, it's easy to implement mongo test cases to easily create fixture data in collections, or simply clear collections between test cases.

You can find the latest release of this tool on github and see an example testcase here.

As PHP 5.5 is getting ready to be released in the next months, the end of line for PHP 5.3 is being planned, while the original MySQL extension is being deprecated in PHP 5.5 to be killed in a later version.

You can listen to this latest episode either through the in-page player, by downloading the mp3 or you can watch the video of the recorded Google Hangout of the taping.