The 3 Major Differences between Drupal 7 & Drupal 8

As a Drupal 7 grandmaster, I am very comfortable with D7. However, learning Drupal 8 has been quite the switch because of some major differences in the way you use some of Drupal 8’s API’s. There are 3 major changes that I’ve learned to love in Drupal 8.

1. Symfony/Object Oriented Programming

The biggest change you will see in Drupal 8 is that it is built on Symfony. Instead of Drupal just being a platform, it’s built on a platform as well. It can be a little intimidating at first; it affects a lot of the ways Drupal’s API’s are used. The most significant change you’ll notice as you use Symfony and Drupal 8 APIs is that most everything is built using classes. A familiarity with object-oriented programming helps you to get comfortable with the basic module development layer pretty easily.

I’ll start with the Menu API. The Menu API uses a .yml format to define routes, instead of defining them in hook_menu() in Drupal 7. It still feels similar to D7’s hook_menu() because you define a path, title, permissions, and usually a controller or form. If you want to define routes dynamically, Symfony provides a couple classes for that: Route and RouteCollection. They are used by creating a PHP file (in the Routing folder in a module root) containing a class with a public function called routes() that returns the routes and their corresponding options. You then add an entry in example.routing.yml with an entry like this:

route_callbacks:

– ‘\Drupal\example\Routing\ExampleRoutes::routes’

This method feels even closer to D7’s hook_menu().

The Form API is also a little different. Instead of defining and building a form in a stand-alone function as you would in D7, you extend D8’s FormBase class. The form is to be built in a public function you define called buildForm(). Once you are in this function it will have the same look and feel as D7’s Form API; it’s virtually the same. What’s also different about D8’s form generation is how you define validate and submit handler functions. Alongside buildForm() you can define validateForm() and submitForm() functions that handle their respective events. In order to connect the form to Drupal’s API’s you return a string of the ID from a public function called getFormId() – all of this in the same class that’s extending the FormBase class.

2. Composer

Another large change in how you do things in Drupal 8 is the use of Composer. Composer was used in Drupal 7 via the composer_manager module, but not heavily like in D8. To install D8, Composer is required; it is what loads the core dependencies that lie on top of Symfony. 

This changed the way that Drupal 8 sites are managed, developed and backed up. Using the .gitignore file, dependencies in the vendor folder are not put into source control, rather, those dependencies are downloaded upon deployment. This method of managing dependencies allows for creative ways of backing up and change tracking code. Public modules can be hosted on packagist.org and simply referenced in composer.json. Composer can also be used to run Drupal 8 core updates, not just to manage dependencies. To learn how to update core via Composer, check this link out: https://www.drupal.org/docs/8/update/update-core-via-composer.

3. Twig

One last major change from Drupal 7 to Drupal 8 is the switch from PHPTemplate to Twig for the template engine. There are several things that changed in the theming layer to accommodate this, but the end result is the deprecation of the render() function in templates. It takes some logging and debugging to understand when and when not to use render() in D7; some find it pretty confusing. In D8, when elements are passed to Twig they are then rendered automatically.

Using Twig instead of PHPTemplate does technically limit you a little bit. However, most PHP logic should be staying out of template files anyways. A part of the theming layer that was not affected by the switch to Twig include process and preprocess functions, in which that logic should lie. It makes for more clean, organized and maintainable code, on top of measurable performance improvements.

The naming convention of the files stays virtually the same, except for the extension (.html.twig instead of .tpl.php). The printing of variables, the use of conditionals, and the use of loops and iterators are about the same in PHPTemplate and Twig. There are a few syntax changes that you’ll need to get the hang of that will allow you to use those things and control others like filters and whitespace. You can read a comparison of PHPTemplate and Twig theming paradigms here: https://www.drupal.org/docs/8/theming/twig/comparison-of-phptemplate-and-twig-theming-paradigms.

If you are still running Drupal 7 and need help migrating to Drupal 8, give us a call. We can help.


Do you need some help?

Let's get started. Tell us a little about yourself and your organization
and we can start a conversation about your needs and our capabilities.

Related Posts