Comprehending Drupal 8 and how it uses Symfony requires an understanding of what has gone before in previous versions of Drupal as well as knowledge of Symfony concepts and techniques. This talk highlights the fact that whilst Drupal 8 is using Symfony components, these are very much used with a Drupal flavour. Doctrine can only store primitive data and being a stand-alone PHP project has different event listeners from Symfony. Also Drupal always requires a render array you don’t return rendered output directly in controllers.ĭrupal has multiple APIs for storing content data, Symfony doesn’t have anything: you use Doctrine (or something else). Symfony templating uses only one file which extend twig files and override blocks defined in the parent twig file(s). While both frameworks now use twig in the theming layer, when working in Drupal 8 you work with multiple twig files for each element, mirroring templating system in Drupal 7. Also, you don’t have path nesting or slugs in Drupal 8. In Drupal 8, you can only use module routing.yml files or events, not annotations, XML or PHP. Paths and routing are handled differently in Symfony and Drupal 8. All meaningful logic in Symfony is in services, which are stateless objects. With Symfony configuration you are free to use PHP, XML, YAML or Annotations, although best practice is to pick one and stick to it.Ĭoming from Drupal 7, one of the fundamental differences in Symfony is that there are no functions it’s all methods, with only a few static functions available. Drupal 8 coding standards are quite strict in prescribing when to use YAML or Annotations for configuration. For instance Drupal always uses the View event whereas this is discouraged in Symfony. These two entry points arise from the fact that Symfony enforces a programmatic toggle between Development and Production modes: you push generated code to production heads you do not compile on production boxes.ĭrupal uses the kernel a little differently and imposes stricter coding standards. Some differences are more obvious than others, such as while the application entry point in Drupal 8 is index.php, in Symfony it’s web/app.php and web/app_dev.php. Visualisation of Symfony components in Drupal 8 Drupal uses about a third of the Symfony components and you don’t need to know Symfony to develop Drupal. Symfony for Dupal Developersĭrupal 8 makes use of many Symfony components, and this session covered the differences between the two frameworks to help decide which to use for projects.
Most of the sessions mentioned below, along with many more interesting talks, are recorded and available on the DrupalCon YouTube channel. Thanks to Riky, Tim, Andrew, Adrian and Chris for contributing their thoughts on sessions they attended any errors, omissions or misinterpretations in their edited notes are entirely mine. Our experiences of some of Tuesday’s DrupalCon sessions are outlined below.
We have been using automated deployment tools for application code for some time now in IS Apps configuration management and automatic creation of server environments is something that could further streamline our deployment workflow. It’s also interesting to see how many attendees are using tools like Vagrant, Docker and Jenkins to take the pain out of manual configuration and deployment. So far it’s been really interesting to see how sessions on Symfony and Drupal 8 this year have progressed from last year’s DrupalCon in terms of the complexity of what is being covered.
The major strands this year are Docker, performance and scalability issues, the Symfony framework in a Drupal 8 context, and using headless Drupal with an alternative toolkit to provide the front-end. On Tuesday I posted some comments on the start of DrupalCon 2015 in Barcelona, where myself and a few colleagues are spending this week.
0 kommentar(er)
