Derick Rethans has a new post today looking at a method for setting up multiple PHP versions on the same machine and switch between them with a little help from some simple bash scripts.

For many of my projects (both hobby and commercial) I need to support many different PHP configurations. Not only just different PHP versions, but also debug builds, ZTS builds and 32-bit builds. In order to be able to test and build extensions against all those different PHP configurations I have adopted a simple method that I'm sharing with you here.

Using this script he can tell his system to pull the latest version of any release from SVN and try to compile it. The trick is putting each of them into a different directory under /usr/local. He uses another small shell function (with a function called "pe()") that sets up the pathing to the right release, complete with its own locations for PEAR/PECL and a php.ini.

On the VXTIndia blog there's a recent post that gives you a very complete guide to setting up a VPS server running Ubunut with all of the software you'd need to get a (more than) complete server up and running.

Every time you purchase a new Linux VPS, you need to go ahead and set it up for use. Even though we manage to do one server a month, we always seem to forget one thing or the other. So we decided to write down the things that we do. I thought it would be a good thing to share it with everybody as well, so that we could get a few comments about what we're doing wrong, and people who do it the first time can probably pick up a few things from here.

Steps and software involved in their process include:

• Updating to the latest Ubuntu packages
• Creating other users for the system
• Installing the web environment (including PHP, MySQL, phpmyadmin and Apache2)
• Minin for monitoring
• Configuring IPTables
• Installing Fail2Ban

All of this comes complete with the additions you'll need to make to configuration files and the commands to get everything installed (via aptitude).

New on PHPBuilder.com today is a tutorial showing you how to use set up and tear down methods in PHPUnit unit tests to work with a Doctrine 2 database, making it simpler to run self-contained testing.

The recently released Doctrine 2 presents significant advantages over its 1.X predecessor, advantages which are even more pronounced when compared to the Zend Framework's default database solution, namely the Zend_Db component. [...] When running unit tests which vet various aspects of your database you'll want to setup (create) and teardown (destroy) the test database, ensuring that a pristine and repeatable version of the database is available to each test.

He includes an example of using the SchemaTool class (of Doctrine) to drop and recreate the schema from scratch with the end result of a clean working copy, ready to test from. He also includes an example of how to initialize the database with some default information using the PHPUnit database connection and a default set of fixtures (defined in YAML).

Rob Allen has posted his own guide to getting PHP 5.3 set up on OS X 10.7 Lion, the just-released update for Apple's operating system. It comes with a bundled set of PHP-related tools but you might want to set them up your own way. This is where the guide comes in.

With OS X 10.7, Apple continues to ship PHP 5.3 with PEAR, GD and PDO_MYSQL out of the box. This is how to set it up from a clean install of 10.7.

He goes through each of the pieces of software and talks about where to download the latest from and what configuration steps are needed:

• MySQL
• Apache
• the php.ini
• Xdebug
• PEAR
• PHPUnit (and friends)
• PECL OAuth
• mcrypt

On his blog Martin Sikora shares a solution that many a Symfony developer out there might find handy for running their application in a shared hosting environment:

Some time ago (actually when I was making this blog) I posted on stackoveflow.com a question on how to configure Symfony to run on shared webservers where you can't change your website's document root. I solved it but forgot that I was asking and left it without any answer.

The main problem is that the DOCUMENT_ROOT for the hosting service can't be changed by the users of the shared host. To solve this he modified his routing rules (sfPatternRouting class) and changed his .htaccess file to rewrite things over from just "/page" to "/web/page" instead. A simple solution, but it might be evasive if you've never configured it before.

David Behler has provided a complete guide to helping you get a development virtual machine instance up and running quickly complete with Apache, PHP, MySQL and Samba shares to access your files.

I know that no server is like the other and you might still run into some problems due to different library versions and so on, but you gotta admit that two Linux servers have way more in common than a Linux and a Windows server. So in this post I'll tell you how to setup your own VM with all the libs you need. Even if you haven't worked with Linux before, you should be able to follow this tutorial/example easily.

He uses an image from thoughtpolice as the base and walks you through every step of the way. He shows you how to log in as root, update all packages and start installing the software you'll need (all via apt-get). There's even a sample Samba configuration file you can use to get started. The end result of all of this setup can be found in this image too.

In a new post to his blog Mike Willbanks shows you how to build and maintain a PEAR server with Phirum.

Pirum is a simple PEAR channel server manager that was built by Fabien Potencier. The Pirum project allows you to easily setup a PEAR channel and publish your own packages quickly. This quick blog post / article will get you going with it in no time.

He shows you how to install Phirum (ironicly from a PEAR channel) and how to create the XML to define the PEAR service. Running Phirum will generate a few other files based off the XML configuration and adding in a package is as simple as a "phirum add" call. He also mentions adding support for cloning packages with the help of his updated fork on github.

Tony Lukasavage has a new post to his blog about debugging your PHP applications with IntelliJ and XDebug on a WAMP install.

If you are a serious PHP developer and have not given debugging a fair chance, or a chance at all, you are killing yourself. So let's do this thing from the ground up. WAMP, XDebug, IntelliJ, and magic. Follow these steps (for Windows) to reach my recent state of elightenment and PHP debugging bliss.

It's a sixteen step process, but don't let that scare you off - it's made up of lots of little steps like "make a phpinfo() page" and "download IntelliJ IDEA". The rest is actually setting up a new PHP project, dropping in a breakpoint and mapping the scripts to run on your local machine's WAMP install.

Volker Dusch has posted a guide perfect for those looking to get their projects set up with the Hudson continuous integration tool quickly (15 minutes or so).

While [running tests on commit] is great it can be pretty tedious to run the whole test suite every time before a commit but not doing it leads to a broken test suite that other people have to repair or go around asking who broke it.. make up your own story. This is where a continuous integration (ci) server jumps in ! Every time you commit, or push if you're using git, to a repository it detects the change, gets the new version of the source, runs all your tests (and more if you tell it to) and notifies you if there was a Problem.

He chose Hudson because of its simple setup, going from download to install and configured in around five minutes. It includes a plugin system with one of the "big ones" being the xUnit integration. Included in the post is every command you'll need to get it up and running on a linux (Ubintu) system including all plugins needed and the setup of a simple project's XML configuration file (with the code to run it on).

On the AjaxRay.com blog there's a new post showing you how to set up unit testing for your Kohana v3-based application through PHPUnit.

Kohana Unittest module has made testing in Kohana v3 easy and fun. Lysender wrote a cool, straight forward post about how to set it up and running. I'll just talk here about how I have set up database testing with Kohana Unittest for my personal use. Not saying "How to set up". Because it's obviously not the best way to do this.

They walk you through the creation of the testing process - making "setup" and "tear down" SQL files, creating a "runSchema" method in a test case class and the code needed to run those setup/tear down files to refresh the database so there's no side effects of multiple tests using the same database.