Mark Ferree Director of Engineering
October 2, 2012

Last week in San Francisco, around 200 PHP developers, myself included, gathered for the Sensio Labs Symfony Live conference. For the uninitiated, Symfony is a full-stack PHP framework made up of a collection of 23 individual components designed to solve common web development problems.

So why are we talking about Symfony on a Drupal company blog? The Drupal community has recently been letting go of "not invented here" and looking elsewhere for code that might share common goals. Drupal 8 is currently in rapid development and many components of the Symfony framework have already been incorporated into Drupal core. Including this much external code at the infrastructure level of Drupal marks a major paradigm shift for the project — and hopefully the beginning of a shift in the wider PHP open-source world as well.

The Drupal community has tried this before, with mixed results. Drupal's early adoption of jQuery is seen almost universally as a smart move and probably helped contribute to the widespread success of jQuery. Simpletest, on the other hand, had to be heavily modified for Drupal's needs, and still needs to be maintained by the Drupal community as a separate project. Meanwhile, back in 2012...

Fabien Protencier, the creator of the Symfony framework, opened Thursday morning with his keynote. First up? A discussion about release cycles: a topic that only an open-source developer or a Microsoft project manager can truly get excited about. One thing for Drupal to note is the beginning of long-term support (LTS) releases for Symfony. This means we can incorporate Symfony components with the assurance that upstream bug fixes will continue for three years (which happens to be just about the average lifetime of a major version of Drupal).

One risk for any open-source project (or any project, period) incorporating outside code is the possibility of having to maintain that code over the long term. In this case, the Drupal community is assured that the efforts of the 500 Symfony contributors who helped with the latest release of Symfony will continue to benefit Drupal, and that we can make concrete plans on when and how to incorporate future changes into Drupal.

Symfony's policy on backwards compatibility is another keynote tidbit that may affect Drupal's own releases. Symfony will maintain backwards compatibility for all 2.x releases, leaving any breaking changes for 3.0.

After lunch on Thursday, Drupal's own Larry Garfield took the stage to let the Symfony world know what Drupal's doing with their code. In short, Symfony now owns Drupal's requests. From initialization on down Drupal's 1,000 possible routes, every Drupal request will now be touched by a Symfony component.

"Drupal is an 11-year-old, PHP4-based extensible Slashdot clone built by a Belgian college kid."

At DrupalCon San Francisco in 2010, there were discussions around enabling Drupal to deliver content to the plethora of devices that'll soon explode onto the web development landscape. These discussions spawned the WSCCI initiative.

Initially planned as a re-envisioning of Drupal's own request handling, the WSCCI initiative eventually looked outside of Drupal for inspiration in handling this problem. Symfony's Lukas Smith and Fabien Potencier joined in on one discussion of HTTP libraries; their engagement helped establish the HTTP Foundation Component as a viable drop-in replacement. Once HTTP Foundation was committed to Drupal core, the floodgates opened and many other parts of the Symfony framework quickly followed.

Curious about Drupal's new accomplices? Here's a quick overview of some of the major Symfony components already in Drupal 8:

  • The HTTP Foundation Component is at the core of any framework built on Symfony. This is where request and responses happen. A request object is created containing information similar to what you find PHP's $_SERVER superglobal. In return, a response object spits out content. 
  • The HTTP Kernel Component is responsible for what happens between the request and the response. It essentially finds a controller and executes it. It defines the pattern of translating a request to a response. 
  • The Event Dispatcher Component implements the observer pattern, enabling the system to attach code to specific events. Imagine Rules and Hooks on steroids. 
  • The Routing Component gets passed a URL and returns an array of info about the route. If it finds a good controller match, it gets executed. Drupal has around 1,000 possible routes, so Drupal's implementation won't be quite this simple. (For Drupal's needs, this has also been extended with a new standalone mime-type negotiation library.) 

Drupal isn't just using Symfony's libraries: the integration has resulted in many fixes and new functionality for Symfony in return. The more we see different and disparate projects using these components in unique ways, the more powerful and robust they'll become. The reaction from the Symfony community? Well, we'll let them speak for themselves: