By Surendra Mohan

Symfony in Drupal 8

By Surendra Mohan

If you are a Drupaler, you must be aware that Drupal 8 is on the way. What you may not know is that it includes a few important Symfony components. Working with Drupal 8.x will give Drupalers an opportunity to become a part of a massive learning curve and is going to tempt them to know more about Symfony. In this article, we discuss the Symfony components that have been added to Drupal 8, covering some third party libraries along the way.

Before we get into the actual article, let us first briefly cover Symfony. It is a PHP based web application framework that follows the MVC architecture. Moreover, it is an open source project that has been released under the MIT license. Please make sure you don’t get it confused with Symfony CMS. If you wish to explore the Symfony framework into greater detail, see its Wiki page or any of the previous SitePoint articles about it.

Now let’s learn about the Symfony components that are being implemented in Drupal 8.

Symfony components in Drupal 8.x

The following are the Symfony components that are going to power the Drupal 8 core to a major extent:

  • HttpKernel and HttpFoundation – These are responsible for streamlining the process of converting a Request into a Response with the help of EventDispatcher. Drupal 8 being moved to Symfony was driven by Web Services and Content Core Initiative (WSCCI) in a motive to transform Drupal from a first-class CMS to a first-class REST server with first-class CMS running on top of it. This initiative is intended to allow Drupal to use web services to offer its content with reduced complexity; considering this as a long term vision, Drupal will be more flexible, robust and easily maintainable CMS.

  • EventDispatcher – Implements the Mediator pattern (that uses encapsulation) in a simple and effective manner especially where code inheritance doesn’t work out, making the application highly extensible. It is more effective in situations where you tend to maintain and/or refactor a program consisting of a huge number of classes due to the fact that it makes the communication amongst the classes quite simple and easy.

  • ClassLoader – Provides tools that autoload classes and caches their location. PHP uses the autoloading mechanism to delegate the loading of a file that defines the class in situations where you reference a class that has not been required or included yet. Symfony comes with autoloaders like PSR-0 Class Loader and MapClassLoader. Implementing the ClassLoader component will make Drupal module developers carefree especially when it comes to implementing module_load_include and other dependencies. Moreover, it allows developers easy calling of classes during run-time.

  • YAML – It parses YAML strings and converts them to PHP arrays and vice versa. This format has been especially designed to hold configuration related information, while being as expressive as XML files and as readable as INI files. It serves as an integral component of Drupal’s CMI (Configuration Management Initiative) that allows our modules to initially define their default configuration settings and later allows the site builder to override the same as-and-when instructed to. This concept of Drupal 8’s CMI which is powered by YAML is a replacement for Features contributed Drupal module which proves to be a robust concept as far as migrating and deploying across environments is concerned.

  • Routing – Allows us to load all routes, and dumps a URL matcher or generator specific to these routes. This also means that it maps an HTTP request to a set of configuration variables. As far as Drupal 8 and above versions are concerned, we define our module’s routes in a YAML configuration file, each of them set to trigger a specific action that has been defined in our module’s classes.

  • DependencyInjection – Primarily used to standardize and centralize the way objects are constructed in our application. Symfony’s DependencyInjection component has been incorporated in Drupal 8 in an intention to write code in such a way that classes can be reused and unit-tested wherever applicable and desired.

  • Twig – Drupal 8 has adopted the Twig template engine. This is of interest to the themers who will probably never think of any other option again for as long as they’re working on Drupal themes. Twig was developed by Fabien Potencier, who also developed the Symfony project, and was fine tuned for integration into Drupal 8.

  • Process – Helps execute commands in sub-processes using the command-line interface. Drupal 8 will use this to handle all activities that are command-line in nature.

  • Serializer – It is used to transform objects into a specific format (eg. XML, YAML, JSON, etc.) and vice versa. To understand it better, let us look at the following schema that a Serializer component follows:

    Additionally, we can use it to accomplish a number of jobs, ranging from configuration to node and entity creation that should be delivered by a REST endpoint.

  • Validator – Helps Drupal validate values. For example: validating form submission, validating entities within Drupal, etc. To accomplish its job, it uses Doctrine Annotations (discussed in Out-of-the-box third party components section).

  • Translation – Provides a standard set of tools to load translation files, generate translated strings as output, and use the generated outcome.


Out-of-the-box third party components

We went through Symfony components that have been included with Drupal 8. In this section, we’ll find out about the 3rd party PHP components that have been implemented in Drupal 8 and are not related to Symfony. They are:

  • Assetic – An Asset Management framework. Assets in Drupal consist of CSS files, JavaScript files, images, other media files, metadata, etc. These assets contain filterable content that can be loaded and dumped. In order to manipulate assets, you need to apply appropriate filters. To understand the filters, in what situations each can be used, how-to use the filters, build, dump, and much more, we recommend you read the Assetic Github page.

  • Composer – A tool specifically designed and developed to manage dependency in PHP allowing us to declare the dependent libraries our project needs and install them for us. Though it deals in packages and libraries, it is not a package manager. Composer is a boon to Drupal 8 due the following:

    • Handles situations very efficiently wherein your project is dependent upon a number of libraries.

    • Tackles situations where there is a nested dependency concept amongst the libraries. For instance; your project is dependent upon a library (say, lib1) and in tern lib1 is dependent upon some other library (say, lib2).

    • It is Composer’s responsibility to choose which version of the package or library needs to be installed unless explicitly told which versions to target.

  • Doctrine – A bundle of tools for use with database records. Drupal 8 uses a part of it called Annotations that exposes additional metadata to Drupal. Efforts have been made to present such tricky functionality in a quite easy and handy way, especially when defining custom entity types. If you wish to explore further on how Doctrine is supposed to be used with Drupal 8, we recommend you visit the documentation page.

  • EasyRDF – A PHP library that has been used with Drupal 8 so as to provide ease in consuming and producing RDF. With the help of EasyRDF, Drupal 8 adds capability to produce metadata in the markup in an easy and convenient way. You may also visit EasyRDF official site to learn more about it.

  • Guzzle – It is a PHP HTTP client and framework that helps Drupal 8 make web requests using REST based web service calls. This makes Drupal 8 web portals more efficient in terms of handling different sorts of web services. To explore further on Guzzle, we recommend reading our previous article on it.

  • PHPUnit – Used in Drupal 8 to standardize unit testing throughout the core as well as help developers write code that is of utmost quality. PHPUnit ensures that any code written in Drupal 8 and in any custom module incorporated in it matches industry standards and works as expected throughout its life-cycle. You may keep an eye on the current status of PHPUnit’s incorporation into Drupal 8 by going here.

  • PSR-3 Logging – A common logging system that is shared by an entire PHP application. Drupal 7 and older versions use watchdog() for this purpose. Switching Drupal logging from watchdog() to a PSR-3 logging framework has made Drupal 8 more robust and scalable in terms of common logging. You may track the current status of this component at Switch watchdog to a PSR-3 logging framework.


The introduction of a few Symfony components has simplified working with Drupal 8. Additionally, including a few of the non-Symfony components has added value to Drupal 8 in terms of its quality, scalability, and performance, making it even more robust and maintainable.

  • M S

    “This is of interest to the themers who will probably never think of any
    other option again for as long as they’re working on Drupal themes. ”

    I’m having problems understanding that sentence.

    • As in, they’ll stick with Twig for good, because it’s a pretty awesome engine and included by default, removing the need to use a third party one.

      • Bas

        I tried Drupal 8 and am not enthousiastic about Twig for Drupal. Don’t get me wrong: I think Twig is a beautiful piece of software. But Drupal uses a lot of associative arrays and objects (nodes / users) which were simply passed to a theme function and could be used in a flexible way. Now every value needs to be preprocessed and prepared (escaped, converted to arrays) for Twig. The effect is that you need to know exactly which properties of the node/user/taxonomy/etc objects you will need in your theme. If you want to override the theme function you will also need to provide an additional theme preprocessor. This causes an unnecessary extra layer of complexity and I find that it makes it more difficult to alter theme variables.

        The reason I love Drupal is its simplicity. Though Drupal 8 has some great improvements I believe Drupal themers are going to hate Twig when they have to work with it in practice. They will opt to use the ‘normal’ Drupal 7 theme functions instead.

        If you are interested, feel free to have a look in the core modules of the current Drupal 8 master branch. You will find that Twig is almost never used, almost all themes are implemented by theme functions as in Drupal 7. Twig can maybe have some uses for the theme’s template files (such as page.tpl.php) but that will be it.

        • Interesting, thanks for this info. This is definitely a topic worth looking into. Perhaps a template engine comparison article once D8 is fully released.

        • Thomas Potaire

          I have experience in Symfony2 plus some degree of experience on Drupal (especially integrating Twig on Drupal 7) and I have contributions to make.

          “Now every value needs to be preprocessed and prepared (escaped, converted to arrays) for Twig.”
          Twig fully supports accessing attributes and methods of an object which is why I find your comment confusing.

          “The effect is that you need to know exactly which properties of the node/user/taxonomy/etc objects you will need in your theme.”
          I don’t understand how it would be different with Drupal 7.

          For further reading, you can go to this page:

          I just realized that you are trying to say that instead of using the function theme(), functions should return renderable arrays.

          Renderable arrays already exists in Drupal 7 and the documentation specifically advises using those over the theme function: third paragraph in this documentation

          Back to my first link, you can see an example with the differences between a theme function call and the definition of a renderable array: the differences are minimal, in fact, the amount of work to replace the function calls in your code should be super small.

          In short, the function theme() and renderable arrays are essentially the same, the only difference is when the template is rendered.

          Now, the bad part about this are the contrib modules that are using the theme function: it will work but you will need to use the Twig filter ‘raw’ on variables that have rendered HTML. This could be a problem security-wise because ‘raw’ basically turns off any kind of escaping and this is probably why they are pushing really hard on using solely renderable arrays.

        • Chris Weber

          Drupal 8 is a dramatic change for the drupal community. Drupal 8 is in a place right now where if you’re a Drupal developer or a Symfony developer you’ll see a lot you recognize. To get Drupal to place where we aren’t passing arrays around to be rendered later would take more time than we have.

          This array handling process is familar to Drupal developers who have worked in this space. And really isn’t difficult to learn for newcomers as you can see a direct relationship between what the array contains and what information is being passed to a twig template. Twig is still there to provide people familar with Twig the ability to manipulate the final markup that gets rendered to the screen. A lot of effort has been put into ensuring that Drupal does not break the expectations of twig developers within a Twig file.

          If you’re interested in how Drupal 8’s rendering pipeline is going to work you’ll want to tune into where the issue is currently being refined

  • Translation component is not being used.

  • Chris Weber

    By the time Drupal 8 is released as a final product Assetic might not be used.

  • Saf

    Some may argue that symfony is not completely MVC.

  • jamlee

    drupal8 have release RC2 now. it’s good new for me. drupal components will not be for drupal instaed of whole php world.

Get the latest in PHP, once a week, for free.