On the LeaseWeb Labs blog there's a continuation from a previous post about migrating your Symfony1 application over to Symfony2. In the first part of this series of posts, Stefan Koopmanschap talked about wrapping your code to make it work. In this second post, Maurtis van der Schee tackles two issues Stefan mentioned - performance problems and handling authorization/authentication.

On December 21, 2011 Stefan Koopmanschap wrote an excellent article on this blog titled "Painless (well, less painful) migration to Symfony2." [...] We were very much inspired by his passionate elucidation and we were fully convinced of the urge to start migrating to Symfony2 as soon as possible. However, he also provided us with a "A word of caution" about 2 things: performance and authentication/authorization. This might get some people worried, but not us: it challenged us to find a solution for those two open issues.

They explain why these two things are a problem and some of their solutions they've created - a .htaccess for routing and manually replicating the Symfony2 session in the Symfony1 code. Included in the post are the rewrite rules and code to make these two things happen (and a small configuration change to make them work).

In a new post to his blog Dave Marshall shares a homegrown migration tool he's created to help make database migrations a simpler task - phpmig.

I've previously blogged about migrations with phing and dbdeploy and also porting ActiveRecord::Migrations to PHP, now here I am again blogging about yet another way of doing migrations in PHP projects. Only maybe this time it's different, maybe this time I've found a way I'm happy with...? Phpmig is a simple migrations system that was written to be easily adopted regardless of the framework or libraries you are using. It requires a little bit of setting up, but if you know you should be using migrations, you're probably more than capable.

He's worked up a sample application to show you how to get things set up and working - a basic Silex-based application. Phpmig is used to create a basic bootstrap for the deployment that includes the use of Pimple for dependency injection and a command-line interface to generate a migration skeleton class for the up/down methods. The source for phpmig can be found on github.

Chris Hartjes, after finally figuring out an issue with database migrations with Doctrine on a Zend Framework application, has posted about the process to his blog today. As he notes:

This posting is a lesson on the value of actually looking at the source code of a third-party library when you are trying to figure something out...

His problem wasn't with the features of Doctrine and how easy it made to automate things in his environments (continuous integration). His issue was that Doctrine wanted to run all of the migrations every time it was executed. Upon closer inspection, he found the key - a migration_version table in his database that held current migration information. He includes a simple Zend Framework-based script he's now using get the latest value from that table and execute only the migrations after that. The migrations are executed in order - he recommends using a timestamp or formatted date on the filename to set the order.

On the Ibuildings techPortal today Harrie Verveer has a new post looking at database version control - one of the more difficult topics for development groups - and some of the technology that can be used to help make it a bit simpler.

Database version control is something that most developers have to deal with regularly, yet only a few have actually thought about what solution might be best for them. Most people have a solution that sort of works for them, but when you ask them about the subject they are pretty convinced that there must be some better way to manage database changes, they're just not entirely sure what that solution is - but the silver bullet must be out there somewhere, right?

He starts where most developers start - their own custom script. It usually will take in a series of patch files and apply them one by one. In this case a "patch level" is stored somewhere (file/database) and is checked when the deployment is done. He points out a few issues with this method including patch naming issues and branching. Taking a step up the technology tree, he looks at other solutions like Phing+DBDeploy, Liquibase, and Doctrine migrations to try to help you find your project's "silver bullet".

On the ServerGrove.com blog today there's a new tutorial posted showing how to, using symfony and the Apostrophe CMS, create a full staging and live setup with different URLs for each.

This system allows you to make changes to a website and preview them before actually going live. It can be implemented with any website, we will show the necessary requirements and steps to implement with symfony and Apostrophe CMS, but you can also take parts of the tutorial and implement them without these applications. We have found this workflow suitable in a number of projects and wanted to share it.

The process can be modified to fit the needs of your symfony application (or really any app with enough tweaking) since it uses several "off the shelf" tools like Apache, PHP, symfony, Gearman and Supervisord. The sfSyncContentPlugin plugin is a bit more specific to Apostrophe, though. They walk you through the integration of all of the tools - starting up Gearman and Supervisord, making a worker and setting up your symfony configuration to have a "publish" route to set things in motion.

Kevin Schroeder has posted an article he'd written for the Zend news letter about non-PHP developers branching out into PHP for the first time and how easy the language makes it.

I have had the benefit of being able to program in many different languages for many different environments over the years. Throughout that experience there are 2 languages that have risen to the top of my favorites list. PHP is one, obviously. But Java is the other. [...] To access all of the functionality in Java, there is a tradeoff with simplicity. To access all of the functionality for the web in Java, there is a massive tradeoff with simplicity.

He notes the cost of using one over the other (hint, PHP's usually cheaper) and, an interesting point, a story about a Java developer that took around two days to get comfortable with PHP. He lists a few things PHP offers that help including the low installation/initial code barrier, loose typing and the definition of functions without a return type.

On the Ibuildings blog today Andy Thompson has a new post looking at some of the challenges of migrating PHP applications up from the now end-of-development-life PHP 5.2.x versions up to PHP 5.3.

According to a recent Twitter poll, we found that over 50% of developers are already working with the latest 5.3 release. An additional 35% is already in the process of migrating to 5.3. This means that the majority of developers see the importance of upgrading and are already taking action, well before PHP's announcement.

He talks about how common migrations like this are in the IT industry and how dealing with multiple releases can only cause more issues. He also mentions some of the keys to successful migrations like compatibility testing and checking of any custom code you might have implemented in your codebase.

Rob Allen has a new post to his blog today that looks at database migrations in Zend Framework applications. He introduces a component of his own - Akrabat_Db_Schema_Manager - to handle the migrations.

It is intended that any time you want to make a change to your database schema (add columns, tables, indexes, etc), then you create a new migration file. [...] The migration file contains a class that extends Akrabat_Db_Schema_AbstractChange and must contain two methods: up() and down(). It follows that up() is called when implementing the changes in this migration and down() is called to put the database back where it was if the change is backed out.

He includes an example of a migration file, one that defines the "up" method to create a table and the "down" to remove it. The Akrabat_Db_Schema_Manager is what your script would interface with by calling the "updateTo" method and change your database's structure. It can even hook into Zend_Tool to make it command-line friendly.

New on the Zend Developer Zone is an article looking t migrating your application from PHP 5.2 up to 5.3 (relatively) painlessly.

Quick research shows that most prominent applications had to be patched or changed, even though minimally, to work cleanly with 5.3. To help people to convert their web applications to 5.3, I present here a migration script that would allow you to inspect your applications for potential migration problems. Do not expect supernatural wonders from it, but it may save you some valuable time.

The migration script looks for a few things (like bad use of magic methods and the use of deprecated functions) but doesn't catch bad use of reference or, of course, fix the issues for you - you'll still need to make the recommended updates yourself. An example of its use and output is also included.

In this recent post to his blog Till Klampaeckel starts off a series directed at PHP developers looking to make the move from the MySQL relational database structure over to the world of CouchDB.

My idea is to introduce CouchDB to a world where database-driven development generally refers to MySQL. By no means, this is meant to be disrespectful to MySQL, or SQL-databases in general. However, I'm a firm believer in using the right tool for the job.

He uses this first post to introduce some of the basic concepts behind CouchDB like document-oriented vs row/table-oriented, Couch's erlang roots and connecting to it via a RESTful or JSON interfaces. He gets into the basic installation (via a package) and how to connect to the server for a sample query. He also mentions some packages that can help abstract out the PHP layer from a direct connection like HTTP_Request2 or phpillow.