Allan MacGregor has a post today talking about a handy tool he uses in his development to have multiple versions of PHP running side-by-side: PHPFarm.

If you have been working with PHP for a while, chances are that you have come across with a project, extension or script that requires to be tested on multiple PHP versions, for simple CLI scripts this seems easy enough but what happens when you are working with complex applications, developing for frameworks or multiple versions of them? [...] This setup can quickly become cumbersome and it is not easily scalable. [...] Getting multiple PHP versions running side by side can be challenging and over the year devs have released multiple solutions like PHPEnv or the new , personally I use PHPFarm.

He walks you through the installation and configuration of the tool. He also shows you how to get a few different versions of PHP installed, including custom configuration files. He also includes a bit at the end of the post about getting it all to work with Apache (via mod_fastcgi and some custom configuration changes).

On the Leaseweb Labs blog there's a recent post looking at using the POC framework to work with flexible output caching. The tool makes it easy to create a new object and push cache content into it, automatically caching the data to sources like the file system, a Redis instance or a MongoDB database.

Last year at the Symfony conference in Paris I have heard a really good quote: "There are only two hard things in Computer Science: cache invalidation and naming things" - Phil Karlton. I agree with it and it gave me a boost to keep evolving the concept.

He includes an introduction to the caching features of the framework complete with sample code showing first how to cache to the default file system and a more complex example that uses unique caches and page blacklists. Other features planned for the caching tool include edge-side includes, using Twig for templating and statistics recorded to a database.

On his blog today Shameer Chamal has a new post about a framework he's recently developed an appreciation for (he calls it "awesome" in fact) - Kohana.

In this article we will discuss some important features of Kohana, a promising and the sexiest community driven php framework. This article is pretty basic and intended to instigate those who are still not familiar with this framework. One of the problem with this framework is the lack of well organized documentation. Anyway there are many useful resources available and I have mentioned some of them at the end of this article.

He talks about some of the things he likes best about the framework including its HMVC (hierarchical Model view controller) support allowing you to cascade files down, allowing overrides at any level (good illustration here). He also talks about the scalability it offers and how, because of the HMVC functionality, you can split things up into interchangeable parts that can be pulled in based on the situation. Other features briefly mentioned include easy configuration, security and the exception handling and profiling.

Adam Jensen has written up a new article today on how you can use the Zend_Auth component of the Zend Framework to authenticate your users in a few different ways based on a strategy selected.

For this example, we’re going to allow our users to authenticate in one of multiple ways: e.g., against a database table, against an LDAP server, or by OpenID [1]. Zend_Auth already provides the necessary authentication adapters, so what we’ll be concerned with here is how to implement all three systems without ending up in an FSUC situation.

He defines the code for the basic controller and a simple view that allows the user to select how they want to log in - email/password, username/password or OpenID. The model does all of the heavy lifting by letting the controller set the authentication type (strategy) and pulling in the correct Zend_Form instance along with its validation rules. Code is also included for the model and each of these.

Chris Hartjes continues his series looking at converting over legacy applications into a CakePHP environment with this third part, a focus on what can be one of the hardest parts - separating out business logic and presentation logic.

Anyway, onto other matters. As you saw in parts 1 and 2, a bug part in having a successful transition from legacy app to CakePHP is having an environment that is well suited to the use of a framework. Having laid out the groundwork for that switchover, it's time to talk about the part of a refactoring or porting that is most difficult: separating your business logic from your display logic.

He talks about fat models, skinny controllers and flexible views with some code to illustrate each. This method makes the models do most of the work while the controllers are more of a go-between for them and the views. The views, then, are pliable enough to work with whatever data might be thrown at them.

Knut Urdalen has posted a new blog item about something he calls "washing emails":

In this tutorial I’ll show you how to create a simple PHP script to cleanup a list of email addresses. As a web developer you have probably been asked to wash a list of emails from a manager or marketer some times. Here’s the ultimate solution.

His script does a few things - removes duplicates, validates that the email address exists, uses pipes for communication and is as flexible as possible to work on most PHP distributions. You can download the simple script here.

In a new blog post today Evert Pot shares some of his thoughts on integrating the Zend implementation of the OpenID protocol, Zend_OpenId, into his application.

The Zend Framework has a pretty good OpenID library. I was looking for a library written for PHP5 (strict), and this seemed like a good choice...

He mentions some of both sides of the argument - (the good) the flexibility of the library to work with different backend storage methods and (the bad) the requirements it has for the Zend Framework sessions system for authentication.

In this new post on the PHP::Impact blog, Federico looks at some examples of directory setups for web apps that can help to make them both scalable and flexible.

Designing a modular and component-based directory structure for your Web applications can seem like an easy task. If your system is small, it may seem logical to go with the simplest design possible, but if there's anything more time consuming and complex than developing a new directory structure design, it's trying to redesign an existing system that wasn't developed with growth in mind.

He breaks it up into a few different topics that can be applied where needed to keep the application in check:

• Consistency
• Scalability and Flexibility
• Single Application
• Multi-application
• Naming Conventions
• Versioning
• Proposed Structure

In an effort to breathe as much life into an old bit of software he was having to update, Harry Roberts worked up a list of things that he sees can make things a bit more "programmer friendly" when it comes to using classes, methods and interfaces in your code.

His list of four is:

• Doc Comments
• Flexible Parameters
• Use method Entry contracts
• Be Stateful and Refactor

The "Doc Comments" is pretty obvious, but some of the others need a bit more explaining. Being flexible with your parameters is more about requiring the least from a developer, "entry contracts" being the restrictions to let the developer know what you're expecting and refactoring commonly used functionality into a easy, single point of contact.

According to Akash Mehta in this new post on the SitePoint PHP blog, all of the frameworks out there aren't really needed because "last we checked, PHP IS a framework".

Now, consider the "average" PHP frameworks. They help you handle request data, manage your output, control app flow - essentially, extending PHP's inbuilt functionality. They are, therefore, PHP frameworks on the PHP framework. PHP provides a vast array (pardon the pun) of functionality out of the box. But when you want to do things your way, it gets out of the way, and this is really important when building anything beyond a simple database frontend.

He suggests that PHP is a "half framework" on its own, providing quick an easy methods and functionality to build up applications. He gives an example of Twitter (and really, who isn't picking on them these days) and how it probably could have avoided a lot of the issues it is seeing if it had gone with something a bit more efficient and flexible.

Be sure to check out the comments for some other great opinions from the community.