You got Symfony in my Drupal 8!

Geoffrey

*updated to include clarification about DI*

If you’re working with Drupal, you’re probably aware that the next major release of Drupal is going to integrate with the wider PHP ecosystem in a big way. Its adoption of Symfony is a really big deal, not just for Drupal developers who will have a lot to learn, with access to a huge stable of components as a trade-off. It’s also a big deal for Symfony developers, who have a whole new platform to develop for, and also the PHP community at large, who Drupal developers are now able to contribute to at a much deeper level. 

We had a look around for a comprehensive list of Symfony components that are going to be in Drupal 8, but we couldn’t really find one that was up to date. For your benefit, here’s a list we put together that outlines the current list of Symfony components used in Drupal 8.

Symfony Components

Here’s a list of all components in Symfony: http://symfony.com/doc/current/components/index.html

The Symfony Project first introduced its partnership with Drupal with a post in March 2012 that discussed a few particular components that would power Drupal 8’s core:

  • HttpFoundation and HttpKernel
    The move to Symfony was spearheaded by the WSCCI (Web Services and Context Core Initiative), which wants to see the great concepts that Drupal is built upon running on top of a first-class REST server. This will allow Drupal to offer up its content via web services without so much messing about, and will generally make Drupal much more flexible, powerful and maintainable in the long run.

  • Routing
    This component maps a HTTP request to a set of configuration variables. From Drupal 8 onward, you’ll define your module’s routes in a YAML configuration file (more on this later) that lives alongside your module, and the individual routes set within it will refer to actions that are defined in your module’s classes. If you’re familiar with Drupal’s hook_menu, take note, because this is its successor.

  • EventDispatcher
    This implements the Observer pattern to enable a system-wide plugin system. This won’t completely replace Drupal’s hook system, and these will exist alongside each other until Drupal 9. However, expect EventDispatcher to power a lot of the more core-level Drupal components.

  • DependencyInjection
    Dependency Injection is a way of writing code that keeps classes decoupled from each other so that they are reusable and unit-testable. The DI Container provides the infrastructure that allows these decoupled classes to interact with each other. Expect to see a lot of this as you see more Drupal 8 code popping up.

  • ClassLoader
    This loads project classes right when they are needed, if they are named and set up in directories that follow PHP’s PSR-0 interoperability principles. This will help module developers out in a major way; there will be less worrying about module_load_include and similar dancing around to include dependencies, and more calling up classes at runtime to get things done.

Since then, quite a few other Symfony components have been brought into Drupal, but they’re not really mentioned in one particular place. Poking through Drupal’s Composer requirements, you can find the following mentioned:

  • Twig
    Themers take note, Drupal 8 has a sweet new templating engine. It was developed by Fabien Potencier, creator of the Symfony project, so we’re already assured that it will play nicely with Drupal’s Symfony components. If you’re going to be doing any theming in Drupal 8, check out Twig, you won’t regret it. (You might even look forward to it!)

  • Validator
    This component lets Drupal validate values in a general sense. We’ll start to see this used to validate form submissions, as well as validating entities in general within Drupal. This component uses Doctrine Annotations, which we’ll discuss in more detail later.

  • Translation
    Provides a standard set of tools for loading translation files, generating translated strings, and preparing them for use. Congratulations to Gábor and the Multilingual Initiative team for getting this in!

  • Process
    Executes command line commands in sub-processes. Will be used to handle a lot of Drupal’s command line duties.

  • Serializer
    Turns objects into a specific format, and vice-versa. This will be used for all sorts of things, from configuration to preparing nodes & entities for delivery by a REST endpoint.

  • Yaml
    The YAML component will serve as an integral part of Drupal’s Configuration Management Initiative (CMI), allowing modules to define default configuration settings and then letting site builders override them.
    This is a big improvement over Drupal’s previous attempts at defining configuration, which at one point were mixed up in the database with all the site’s content. Initiatives such as the Features project were a good first step to try and move configuration to the file system, but Drupal 8’s YAML-powered CMI will be a huge leap forward from this point.

Components that aren’t in Symfony (but work with it)

As well as Symfony components, there are also a lot of other third party PHP components that are popping up in Drupal 8 for the very first time. These components aren't part of Symfony as such, but tend to use Symfony components as well. Here's a rundown of what we found in core:

  • Doctrine
    Doctrine is a set of tools that works with data and databases. In particular, Drupal uses one significant part of Doctrine:

    Annotations
    This provides extra metadata to Drupal, telling it what various components are used for. This is a pretty tricky piece of functionality but it’s going to come in handy later, especially when developers need to define custom entity types.

    Drupal 8 won’t use Doctrine’s Object Relational Mapper or Database Abstraction Layer, but it may use it in a later version.
  • Guzzle
    This is a PHP HTTP client, enabling Drupal 8 to make web requests. This will become absolutely vital as Drupal sites will need to work with all kinds of web services.

  • Assetic
    An asset management framework; will help Drupal prepare additional stuff for page downloads, whether it be CSS, JavaScript, images or whatever. This will effectively take on the duty of compressing CSS and JavaScript, managing image styles, and dealing with other media types in a consistent fashion.
    There are still some issues with the integration, so we’re awaiting final confirmation about whether it will ship with Drupal 8.

  • EasyRDF
    This library makes it easy to consume and produce RDF, which allows Drupal 8 sites to produce metadata in the markup, preparing them to be first class citizens of the semantic web.

  • PHPUnit
    Industry standard unit testing, baked right into Drupal core. Drupal uses it to make sure core works the right way all the time, helps module devs build their modules the right way, and therefore makes it easier for Drupal code to be used in the wider PHP ecosystem.

  • PSR/Log
    This component provides a common logging interface throughout an entire PHP application, allowing Symfony components to log the same way as Drupal does. It is expected that watchdog will be augmented by Monolog, which makes the PSR/Log component vital in this effort.
  • Symfony2 CMF’s Routing Component
    This is part of Symfony's spinoff Content Management Framework project, but can be used on a standalone basis. It extends Symfony's routing systems and provides a couple of extra classes which Drupal is going to require.


Keep in mind that both of these lists are subject to change, so keep an eye on our blog for fresh updates as they come in.

Find out more

If you'd like to learn more about how Symfony is used in Drupal 8, watch this blog. You can also catch us in DrupalCon Portland this May, where we'll be giving a training session on Drupal 8 and Symfony. Registration is now open; we have a special for the first few tickets, so get in quick!

Comments

Thanks for the write up. Looking forward to future blog posts. I'm looking forward to diving deep into the internals of D8.

"If you already know about hooks in Drupal, you’re already aware of what Dependency Injection is."
 
Erm, no.  Hooks are more akin to events.  Drupal has no equivalent of the Dependency Injection Container in version 7 and earlier, and that's a problem. :-)  This is perhaps the largest technical shift in Drupal 8 so far, but one of the most important.  It's a different way of thinking about your code.
 
We're also not using the Process component at all.  I'm not sure why it's on the list.
 
Replacing watchdog with Monolog is not guaranteed. There's an open issue to leverage PSR-3, but as of yet Monolog is not decided.  (Additional input on that front would be welcome.)
 
The Symfony CMF Routing component also has considerable input from Drupal itself; the current code there is a collabration between Drupal and the Symfony CMF team, and it is more than just "a few classes we'll require".  It's actually the core of the new routing system. :-)

Hi Larry, 
Of course, Dependency Injection Containers are very different to the current hook system, but the idea of being able to extend a piece of code by injecting something into it as a concept we felt was very similar. With a few sentences for each of these components, its hard to capture all the specifics. 
Regarding the process component, it is a dependency for Assetic - you can see it referenced at http://api.drupal.org/api/drupal/namespace/Symfony%21Component%21Process...

How about:"Dependency Injection is a way of writing code that keeps classes decoupled from each other so that they are reusable and unit-testable. The DI Container provides the infrastructure that allows these decoupled classes to interact with each other."
It really has nothing to do with hooks :-/

Thanks, katbailey. I've updated the description with your suggestion. 

Hi there, read the article. One of the most notable changes that Drupal 8 is doing is by moving its core to Symfony 2 Framework. Symfony 2 is a high performance robust PHP framework, which utilizes the object-oriented architecture of PHP 5.3 for efficacy. Symfony 2 will help to achieve certain premeditated goals. One is that Drupal developers will have to be less anxious with writing the basic functionality, which will now be managed by Symfony.
Saurabh Saxena

Thank you for the clearly written article.

If I interpret these numbers correct, and the tests are valid, then these performance figures for Symfony2 look bad compared to other frameworks?
http://www.techempower.com/benchmarks/#section=data-r3

If so, how will this affect Drupal 8 performance?

Add new comment

Filtered HTML

  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Type the characters you see in this picture. (verify using audio)
Type the characters you see in the picture above; if you can't read them, submit the form and a new image will be generated. Not case sensitive.

glqxz9283 sfy39587p10 mnesdcuix7