We are welcoming some new colleagues that come from a Java background in the Onebip team, both from the development and operations field. Here's a primer on learning PHP in this situation, that you may find useful when introducing similar people in your PHP-based projects.

He breaks it up into a few sections:

• the "absolute basics" (like the differences in variable handling)
• things to not care about (like procedural PHP or the installation of Apache+PHP)
• how to "write to a graph" (things like PDO, DateTime)
• things to watch out for (like == vs === and some php.ini settings)

He also recommends doing some coding katas with TDD to give you a "crash course" in the language and help you learn from more than just reading.

I am working for an online store that has a codebase which has spanned dozens of developers and has been constantly upgraded. The codebase has its problems but it is not too bad. I would love to put it onto a framework like laravel and systematically start cleaning up as I go, but I am unsure if it will work trying to shove a framework into the current site. Has anyone done something similar, it would take me months to rewrite the whole system, has anyone done something like this successfully? Any advice would be appreciated.

There's lots of good recommendations made in the comments including:

• "If it were me, I'd take a step back before trying to build on top of a framework. I'd start by refactoring the existing codebase out into PSR-0 compliant namespace."
• "In my experience you only rewrite an entire application if what you have has become too expensive to maintain. At this point it is actually more cost effective to rewrite it using a framework."
• "We have recently moved our website to the Symfony2 framework at my company [...] it definitely is not a one programmer job."
• "Whatever you do, replace one bit at a time. And always strive to de-couple code."

Read up on the rest of the responses or add your own to the post.

Recently, I gave a lunch-and-learn to my team on the topic of Dependency Injection (DI). Instead of showing a bunch of slides explaining what DI is and what it's good for, I created a small project and demonstrated the process of migrating a codebase that does not use DI to one that does. Each stage of the project is a different tag in the repository. The code can be found on Github: http://github.com/jadell/laldi. Checkout the code, and run composer install. To see the code at each step in the process, run the git checkout command in the header of each section.

He goes through each "checkout" step (the title is the git command to run to follow along) showing how he migrated away from a simple micro-framework based site to one that defines the various objects (and repositories) inside the "application" object. He adds in a few comments to let you know a bit more about what's going on and some basic event handling. He finishes off the post with some potential issues that could come up both during the process and with the resulting application.

PHP-GTK is a PHP extension that enables you to write client-side cross-platform GUI applications. This is the first such extension of this kind and one of the goals behind it was to prove that PHP is a capable general-purpose scripting language that is suited for more than just Web applications.

The full source can be found and forked/cloned over on github and is just waiting for you to contribute!

In many ways, the SAG Awards website was a perfect candidate for Windows Azure. The website has moderate traffic throughout most of the year, but has a sustained traffic spike shortly before, during, and after the awards show in January. [...] The main challenge that SAG Awards and Microsoft engineers faced in moving the SAG Awards website to Windows Azure was in architecting for a very high, sustained traffic spike while accommodating the need of SAG Awards administrators to frequently update media files during the awards show. Both intelligent use of Windows Azure Blob Storage and a custom module for invalidating cached pages when content was updated were key to delivering a positive user experience.

He walks you through each of the five steps (high-level, obviously) that they took in the migration:

• Export data
• Install Drupal on Windows
• Import data into SQL Azure
• Copy media files to Azure Blob Storage
• Package and Deploy Durpal

Each step comes with some explanation and descriptions of the commands and tools used during the process.

The migration of the PHP source code from Subversion to Git is complete. You can clone or fork the source from our GitHub mirror, and we also now support pull requests made via GitHub. The source is also available via git.php.net, and full instructions on cloning the php-src tree can be found at php.net/git. One immediate benefit is that future PHP release tags will be signed by the PHP development team. We will be releasing GPG keys for verification purposes in the next few days. More information on the migration and the new workflow can be found at the Moving to Git FAQ on the PHP Wiki.

This move does not include the manuals yet, but that's coming soon. Be sure to follow these steps if you'd like to contribute back via the git repository. This is a great move for the project and makes it even easier for developers to contribute their fixes and ideas back to the development group!

Joshua Thijssen has also posted a guide to getting started on his blog.

IBM developerWorks has just published the final part in our series on migrating a PHP application from MySQL to DB2. [...] In addition to sharing our own experience, the series highlights the number of resources available to you to carry out your own migration.

The series is broken up into four parts:

• Prepare for your migration
• Migrate your data
• Convert your PHP code
• Deploy your application

Since October 2011, 5 million lines of the PEAR codebase has shifted to github. Hand in hand with this shift has been the tireless work of Daniel C - someone who brazenly said "I will fix the failing packages!" in the tail end of last year.

As a result of his efforts a list has been created of known good packages to use with PHP 5.4. Other results include:

• All test infrastructure upgrading to PHP 5.4 release candidates
• All database driven test suites executing properly, catching a variety of simple bugs
• Hitting a point of "near zero" patches to be applied to unmaintained packages
• Increasingly, the PEAR QA team is delivering PHP 5.3+ friendly forks of existing packages

It is much easier to do a gradual migration. Start with one part of your application, and bit by bit migrate your logic and application. The traditional way of doing such migrations is to create a new project and have parallel development on the old and the new version of the application. The problem with this, though, is that when you make a change to your old application, you have to make the same change in the new codebase, essentially doubling the amount of work for each feature you need to implement. [...] You could wrap your old application into your Symfony2 application, and have different parts of your application be handled by different versions of your codebase.

With the help of a bundle he created, IngewikkeldWrapperBundle that handles the rerouting of your requests based on where the requested resource exists (in the Symfony 1 or 2 codebase).

While the existing PEAR packages will continue to use the pear.php.net distribution and bug tracking capabilities; it's never been easier to contribute to a PEAR package - simply fork; add your changes and send us a pull request. If your preferred packages aren't yet on github, please feel free to drop us a line on the pear-dev mailing list.

Here's more about the process to get the repository set up and how to migrate your package's current code from SVN over to github. The transition's pretty painless and can make the social development and improvement of your package a lot simpler.