On the Symfony blog there's a new post about a major upcoming milestone for the framework: their 500 millionth download of version 2.0 of the framework.

Symfony 2.0 was released on July 28th, 2011. The biggest difference from Symfony 1.x was the internal architecture of the framework, which was designed around a set of stand-alone and decoupled PHP packages called Symfony Components.

In the five years since it's initial release the download count is getting closer to the 500 million mark all the time. They've even provided a real-time(ish) dashboard of the current count so you can keep track yourself if you'd like. The post also asks the Symfony users out there to share some of their own photos on Twitter of when the milestone is reached and even offers potential prizes to those that participate (a raffle).

So talk to your work mates, prepare a way to display symfony.com/500million in your office and share some photos of the moment so you get a chance to win. And while we wait for the moment ... keep downloading those Symfony packages!

Matthew Weier O'Phinney has a recent post about recent work that's been done to split up the componenents in Zend Framework 2 into their own repositories and linked as dependencies.

Today we accomplished one of the major goals towards Zend Framework 3: splitting the various components into their own repositories. This proved to be a huge challenge, due to the amount of history in our repository (the git repository has history going back to 2009, around the time ZF 1.8 was released!), and the goals we had for what component repositories should look like. This is the story of how we made it happen.

Matthew talks about the methods that were used to split things apart, even more so than they already were. While the components could be installed separately before, the methods used to get there were "cringeworthy". He talks about the different methods they've tried and the version bump issue that came with them, even when no changes were present. He talks about the ultimate goal of the refactor and the techniques to get there - a combination of grafts, subtree, subdirectory-filter and tree-filter through git. He covers some of the "stumbling blocks" they hit along the way including empty merge commits. The end result was a one-line command that could be executed and split out the provided component (well, with a lot of help behind the scenes).

He ends the post talking about the speed of the extraction process (hint: parallel processing is a happy thing), the ultimate results of the entire framework being split and a few lessons they learned along the way.

On the SitePoint PHP blog today there's a post introducing you to the concept of building a framework with Symfony components, using only the ones you need from the Symfony framework ecosystem to create a customized framework to fit your needs.

You’ve probably met Symfony in your PHP career – or have at least heard of it. What you may not know is that Symfony is, at its core, composed of separate libraries called components, which can be reused in any PHP application. For example, the popular PHP framework Laravel was developed using several Symfony components we will also be using in this tutorial. The next version of the popular CMS Drupal is also being built on top of some of the main Symfony components. We’ll see how to build a minimal PHP framework using these components, and how they can interact to create a basic structure for any web application.

He covers some of the main parts of the framework, how to grab the components that will help with some of the common functionality and integrating them to work together. He uses the HttpFoundation, HttpKernel, Routing and EventDispatcher (along with their own dependencies) to create a simple example that will respond to a few different route requests.

On the QaFoo blog today the company is introducing a new tool to help PHP developers write better, more optimized code - the PHP Refactoring Browser (written in PHP too).

Without continuous refactoring, code maintainability and extensibility will start to decrease fast, even if it has tests. Until now, only IDEs contained functionality to perform automated refactorings. And then even only PHPStorm contains the most important refactorings such as "extract method". Today we release the PHP Refactoring Browser, a refactoring tool written completely in PHP. It is based on several outstanding open-source libraries.

The browser currently supports multiple refactoring methods including the extract method, renaming of local variables and converting a local variable to an instance. They include some example code and the result from the execution of the tool. The output shows where refactoring would work best with some color coding and formatting.

You can find more about this new tool over on its github repository.

On the Symfony blog there's a recent post talking about the availability of the SF2 packages as standalone components available for separate downloads.

Each Symfony Component has been available as a standalone "package" for a very long time, but this is the first time I post something about this on this blog. That's because the way it was done was quite experimental... until recently. Why is it useful? Let's say you have a project that does not use Symfony, the full-stack framework, but you still want to rely on a few Symfony Components like YAML, Console, and Process for instance. In that case, instead of depending on the main symfony/symfony code, your project can just depend on these specific components.

An example of the composer.json configuration needed to grab individual components and define a "minimum stability" for the sources.

The new version has been online for the last week and the Components are now updated 1 or 2 minutes after some changes are pushed to the Symfony component. Unfortunately, we have had one force push during that time due to a bug in the Git subtree command (I haven't found the time to submit a bug report yet).

Fabien Potencier has posted the eighth part in his "building a framework on Symfony2 components" series. So far he's created a full-featured microframework with routing, controllers, HTTP handling and namespaced code. In this latest part he improves the sample framework by adding some unit tests.

Some watchful readers pointed out some subtle but nonetheless important bugs in the framework we have built yesterday. When creating a framework, you must be sure that it behaves as advertised. If not, all the applications based on it will exhibit the same bugs. The good news is that whenever you fix a bug, you are fixing a bunch of applications too. Today's mission is to write unit tests for the framework we have created by using PHPUnit.

He includes the XML for a basic phpunit.xml configuration file and uses a UrlMatcher and ControllerResolver in a "Framework" class and makes the test check for "not found" URLs and for checking for a correct Response.

Fabien Potencier has posted the seventh part of his series looking at how to make a custom framework on top of the components from the Symfony2 framework. In this part of the series he improves his basic framework by adding some namespacing to organize the application a bit more.

If you have a closer look at the code, front.php has one input, the Request, and one output, the Response. Our framework class will follow this simple principle: the logic is about creating the Response associated with a Request. As the Symfony2 components requires PHP 5.3, let's create our very own namespace for our framework: Simplex.

He puts the main front controller in just the "Simplex" namespace but adds in others for the controllers and models. He also updates his Composer configuration to create some PSR-0 autoloading.

Fabien Potencier has posted the third and fourth parts of his "Build a framework on top of Symfony2 components series to his blog:

• Part three adds on another page to the sample site, creating a front controller and changing the output to use "setContent()" instead of just echoing the data.
• In part four he refactors the code to be a bit more readable, adds in the Symfony2 Routing component to correctly get the requests to the right controller and an example of how to generate routes based on route definitions.

You can find the other parts of the series here: part one, part two.

Fabien Potencier is back with the next installment of his "Building a framework on top of Symfony2" tutorial series with this look at using the HttpFoundation component to use the Request and Response classes to handle HTTP interaction. (Part one is here.)

The first step towards better code is probably to use an Object-Oriented approach; that's the main goal of the Symfony2 HttpFoundation component: replacing the default PHP global variables and functions by an Object-Oriented layer.

He shows how using this component not only makes OOP handling of requests/responses simpler, but also helps to make your application more secure through features already included in the HttpFoundation component. Sample code is included showing how to fetch the current request, get filtered values from the superglobals (GET/SERVER/etc) and how to respond with a refactored version of the "Hello world" message from the previous example.

Fabien Potencier has a new post to the Symfony blog today - an announcement about the setup of a PEAR channel to make it easier to grab the various Symfony components individually.

One of the strengths of Symfony2 lies in its components; they define the building blocks of the framework and they can be used as standalone libraries. [...] The Symfony2 components have been available on Git for quite some time now, and as of today, I'm really excited to announce that they are also installable via the brand new Symfony2 PEAR channel, powered by Pirum of course.

Packages included in the list installable on the PEAR channel include:

• BrowserKit
• DependencyInjection
• HttpKernel
• Serializer
• Validator