The Promise and Challenge of Drupal 8

We had an inspiring and educational time last week at DrupalCon Portland. As my first trip to DrupalCon, it was particularly exciting to see the synergy and ambition of the Drupal community firsthand. I was impressed by the community’s diversity, talent and creativity, as well as its ability to solve problems via collective momentum, such as the sprints for working on Drupal core.

I spent a lot of my time at DrupalCon learning all I could about the upcoming Drupal 8: receiving a crash course on the bleeding-edge of Drupal from the many developer-oriented sessions offered, most from those actually writing or managing the new Drupal 8 codebase. The conclusion I drew from my experience is that Drupal is maturing with Drupal 8, and shedding some of the awkwardness left over from its younger years so that it can truly take its place as one of the greatest achievements of modern open-source web technology.

From what I could see, Drupal core is undergoing a major rewrite, with the focus on making Drupal more object-oriented so that it can utilize modern OO best practices and other advances in the PHP universe. The most obvious example of this is the integration of various Symfony components into Drupal core, such as the HttpKernel component for request handling, as well as other PHP libraries that tackle specific challenges, like Assetic for asset management and Twig for templating.

Building for the Future

I applaud the approach the community is taking with Drupal 8. Shedding so-called “Drupalisms” for time-tested object-oriented techniques will strengthen Drupal and make the process of creating great web applications with it better than ever. It may also lead to the expansion of the Drupal community and an inflow of new talent and creativity, as developers trained in object-oriented methodologies will have an easier time learning and utilizing Drupal.

Drupal 8’s object-oriented way of creating modules will allow current developers to architect and build solutions that will be superior to those of previous Drupal versions, as it will be easier for them to leverage the vast accumulation of design patterns and methodologies the object-oriented school of thought has produced over the years. It will also make it easier to integrate existing PHP technology into Drupal, such as core is doing with Symfony.

This is not to say there won’t be challenges. A lot of Drupal 8 is a major departure from how developers worked with it in versions 7, 6, and before. Even the most experienced among us now have a lot to learn, and I imagine porting to Drupal 8 will be a major rewrite for many modules. Though this presents a significant challenge and a lot of work ahead, I believe it is a necessary step in modernizing the many contributions that makes Drupal great. The modules, their authors and users, and Drupal itself will be better for the experience.

So that’s my general take on Drupal 8. I’d now like to share various interesting technical points I gleaned during DrupalCon and in reading recent articles.

Dependency Injection

Firstly, Drupal in version 8 is adopting an object-oriented best practice called dependency injection. Essentially, DI involves passing an object the resources it needs to work with rather than making it responsible for managing its own resources. For example, you may have an object that needs to read in data from a data source, such as the filesystem. Rather than having the object create an instance of a file-reading object to use, you can pass that object in when creating it. That way, your object is simpler in that it doesn’t have to handle the creation of the file-reader.

The big win with DI is that it makes polymorphism easier. If you later decide that you want your object to read from a database rather than the filesystem, you can simply pass it a database-reading object instead, providing that it has the same methods as the one that read from the filesystem. Then your object can read from a file, database, or anything else without caring where the data is coming from.

Techniques like this allow us to write much more modular, maintainable code, and Drupal 8 adopts DI extensively, as well as interfaces. It even tackles the problem of managing large webs of dependencies by adopting Symfony’s DI management system, which permits easy configuration via YAML files. The modularity and flexibility offered by this system will likely make it possible to override and extend more of Drupal’s default behavior than ever before. For more info, see the video of Kat Bailey’s great session on Dependency Injection in Drupal 8.

Plugins for Reusable Code

Many other advances comprise the changes in Drupal 8. Reusable components of code can be created with plugins and plugin managers, things like blocks, field widgets, and field formatters. Plugins will use annotations instead of hooks for advertising their services to Drupal. Annotations, a concept borrowed from Java, consist of structured docblock comments that are parsable by the Doctrine library.

At first, I was unimpressed by the notion of including metadata via pseudo-code in comments, which is one way of getting around the lack of native annotation support in PHP. But I soon learned in Alex Bronstein’s Upgrading Modules to Drupal 8 session that the use of annotations instead of a static class method allows Drupal to retrieve a class’s metadata without needing to load it into memory.

Configuration Moved Into Files

A lot of configuration data are moving into YAML files, providing the benefit of version-controlled settings previously supplied by the Features module. Building on Drupal 7’s entity concept, 8 has Config Entities, objects that represent at runtime the stored configuration. This will improve the way we store and work with fields, views, and many other Drupal components. Structuring Drupal 8 with classes and interfaces makes it more lightweight, as classes can be loaded only when needed via an autoloader. This will make Drupal a better backend for JavaScript based web applications and REST-based APIs. The use of PHP 5’s new namespace feature will make it much easier to organize code.

Composer for Third Party Libraries

The last item of note I want to mention about Drupal 8 (before this turns into a ramble) is its use of Composer. Composer, like Node.js’s NPM, makes it easy to download third-party PHP libraries into your project, as well as store a configuration of which libraries and library versions it depends on via a json file. Its adoption is a big win for Drupal, particularly as the number of libraries available via Composer continues to grow. The main composer repository, Packagist.org, was hosting 10,000 libraries as of April. With Composer, Drupal developers can easily find and integrate existing solutions and focus on new challenges rather than reinventing the wheel.

So that’s my attempt at summarizing the exciting technologies that contribute to the awesomeness of Drupal 8. If you made it this far, congratulations, and I hope you found a few interesting topics to investigate further. Personally, I’m stoked to dive into D8 core and learn more about what it has to offer. If you want to keep up with further Drupal 8 developments, I highly recommend the core changelist and its informative examples.