24 things about Drupal 8 every CTO should know - Part three
Are you one of the growing number of CTOs who is preparing to migrate to Drupal 8? Our technical lead John Ennew has gathered together all of the questions we’ve received to bring you some useful answers (to see all we’ve covered so far, you can read part one and part two of this post). In the final part of our mini-series, we’re going to tackle three topics: Drupal 8 in the enterprise, architecture changes, and the crucial issues of performance and security.
Drupal 8 in the enterprise
15. Does Drupal 8 make enterprise development practices such as automated testing easier?
Several improvements in Drupal 8 make it a more effective platform for practising continuous development.
The configuration management system means configuration now lives in code in a standard way meaning code can be safely transferred between environments and its behaviour is now predictable.
Drupal 8 code makes more use of objects and PHPUnit is supported by the testing infrastructure within the core codebase, meaning all code can now be written with unit tests.
Drush, the Drupal CLI tool, has been updated to work with Drupal 8 already, and can be used to automate most deployment activities from testing the quality of the custom code using the coder module, to testing the functionality using PHPUnit.
Automated testing, outside of the core codebase, has also been improved with Drupal 8. The core product now includes PHPUnit which is a test runner which allows both Unit and Functional tests. These are more robust tests that run much quicker than previous versions.
Since PHPUnit is a well recognised tool in the wider PHP developer community, hopefully finding people to write tests and finding resources to help developers get to grips with testing will be easier with Drupal 8.
Drupal 8 is also supported by the popular Behat testing framework for Symfony allowing well formed behaviour driven development practices (BDD).
16. Is it easier to manage a large portfolio of sites with Drupal 8?
Drupal 8 is a good choice for organisations maintaing large portfolios of sites. Drupal is the most flexible and extensible CMS and so can be used to develop both small, simple websites but also larger, more complex ones. By choosing to consolidate on Drupal you can reduce the development effort required in maintaining a large estate.
Drupal 8’s RESTful APIs allows you to develop the sorts of enterprise tools needed to manage an estate of sites. Features like Drupal’s multi-site and the Group module mean that you can also take a single Drupal codebase and use it to deliver multiple websites.
In addition, the new Configuration Management system means that changes can be deployed to a large number of sites far more reliably than with Drupal 7. While there will always be complexities with such approaches Drupal 8 is flexible enough to adapt to your specific requirements.
17. Has configuration management improved in Drupal 8?
Configuration management is the ability to define the configuration of a software application like a Drupal website in a testable, versionable way. In Drupal 7 it was often the case that configuration had to be done manually in each environment after a release rather than defining the behaviour of the website in each environment within the code of the website.
Drupal 7 had some addons that made exporting configuration to code possible such as the Features module, but these were never done in an entirely satisfactory manner and each module had to define its exportable behaviour to Features.
In addition, the variable table in Drupal 7 became a dumping ground of both configuration and state for each environment which meant that determining what needed to be exported into configuration in code and what could be safely ignored on a per-environment basis was complicated, time consuming and could lead to errors during deployment.
The Configuration Management Initiative in Drupal 8 has brought a standardised way for modules to define their editable configuration. Site builders can then export the configuration for an environment into configuration files which can be put into the website’s version control system and changed on a per-environment basis. This allows configuration to be audited, rolled back and be testable.
Architecture changes
18. What does Drupal 8 mean for ‘headless Drupal’?
Headless Drupal or Decoupled Drupal are terms used to describe the system’s architectural practice of separating the back-end and theming components of Drupal. In such an architecture, Drupal is used as a Content Management System for data entry and retrieval, but the rendering of web pages of content to end users (the theming layer) is passed over to another tool.
This allows development teams to build rich internet applications, mobile applications or apps for devices such as smart TVs, watches or the next Google Glass. Each of these devices have their own theming mechanisms and all of them just want pure data from the Content Management System.
Drupal 8 is capable of outputting data not just as HTML but in many forms such as JSON or XML. How it delivers data depends on the device or application which is requesting the data.
Choosing Drupal 8 as the Content Management system is a good investment for the future. Initially it may just be a website delivering to traditional web browsers, but later other apps or dynamic internet applications may be built which use the same Drupal back-end for retrieving their data.
The Drupal community as a whole is actively developing a variety to tools to make Headless or Decoupled Drupal increasingly easier. There are now modules that allow Drupal to provide GraphQL responses, the core REST APIs are improving and best practices around how to integrate with front-end frameworks such as Angular or React are being developed.
19. Does Drupal 8 change how Drupal integrates with other systems?
There are two levels at which Drupal 8 provides significant steps forwards.
At the PHP application level Drupal 8’s inclusion of standard PHP libraries means that for any particular application it is likely that a good external library already exists. There is less of a reliance on a single developer working inside of the Drupal ecosystem to meet your integration needs. In addition, the new plugin system within Drupal means that extensions to Drupal can easily be developed. This technology maintains Drupal’s position as the most extensible and flexible CMS framework available.
At the API level Drupal 8 provides mechanisms for interacting with its data via a RESTful API allowing it to easily integrate with other systems.
20. Is the database abstraction layer any different?
In Drupal 7 a process began to standardise how information is described and stored in Drupal through the Drupal Entities. This model was only partially implemented in 7 but Drupal 8 takes this much further to make it become the only model developers need to use.
As such, developers working on developing websites with Drupal 8 will work at the Entity level rather than the database level. This allows Drupal 8 websites to work agnostically with a larger number of database technologies, not just the traditional relational ones such as MySQL. For example, it is possible to use NoSQL solutions such as MongoDB as the database storage layer with a Drupal 8 website.
In Drupal 8, the database API is pretty much the same as Drupal 7, but developers should almost never be making database calls directly unless they are developing core APIs.
21. I’ve heard Symfony is used heavily in Drupal 8 core, what are the implications?
In previous versions of Drupal all the code within Drupal was built by members of the Drupal community. In Drupal 8, the developers have embraced other projects like Symfony directly incorporating Symfony components in Drupal, and, likewise, are building libraries which can be reused in other projects. Rather than re-inventing the wheel, Drupal 8 includes components developed by a larger community to solve common problems.
This means that Drupal benefits from a more stable codebase used in more projects. In return, projects like Symfony also get the benefit of more people making use of their code and so becomes more robust in the process.
A key addition benefit is that developers familiar with Symfony and not Drupal will now be able to move into Drupal development with much less effort. This opens up the pool of talent development teams can draw on.
Symfony is written using industry standards and best practices, such as PSR-4 name spacing of classes, these have been incorporated in Drupal 8.
Performance and security
22. Are there performance improvements in Drupal 8?
Drupal 8 is not necessarily faster out of the box when compared to Drupal 7 but pure page load speed is less relevant these days. Drupal 8 can scale much better and that is in large part due to a complete redesign of the caching system and the page build pipeline.
In Drupal 7, often when a cache needed to be cleared the only option was to clear all caches meaning that a small change could cause a greater strain on the website as all the caches had to refill. Caching usually occurred at the page level as well in Drupal 7, which meant that either the whole page was returned from cache or the whole page needed to be regenerated. For logged in users, generally no caching happened and the whole page was generated for every page request.
In Drupal 8 the caches are much more complex and caching can be defined and cleared in a fine-grained manner. The new Cache Tags system allows, for example, pieces of a page to be cached so that logged in users might receive most of a page from cache and just the link to their account is generated. Cache Tags also allows the developers to define specific cache-clear scenarios for their sites based on the known behaviour of the site - for example, it is possible to clear all caches which contain information about user with id 300 following an update to their account without clearing every other user’s cached data.
In addition, the cache system, like much of Drupal 8, is pluggable which means that better caching tools can be plugged in at all levels. For large, complex sites, much more precise selections of tools can be used to improve performance.
The way the page build pipeline works has been overhauled in Drupal 8 meaning that a web page is built in a much more efficient manner to previous versions of Drupal. There is also a general ‘fast by default’ principle used by the Drupal 8 core development which makes sure that nothing needs to be enabled to provide performance boosts for Drupal 8.
There two architectural improvements meant that advanced page rendering techniques such as Big Pipe could be made a part of a Drupal and in Drupal 8.1 the Big Pipe module was introduced. This technique, pioneered by Facebook, allows for different components of the page to be delivered asynchronously and while overall page build time does not improve the user’s experience of the page build is greatly improved. It feels as if the page loaded much faster because the key components can be delivered first allowing the user to focus on them while secondary components are delivered subsequently.
23. Has High Availability (HA) improved in Drupal 8?
Drupal has been used in HA environments for many years now and is a well understood problem. Drupal 8 is similar to Drupal 7 in this respect. The improvements to the caching layer means that more complex strategies are now possible with Drupal 8 and additional thought may optionally be put into the configuration of caching tools.
24. Does Drupal 8 have any major differences in its approach to security?
The key headline with respect to security in Drupal 8 is that it is now much harder for oversights or simply bad development practices to introduce problems.
At the theming layer the use of the introduction of Twig templating system as a substitute to PHPTemplate means that there is no need for PHP code within templating. Twig is full of features for ensuring a secure theming layer, which has historically been a common source of security vulnerabilities.
Another common vulnerability was introduced through site builders manually configuring text filters for a variety of third party WYSIWYG editors. While such editors are a must for a content management system installing them wasn’t supported natively by Drupal core and was one of the more complex tasks of a site builder. In Drupal 8, the CKEditor editor is included as standard with sensibly configured defaults which will work for most cases and be secure.
The PHP module has been removed from core which allowed site builders to write PHP code in the browser. This led to bad practices and also allowed a way for a malicious user who gained higher privileges in the website due to poor configuration to execute code on the server.
All input variables from the URL are properly declared by the new routing system. This means bad or unexpected data types get filtered by default. The previous CSRF protection provided by Drupal 7’s core APIs are also still available in Drupal 8.
A team of volunteers called the Drupal security team have managed looking for security issues in Drupal core and managing the security issue queue and advisory notices.
With so much third party code now required for Drupal 8 to work, managing security advisories to external libraries is more important. Modules making use of external libraries can alert to security problems with their dependencies via the hook_requirements event.
In Drupal core, external code actually forms part of the Drupal 8 codebase. When security problems are found in that code, the security team must then work with the third party developers to fix the problems and ensure security advisories affecting both code bases are released together.
Drupal 8 doesn’t provide an automated way of applying updates out of the box. However it’s possible for companies using Drupal websites to do this via a continuous integration process using the drush command line tool, version control and automated tests.
So there you have it; some straightforward answers to Drupal 8’s most commonly asked questions. Have you found it helpful? If so, don’t forget to share it with your network on social media. If you've missed it, see part one and part two.