Drupal 8 for developers – discoveries from DrupalCon

Ever since the early versions of Drupal one of its biggest pros was the developer-friendly approach. With the introduction of Drupal 8 the CMS, its UI and UX is becoming ever more user-friendly and administrator-friendly. But there’s still plenty to keep developers happy.

Hat-tip: A lot of the following information was gleaned from Joe Shindelar’s excellent presentation at DrupalCon: “Altering, Extending and Enhancing Drupal 8” (pictured above). Here are the slides.

Drupal 8 fundamentals

Developers will find that their beloved environment has improved a lot. Modern patterns, logic and components are just some of the new additions.

But to start at the beginning, here are a few fundamental concepts of the Drupal 8 programming approach:

• Object Oriented – Drupal goes fully OOP for the first time with D8
• Autoload / Lazy load (PSR-0, PSR-4) – utilisation of namespace conventions means no more logic left lying around in PHP, improving performance e.g. loading files only when needed
• Dependency Injection – a modern and quite established software design pattern
• Services – Drupal 8 introduces the concept of services to decouple reusable functionality
• Annotations – used to provide meta information about e.g. plugins

The motto “Don’t hack the core” – well, actually the Drupal way is “Don’t modify core, without submitting a patch” – is still valid. Developers will need to create their own modules in order to extend the functionality.

But together with the famous Drupal “hook” and .module files they will find a few new friends in their everyday lives: plugins, services and events.

Plugins

In Drupal 7 we had Blocks, Field Types, Field Formatters, etc.

Almost everything is a plugin in Drupal 8. These are Discoverable Swappable Object-Oriented Interface-Driven components. Including and extending the Drupal fundamental concepts listed above.

Forget the days where to build a block you needed to instantiate BOTH block_info and block_view hooks. Info and View are now co-located in the same plugin class. Your code in the class will mainly provide the logic for the element (the render, using blocks as an example) while the annotations on your class will replace the hook_info data.

Here’s a module intended to show how the plugin system works: Plugin Message.

Services

Services are intended to provide a way to do a certain task. It can literally be any task, but ideally you should create services which share the task on your modules or other contrib modules.

A normal example is a connection to a 3rd party platform. A service which connects to the platform may be running basic tasks automatically, like authentication and session management, and then providing other Drupal modules the tools to use the platform.

You need a few steps to get such a service up and running:

1. 1. Choose a unique name, i.e. mymodule.service_name
2. 2. Define an Interface and implement it
3. 3. Register the service in a mymodule.services.yml
4. 4. Access it with\Drupal::service(‘mymodule.service_name’);

Events

Events notify the environment about a specific action so other modules can subscribe to it and react accordingly.

The Events system won’t be new to anyone who’s worked with a modern Framework (e.g. Symphony, Laravel, Cake) and now Drupal 8 has them too.

Hooks

If you have worked with Drupal before, hooks should also be familiar.

Although Drupal 8 has improved and changed a lot, to alter existing components you still need to use its hook _alter() in your .module e.g. to modify some data, settings or behaviour.

Can’t wait to build your first module and start playing with these brand-new toys? Me too!