You got Symfony in my Drupal 8!
*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.
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.
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.
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.
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.
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:
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!)
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.
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!
Executes command line commands in sub-processes. Will be used to handle a lot of Drupal’s command line duties.
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.
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:
This is a dependency manager for PHP that downloads dependencies for a particular project, on a local basis. A close analogue might be the Bundler gem for Ruby.
Doctrine is a set of tools that works with data and databases. In particular, Drupal uses one significant part of Doctrine:
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.
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.
There are still some issues with the integration, so we’re awaiting final confirmation about whether it will ship with Drupal 8.
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.
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.
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!