Contrasting the differences between the latest and previous version(s) of Drupal

As you gear up to build your next (or first) website, the process of landing on the tech that will be used can come about in different ways. A few contributing factors may include one of the following or a combination thereof:

 - The client/stakeholders have experience with (insert CMS here)
 - The developers/agency building the site have experience building with (insert CMS here)  
 - The project lists specific requirements that make the decision more obvious.
Let's assume we're concerned with building a website. We then choose from available content management systems. That decision automatically rules out other offerings such as Laravel or Ruby on Rails, which are typically more suited for application development. This then leaves us in the modern age with few popular and well supported content management systems to choose from. In our case, we support Wordpress and Drupal predominantly, as those happen to be the common choices. For arguments sake, let's say the choice has been made to use Drupal.

The decision making doesn't stop there, however. We still need to decide on a version of Drupal to use. Usually one picks the latest version of any given technology and that's the end of it. In Drupal's case though, there are significant differences present that make us choose which will be best suited to our needs. The short answer, especially at the time of this writing, is to just use Drupal 8. But further discussion below will expose just how different the two latest major versions are, and how they can almost seem like different products. 

It's true, latest is greatest

On November 19, 2015, the 8th version of Drupal was released, setting in motion the deprecation of previous versions. Most imminently effected was version 6, which has been out since February 2008. The next concerned was Drupal 7, which has been out since January 2011. Typically with Drupal major version changes, developers have seen just how major the changes have been that separate each version. That idea has likely never been more true than now as we examine the leap Drupal has made between versions 7 and 8. While there are strides being made to assist upgrading between versions, more complex sites may need to just be rebuilt coming from version 6 or 7 of Drupal. If this entry point is for a new site, Drupal 8 would certainly be our recommendation. The mindset may be to just build in Drupal 7 right now and then upgrade in 6 months to a year once Drupal 8 becomes more mature, but it would be much easier to just start with 8 now.

Since there are many blog posts out there that cover the decision to choose Drupal 7 or 8, we'll just cover the high-level points below and some things we've seen and used that make 8 stand out as the right choice. Outside of the version argument, it also serves as another general feature breakdown in case you're just not that familiar with the new offerings of version 8.

Drupal 8 has a strong core

There have been improvements in getting much of the common functionality into the core of Drupal. This means these often installed modules now ship as part of Drupal itself and can just be turned on. Key features that used to be excluded or otherwise take many discrete modules to setup are now included by default and are more streamlined as well. Below are a few highlights and a little about each.

Inline form errors    

The inline form errors module helps out with all forms on the website by leaning towards the gold standard of form error handling and display. Just turning the module on, it will start improving the accessibility of form errors that occur whether it be for a custom form coded with the Form API, a form created with the webforms module or a form built with the core forms module.

Content moderation and workflows

In previous versions of Drupal, you'd typically have to install something like "Workbench Moderation" to get a revisioned content authoring workflow. A solution similar to this is now bundled into core. It's made up of two parts. One is called Content Moderation and the other is Workflows. The former offers the ability to put content into different states, such as published, draft or archived, and the latter helps define those states and their transitions. So if you wanted to have content reviewed before publishing, you might create a new state called "review" that content needs to transition through before it can be moved into being published.  

Advanced caching

In Drupal 8, we see the introduction of a new kind of cache called the "Dynamic Page Cache". This ones deals with both anonymous and logged in users but adds in complexity to handle cache contexts and placeholders to deal with personalized parts of the page. This kind of control was not possible in earlier versions of Drupal and the API changes made in the recent version make this possible. The "Internal Page Cache" is more analogous to what was used in Drupal 7 for anonymous users whereby it caches the whole page for everyone. Both caches are enabled by default as well, making Drupal 8 fast out of the box. This has the side effect of making sites built with this CMS generally faster as it is treated as more of a default. However, the internal page cache may need to be turned off if your site deals a lot with logged in content and much personalized data.

RESTful web services

Drupal 8 now bundles into core the RESTful project. This is an exciting time to have this available as we start to build more decoupled solutions using often the same data set. One example where this could be used is with an existing Drupal 8 site and the need for a mobile app. The app may be designed to only pull out certain types of content from the website. This would be fairly straightforward to do given the content access point provided by the provided web services.

Another common use case that is gaining momentum is to use Drupal as the backend to store and enter data, but develop a completely custom front end that interacts with Drupal and reads/writes data to it. There has been much talk about whether or not this is a feasible approach, but one at least worth considering.

Providing an API can be hard for many reasons, which have been discussed over on Lullabot's blog. The core offerings provide a good starting point, but other addons may be needed to help boost usability and conformity. Some other cool projects that are in the works that compliment the core RESTful web services are these:

  • JSON API - A no configuration set and forget module that helps your API conform to the JSON API specification.
  • Schemata - Provides schema definitions for Drupal entities that are available through the API
  • Docson - Provides a visual representation for the previous module.  

Composer workflow

Drupal 8 now adopts a package management style workflow using composer. This makes the development and deployment process more in line with other contemporary frameworks that use a package manager to handle dependencies. This is one of those features that mostly affect only the developers but one that we're glad to see. This really became a necessity as Drupal started moving towards other technologies to build itself up. 

In case you're not familiar with package managers, they work by reading from a manifest of dependencies that need to be included for the core project to run. Drupal itself defines dependencies and as you build out your project, modules you install and PHP libraries you define also get included into that main file, called composer.json in this case. The benefit here is that you only need to store your core code in source control and then have all the needed supporting code pulled in, defined by specific version. This also comes in handy while deploying as well, as you just need to place your core code and the manifest on the server and run an install command to request the needed files.

More information on this change can be found in Drupal's documentation about developing using composer.    

Better translation handling

Version 8 now makes the whole localization task easier. With only 4 core modules, you have everything you need to build a localized website. The switch over to having everything be "entities" in Drupal helps this as well. Instead of having separately stored versions of your pages, they are just a single page now with separate language information stored on them as meta data for each language. This concept spans to other entities in the system as well such as menu items, files, blocks, taxonomy terms, users and comments. Here is some more information about the state of localization in Drupal.

Better blocks

There have been some updates with blocks as well. In previous versions of Drupal, you could only have one instance of a block by default (without adding in contributed modules to fill out this functionality). Now you can use the place block button for any region in the backend to create multiple instances of any existing block. This helps in defining a block once and placing it in multiple places without having to duplicate editing efforts. 

The other big feature that was added was custom block types. Not unlike content types in core, you can now create custom block types with fields. This is in part due to the help of blocks being setup as entities, just like menu items, taxonomy terms, comments, and node are. In the past, you'd typically have to rely on the contributed module BEAN to supply this equivalent feature.     

Date field, CKEDITOR and Views in core

These are some of the most used modules and have been brought in to core as well. This should mean better support and improvement as core gets developed further. Given this change to have Ckeditor in core, it is noteworthy to mention it now uses Drupal's plugin system as well to extend it using, often using many of the already available ckeditor plugins.

Theming is better

This reason to switch is huge as well. Drupal 8 now uses the twig templating engine for its view layer. This makes things more familiar for developers coming in from other frameworks that often have a separate layer for output.

It also helps with separation of concerns and security. No longer can you get away with having long, monolithic PHP templates that contain the view elements alongside the code that sets up that display. Drupal forces you now to adopt best practices in this regard and in doing so enforces security best practices as all data coming into those twig templates are sanitized to remove any risky injected code.    

D8 infrastructure vs D7

Before Drupal 8, there had been an idea that Drupal and its community have been living on an island. Metaphorically speaking, this described the ways of developing technologies and of handling problems proprietary to itself, commonly referred to as "Drupalisms". With version 8 comes this idea of moving off that island. This is done by starting to adopt existing libraries to build Drupal itself and also in doing so provide a more familiar developer workflow. Some highlights include Symfony, AsseticDoctrine, GuzzleTwig and many others. By using existing best of breed solutions for common problems, the Drupal community can have a great existing software and development experience, while allowing time to focus on greater far reaching concerns upcoming in future releases.

Another big shift is the move towards Object Oriented Programming. This is a side effect of adopting parts of the Symfony framework, but also comes as a decision to make Drupal 8 learn more towards OOP. This, again, will help onboard existing developers, making things more familiar and removing the need to learn any "Drupalisms".

Long term support and SemVer

Each version of Drupal has typically also enjoyed a long lifetime before the next version release. This has been a bit of a double edged sword in that you have a maintained, stable version of a product that once built, can remain for a good amount of time without having to rebuild or upgrade. However, in Drupal's case, that length of time between versions brought much change to the web. When jumping between major versions, you'd basically have to re-write the system so much that it is very different from the previous version, which is what happened.

Now with Drupal 8, another initiative has been developed to release more often (twice a year) and to be more in line with the update schedule seen by many other software projects, the new Microsoft Windows release cycle being an example. Along with these steady, predictable updates, we can expect the eventual move to Drupal 9 to not deviate from this very much. Gone will be the pain of having to suffer through major version upgrades every 5 or so years, which usually involve re-building the site in the new version given the vast differences the major versions has to offer. Dries Buytaert blogged about this change to make upgrades easier going forward.

Also, as part of this release cycle change, Drupal has now adopted semantic versioning. This system helps to more clearly identify when changes could be breaking your existing code. Given the following format, it provides more definition than arbitrary numbering that isn't tied to the reason the updates are being released.

SemVer is a 3-component system in the format of x.y.z where:

x stands for a major version

y stands for a minor version

z stands for a patch

So you have: Major.Minor.Patch.


Given the above features and improvements over previous versions of Drupal, it's clear that there should be no other choice than Drupal 8 or later unless there is a very good reason to use an older version.