Drupal 8 Ready: What's new for Developers?

by chris.skene /

Share this post on social media

What are the core skills, tools and practices you will need to be Drupal 8 ready? How do you get them now? This summary is a companion to PreviousNext's DrupalCon presentation "Drupal 8 Ready".

Technology stack

Modern PHP programming

Need to know

  • Programming patterns
  • Factory methods
  • Dependency injection
  • Namespaces & PSR-0
  • Modern Object-Oriented PHP
  • Classes, objects, inheritance
  • Late static binding

In Drupal 7 and before, developer’s could largely get by with basic procedural PHP programming. With the exception of those working on Drupal core, most of us did not need to know anything more than Drupal’s hook patterns and a small number of APIs.

In Drupal 8, writing modules will require a working knowledge of a range of modern PHP programming paradigms.

  • basic OOP is now assumed knowledge and more advanced OOP patterns, syntax and patterns now exist
  • the obvious aesthetic change is we have lots of code broken out into their own files
  • more files, with less code in each file and conventions to make it all work

Resources

This last resource has the advantage of also explaining how Symfony services work, which is relevant to us.

Sessions

Symfony

Need to know

  • Symfony2 components form the basis for large parts of 8
  • Drupal 8 doesn’t work like Symfony2

Understanding Symfony2 will make you a better Drupal developer. The best Symfony resource is the Symfony website, and its online Learn Symfony book is the best learning resource. It takes a few evenings to work your way through the book and its exercises, and will give you a really good understanding of how Symfony components work, which will help your Drupal development immensely.

In some ways parts of Drupal core internals have never been better documented or learning them more accessible thanks to the symfony2 project’s resources.

Resources

New 3rd Party libraries

  • Guzzle – for fetching content from URLs (replaced drupal_http_request)
  • EasyRDF – for parsing RDF into PHP
  • Zend_Feed – for processing Feeds

Composer

Need to know

  • What is Composer and how does it work
  • When do I need to use it

Composer is a dependency management tool for PHP which Drupal 8 has adopted it to handle its PHP dependencies, such as Symfony and Twig. You will find composer.json available at /composer.json, which follows a schema in order to define the version dependencies for each required package.

Many sites wont need Composer at all, since Drupal core comes packaged, however if you wish to add new PHP libraries, you may find modules start instructing you to load them via Composer, so we put it in the 'Need to know' category.

Resources

YAML

Need to know

  • How to create and edit YAML files
  • Lots of Drupal config is now in YAML

YAML is a human readable data serialization format. YAML can be used in place of XML or JSON. It provides a much more human readable format whilst still being powerful and performant.

YAML is widely used and is a standardised format which means it is easier for people coming from other projects. Instead of having to learn a Drupal-only format such as module .info files in earlier version of Drupal, developers will be able to use YAML. YAML is easy enough to read by a human but can also be used for data processing.

Resources

PHPUnit

Need to know

  • Simpletest is replaced with PHPUnit, more or less
  • Learn to use PHPUnit

The testing framework PHPUnit has been added to Drupal 8. Simpletest is still supported but should only be used for web tests and DrupalUnitTest's that require a complete or partial Drupal environment.

PHPUnit is the de-facto standard tool to write (unit) tests in PHP and offers a long list of advantages over Simpletest, such as overall better API's, Mocking, an improved test runner, code coverage report generation and more.

Resources

Drupal

Plugins

Need to know

  • How to find, create, load and work with Plugin’s

Plugins are chunks of code that can replace or override other code, serving essentially the same purpose as info hooks in earlier versions of Drupal. Plugins are useful for extending or modifying both core and contrib behaviour. They offer more flexible architecture and make it easy to customise Drupal in a way that is also flexible.

Anyone who maintains a module that contains more than one block definition will agree that using four hooks and a massive switch($delta) statement soon gets unweildly. Plugins mean everything is in the one file. Neatly packaged up. Away from the rest of your module. Want a new block? Copy an existing one, edit. Done. Meta is defined in the same place. Then there's base classes, interfaces and inheritance. Again objects with defined interfaces are always a better experience than an arbitrary array.

Some terms you’ll need to be familiar with:

  • Plugin types
  • Plugin discovery
  • Plugin factory
  • Plugin derivatives
  • Discovery decorators
  • Plugin mappers

Resources

Entity API

Need to know

  • Entities are Classed objects with a defined Interface
  • Fields are bound to entities, and no longer shared across bundles
  • How to access entity properties and fields
  • How to define new Entities

Drupal 8 introduces a more feature rich entity API with full CRUD support in core. Entity forms have also been introduced to simplify the creation and management of entity forms.

  • Entities are now classed objects that implement the Drupal\Core\Entity\EntityInterface.
  • The default implementation is the Drupal\Core\Entity\Entity class.
  • Entity create, update, and delete functionality is now provided via the interface.
  • Users, nodes, comments, files, taxonomy terms and vocabularies have been converted to extend the new base class and interface.
  • entity_uri() and entity_label() have been removed in favor of methods.

The Entity API in Drupal 7 was limited. Drupal 8 expands it heavily in order to provide better tools and flexibility for working with entities.

Resources

Configuration API & Configuration entities

Need to know

  • How to load and save config data
  • Creating and working with Config Entities
  • How config data is managed
  • variable_get() and variable_set() are gone

The configuration API provides a central place for modules to store configuration data. This can be simple static data like your site name, or configuration for more complex business objects like field definitions or image styles. Contrib module developers can commit YAML files in a module/config folder defining the structure of their configuration settings.

In addition, Drupal 8 gets config entities, which are like regular entities only they are used for configuration – not content – and are not fieldable, and use the Config API for storage, not the database.

Resources

Routes

Need to know

  • How to write Symfony2 routes
  • hook_menu() only does menu’s now

Prior to Drupal 8, hook_menu() managed a few different features. In addition to handling incoming requests, it provided menu links, access control, action links, and a number of other features that are all very tightly coupled together.

In Drupal 8 we are using the Symfony2 Routing component, so we are able to split out the route handling aspect, and get a much improved and feature-rich solution. For example, this allows us to have multiple routes based on Accept headers, enabling RESTful web services.

Resources

Services

Need to know

  • Many Drupal functions are now “Services”
  • What are Services and how do they work
  • Accessing and injecting Services

A Service is any PHP object that performs some sort of "global" task. Each service is used throughout your application whenever you need the specific functionality it provides.

A Service Container (or dependency injection container) is just a PHP object that manages the instantiation of services (i.e. objects).

In Drupal 8, we use the Symfony Service Container component, and Services are defined in YAML files. One example is the Drupal::moduleHandler() service, which replaces a lot of functions dealing with module management, such as the function ‘module_exists()’.

In many cases, Services are injected into other classes using the Symfony Dependency Injection Container, which looks a little like this. The ContainerInterface passed to this function contains a get() method which can be used to load Services which have been defined elsewhere. This is also an example of a static factory function, which appears often in Drupal 8.

Resources

Object-oriented forms

Need to know

  • Forms are now objects, built from a common interface
  • Extend \Drupal\Core\Form\FormBase for common form functionality

In Drupal 7, forms were built by a procedural function, and validation and submission were provided by magically named functions: the name of your form building function, followed by either _validate or _submit.

In Drupal 8, there is now an interface called FormInterface. It has four methods:

  • getFormID()
  • buildForm()
  • validateForm()
  • submitForm()

The form is called in much the same way as before, using drupal_get_form(), or via a route, however now we pass the class name instead.

Resources

Other new APIs

There’s loads of them. Just know they are there, so that when the time comes to use them, you can find them again...

  • DateTime
  • Transliteration
  • Breadcrumbs
  • Modular authentication
  • Entity Translation
  • Image styles
  • Unicode
  • Crypt
  • Timer
  • New AJAX API
  • TempStore
  • Settings/Storage
  • History JS API

Other module development sessions