While this mailer class can be used with small PHP applications, it lacks some important features related specifically to its object model, since it was built in PHP 4 from the very beginning.

They review the PHP4 version of the script first then move on to the process of porting it to a more standardized PHP5 structure and code.

PHP 5 supports most of the legacy syntax features of PHP 4. Most code written for PHP 4 should function fine under PHP 5, and a comprehensive test suite could check this. However, many of the backwards-incompatible changes in PHP 5 were in regard to language quirks, and quite a few hacks rely on these in order to function.

He points out some of these hacks including changes to the object model and updates to the way variables are handled (breaking many "bad use" cases). He also points out the changes made in the latest Windows binaries as well as some of the new reserved keywords that could conflict with pre-existing code in your application.

With PHP 5.3 coming up on the horizon, I'm of course looking forward to using namespaces.

He gives an example of how useful these namespaces can be for you and your code, but points out one failing point - trying to define classes in a namespace that are named the same as a built-in keyword for PHP. There's already been a suggestion to add a captial "I" in front of the class name to prevent this collision.

There's also the problem of throwing custom exceptions - unless you use the namespace properly your script will just throw a default exception.

So after eventually getting fed up with WordPress, especially after the WYSIWYG editor disappeared in the 2.3.3 update, I finally decided to bite the bullet and migrate my blog over to Habari. Once I'd been through the process, I thought I'd write a short blog entry about the experience.

The two tips he mentions are about exporting the old content (made simple from the WordPress admin interface) and making Habari support his WordPress URL scheme (so as not to loose links to any content out there). He found this to help on that front.

It took a little while for me to get acquainted with the little oddities of the Eclipse platform. One can clearly see that it was originally tailored to fit Java development, and although PHP integration is now pretty good, things sometimes still feel a bit bloated and overly complicated. Having said that, I'm using PDT full-time for all my PHP development now and have kissed the old Zend Studio goodbye. Eclipse brings too many goodies to the table to ignore.

Among the "growing pains" he mentions are things like:

• Piss-poor network performance
• Frequent slowdowns and out of memory exceptions
• If you can, use NFS instead of Samba
• Adjust Java heap space
• Turn off unneccessary validators

Check out his post for more details on each.

In this post I'm simply going to throw out some snippets to show how I'm currently approaching the whole process in order to give both my insight into what works and what doesn't, while also hoping to get some people to share their insight into migrating legacy apps to CakePHP.

The tip in this post is primarily about the database side of things - his porting over of the information from the Wordpress table model to his new customized schema. His code example for the migration is included.

A few months ago I've posted an article about running multiple Apache instances with different PHP versions. In that article I showed how to make multiple configurations running Apache on different IP addresses. By using different ports instead of different IP addresses, we can give our customers a way to check their site before it goes live.

He modifies the settings in that tutorial with a few updates he includes to make two different apache configurations - one for PHP4 and the other for PHP5. When used together, they can run two different PHP versions on the same code, just on different ports.

In the web environment, we've typically needed hacks like populating hidden fields in a form, and regenerating the whole page, even for a tiny change. Can we make the process more rational?

This article describes a makeover of a typical database-backed web form. We'll show some old code '" a mixture of HTML, JavaScript, and PHP '" and rebuild it with modern web techniques like Ajax, and modern tools like jQuery.

In their example, they show how to take a simple form element, a select box of names, and modify it to work with an Ajax connection. Instead of having to submit the information back to to the PHP script with a form submit button, they can make a request when the user changes the select option to get that person's information. They've included all of the relevant code and some great explanation to help you recreate the example and move on to work up your own.

The first post spotlights a package that makes highlighting in WordPress simple - the iG:Syntax Hiliter v3.5 plugin. He includes some sample code to show how the CSS is formatted which, in itself, is a demo of what the plugin looks like.

The second article follows the steps he went through to make the move to WordPress URLs from the previous format. He leaned toward mod_rewrite, but decided to go a different way and whip up a custom 404 handler to get people where they want to go. He includes the code (all 15 lines of it) to show how he did it.

Today, started to test moving some of our PHP4 apps to PHP5.1.1. Some of this code was written for PHP 4.0.6, over 3 years ago. The migration so far has been relatively painless. Here are some of the problems we encountered.

Included in his list are things like:

• issues with code generators (created in PHP4) and pass by reference problems
• the classic register_globals issues
• the lack of an open source opcode cache for Windows
• and more...