Looking ahead to drupal 8


By Andy Thorne

on the 23rd February 2017

At work, we have recently started a new exciting CMS based project and instead of using the relatively old Drupal 7, we decided to investigate using 8. We intended to use Drupal as a backend API, interacting with a frontend using REST. On paper, 8 seemed ideal as (so they claimed) as it was fully Object Orientated, used Symfony components and it has RESTful APIs as standard. Perfect! When we started the investigation, Drupal 8 was in alpha (and as of writing, Drupal 8 is almost in beta. Hooray!) so we kept an open mind and an eye on the issue tracker for intended changes before release.

In this article, I'm going to discuss what we liked, what needs to change before release and concerns that were raised. Before we start however, let me just say that I was never a Drupal developer. I've never used Drupal X version so this is not a comparison of what has changed - It's a review of 8's design, implementation and coding philosophies. 

What's good in Drupal 8

Symfony Components

I'm not going to lie, I'm a bit (a lot) of a Symfony fan boy. As soon as I heard that the Drupal team were going to use Symonfy components, I was instantly interested. The coding standard of the Symfony community is, generally, quite high. Be it Standard Edition Bundles or new frameworks like Laravel, projects using Symfony Components require you to follow their coding standards with good structured code.

Here are a few components used in Drupal 8:

  • Http Kernel
  • Routing
  • Dependency Injection
  • EventDispatcher
  • Twig


Hooray! Drupal 8 uses Composer! Unless you've been living under a rock, you'll know that Composer is a PHP dependency manager. Using Composer, we can get rid of the awful "Copy and paste a module/plugin into X directory" - instead we can simply update the composer.json and let Composer handle it all.


Drupal 8 uses APIs everywhere. You can even have a (RESTful) API on a (core) API! This really is a fantastic positive with Drupal 8. I know that 7 could cope with APIs using plugins, but keeping them central to your coding philosophies is obviously the right way to go. They are also so easy to implement using simple yaml configs.

What's bad in Drupal 8

Composer and folder structure

Remember I said how great it was that 8 uses Composer? That, using Composer, we can install modules and their dependencies to get rid of the "Drag n' Drop a module" problem? Well that was a lie, because the way Composer has been used it completely wrong.

Firstly, when you download (or clone) the 8.0.x development branch and take a look at your directory, you'll probably say "Why is all the source code in the web root?! Why is there a modules folder?!​ "Why are all the composer dependencies checked in?!​". Or at least I hope you will!

Here's what's wrong and why:

The Drupal Core

The Drupal core is bundled into the branch and is not installable via Composer, making updating the core a complete nightmare if you have added dependencies through composer. What they should have done is just copy the way Symfony Standard Editon does it. You have the application kernel and frontend controller as a Composer project. You then make your core (drupal/drupal) installable via the normal Composer way. This way you can just let Composer handle all your autoloading and version management.


Drupal 8's dependencies have been installed via composer, and then checked in to the development branch. I have no words for this. It's SO wrong I don't know where to start. To me, it seems they have not understood Composer at all.

Briefly, the point of composer is that you don't need to check in dependencies. The composer.json (and composer.lock) files are checked in and Composer installs the correct packages and versions on install.

Web roots

Placing all your PHP source files in your document root when using Symfony (or any MVC!) is needless and potentially dangerous - especially when 'trusting' third party code/modules. It means you need to have ridiculous .htaccess files (assuming you're using apache) dotted around hiding files that you don't want the public to see. I started off by having a go at changing the web root, but soon ran into problems with module assets and URLs.

I can see why they did this. If you are using shared hosting (don't use shared hosting!) or have little to no knowledge of web servers (learn!), changing web roots in Apache may be too much and instead of using Drupal, they would use WordPress or something else. However, I feel they should have made the web root a subdirectory by default and account for this risk case rather than the other way around. Regarding module assets, you don't have to look far to see how it can be implemented (i.e. Symfony Standard Edition).

Adding Modules

Modules are still installed by downloading the source code into the modules directory (or even more worrying the core/modules directory!). Why are they not installed and managed via Composer I hear you ask? I've no idea. There is no reason for it and it worries me as this is exactly what Composer was build for and that they have not actually understood what Composer is.

Module dot files

Ah, the modules... As part of our investigation, we needed an AWS S3 module to store our media. The required module had no Drupal 8 conversion, so I set about doing it myself. 8 still uses Stream Wrappers to store media so actual implementation didn't change much, but the Drupal module files (*.info, *.module, *.install, etc) have.

The module config (*.info) has moved into yaml (now *.info.yml) as has the routing and menu components. Forms have been converted into a class that simply extends FormBase. See upgrading drupal 7 to 8 modules for information on what has changed.

The above is good. However, it's not done everywhere. For example, when install a module, the *.install file is used. The file contains php functions as hooks to install the module. This should be converted to an extendable class, like Forms has done. Really, no *.[whatever] files should exist. They should all be proper php class files. I saw that modules and hook into other modules, and their hooks are also placed in the *.module file. Module based hooks can be so easily implemented using the Symfony EventDispatcher so there really is no excuse for having these files.

Hopefully this will change, but I can't find any issues or plans to implement this.

Doctrine, or lack of it

This is more of an observation as I haven't read that much into it, but I'm not sure why the Drupal team isn't using Doctrine ORM, especially when they are using the Doctrine Annotation Reader. I think Doctrine is great, albeit not perfect, but seems like a good step up on their current entity manager.


All in all, Drupal 8 has the potential to be great. At this stage, implementing the problems we found is a relatively simple job. Leaving it later will make it more and more difficult as more modules are converted.

I pray that they fix these before the final release. If they don't, then it's certainly an epic failure and a missed opportunity.