John Ennew, Drupal 8 contributor and Deeson technical lead has collected together the questions we’ve been receiving from clients about Drupal 8 into one handy list.
John is a speaker at DrupalCon and maintains Drupal modules used on thousands of websites throughout the world. He holds a Masters in Computer Systems Engineering and is an IET Chartered Engineer, in addition to winning ‘Techie of the Year’ 2015.
Do you have a question that we haven’t answered? Drop us an email firstname.lastname@example.org or ask in the comments.
1. Why did Drupal 8 take so long?
2. When should I start building on Drupal 8?
3. How long until common contributed modules are going to be available?
4. How much do Drupal 7 developers have to learn?
5. Will Drupal 8 make Drupal builds cheaper?
6. Will Drupal 8 sites be quicker to build?
9. Does Drupal Commerce feature in the Drupal 8 release?
10. Are multi-lingual sites handled differently in Drupal 8?
11. How is the content editor experience different in Drupal 8?
12. Does Drupal 8 handle complex user and content permissions any differently?
15. Does Drupal 8 make enterprise development practices such as automated testing easier?
16. Is it easier to manage a large portfolio of sites with Drupal 8?
17. Has configuration management improved in Drupal 8?
18. What does Drupal 8 mean for ‘headless Drupal’?
19. Does Drupal 8 change how Drupal integrates with other systems?
20. Is the database abstraction layer any different?
21. I’ve heard Symfony is used heavily in Drupal 8 core, what are the implications?
Drupal has been around for 15 years and Drupal 8 has been in development for 5 years. This sounds like a long time to produce a release.
Under the hood, Drupal 8 has lots of big changes from Drupal 7. Many new programming concepts and paradigms have been adopted which will make Drupal more standards-compliant. This has meant removing old, more Drupal specific ways of doing things and embracing more widely known standards and technologies.
The discussion plan in Drupal community is that in future there will be gradual, phased releases allowing feature development to proceed in separate branches, rather than waiting for other functionality to produce a single large release like Drupal 8.
Drupal 8 should be considered for all projects from now onwards. The decision on whether it’s the right time for a specific project will depend on the appetite for risk, the nature of the functionality and complexity of the project.
There are many contributed modules that don’t have a stable release yet. This means a project may end up building a Drupal 8 version of a particular tool which would be available ‘for free’ in Drupal 7.
However, this is likely to be outweighed by the long term advantages of choosing Drupal 8. We’d recommend that a project scheduled to launch in 6 to 12 months time should select Drupal 8 over Drupal 7.
The fundamental overhaul of the multilingual system in Drupal 8 means that multilingual sites should always choose Drupal 8.
A project with a close, hard release date may not want to take on the risk of an unexpected bug in Drupal 8 impacting development or causing post-launch issues. These issues are always more likely in a new product before it’s had widespread production use.
Deeson maintains a list of 52 modules which are used in a large number of our projects. 11 are now included in Drupal 8 Core so will be fully supported, 9 have community contributed releases in an alpha or beta stage of development and the rest, 32 modules, have no testable release as yet.
For simple brochure sites with limited functionality, Drupal 8 is ready now as some of the most important content management tools are now included in the core platform.
Our experience of Drupal 7 was that contributed modules started being usable one year after the initial Drupal 7 release. We expect the turnaround to be quicker this time because Drupal 8 core incorporates many of these modules and that key contributed modules will be stable by May 2016.
Some major changes to Drupal 8 are the introduction of the Twig templating system for the theme layer, the introduction of components of the Symfony framework into core, the plugin system and a general principle to move to an object-orientated style of programming from the previous, procedural style. Drupal 7 developers, therefore, have quite a bit of learning to do.
It is expected that over the next year interest in Drupal 8 will grow and more developers will begin learning the skills needed to work on a Drupal 8 project. The Drupal community has done an excellent job of providing support material on the Drupal.org website with better documentation than previous versions of Drupal had.
Development teams will need to start ramping up their training now to support the projects they will be taking on in the next 6 months or risk being left unprepared.
As with previous versions, Drupal 8 will have no license fee so is free to reuse.
The cost of projects built using Drupal 8 is unlikely to be significantly different compared with projects built with previous versions of Drupal.
However, we believe that there will be long term reductions in the total cost of ownership because of the improvements made under the hood in Drupal 8. Development best practices have been introduced including a new plugin system making it easier to extend and enhance Drupal 8 compared with previous versions.
There has been significant improvements in what is known as DX, or developer experience. These should improve the abilities of the development team to develop sites and diagnose issues.
Examples include moving to Object-Oriented OO coding principles which organises code more logically and in a manner the developer tools understand. This means that code can autocomplete in their editing tools. Another example is the Twig templating layer which better organises the theme system in Drupal, meaning that it is harder for developers to create untidy code.
Of course, many development teams have been applying these practices on top of Drupal 7 already so are already getting the benefits of these tools and practices which are now in Drupal 8 core.
The Migrate module is included in Drupal 8. Migrate provides a series of tools a developer can use to map content in a Drupal 6 or 7 website to its location within a Drupal 8 website. Although not a simple process, it does mean the migration path from previous versions of Drupal is available.
The Drupal community is committed to supporting the previous version of Drupal. This means Drupal 7 will be supported until Drupal 9 is released. There is currently no official release date for Drupal 9 and so no end of life date for Drupal 7.
I expect support for Drupal 7 for many years, particularly considering the huge install base of Drupal 7 sites.
Drupal Commerce is not maintained by the Drupal core team but maintained by a company - Commerce Guys. They have a Drupal 8 version of the module in active development.
The new Drupal 8 version is described as offering significant improvements over the old versions of Drupal Commerce, including better add to cart facilities, faster product creation and more intuitive product administration.
Previous versions of Drupal had only partial support for multilingual websites. Multilingual projects usually involved stitching together a number of contributed modules to provide support for various elements of Drupal to be translated and each worked in a slightly different way. This inconsistency caused many projects budget and deadline pressures.
There has been a significant overhaul of multilingual capabilities in Drupal 8. Translations of all core elements are done in a sane and consistent manner in Drupal 8 core.
The installation system natively supports 94 languages. There are simple processes for installing new languages and language updates. The administration interface is entirely translatable. Assets, such as files or images, can now be assigned to a language or shared between languages.
Drupal 8 ships with the popular CKEditor WYSIWYG web editor. This means this tool is supported as standard and so will be maintained to continue to integrate well with it.
The new NavBar module in Drupal 8 core offers a clean administration tool for accessing all sections of the administration interface.
Drupal 8’s quick edit feature allows content editors the ability to do simple editing and changes in the page instead of loading a form specially for editing content.
On the horizon there are improvements to media handling in Drupal 8 as well which will give Drupal 8 a superior interface for managing assets such as files and images but this did not make it into core.
Under the hood the content access permission system has been rewritten in Drupal 8 but the behaviour for content administrators is much the same as before.
It is expected that contributed modules will be providing the fine grained additional permission control they did in previous versions of Drupal. The popular choice in previous versions of Drupal for this was Organic Groups, which hadn’t been refactored to match more recent core versions. To provide stable functionality in Drupal 7 we have been using the Group module instead, we are planning to create a Drupal 8 release too.
In Drupal 7 PHP based templates made it too easy for developers to place logic in their templates which should have been managed in modules. Over time, templating code which was not strongly controlled would become fragile and it would be hard to find bugs and add new functionality.
Theming has changed significantly with the introduction of the Twig templating system in Drupal 8. Developers will now be able to write almost all markup in Twig templates rather than PHP code in functions. Though there will be an initial investment in learning required by development teams, the long term results will be cleaner templates which are more maintainable.
There have been some improvements made to accessibility in Drupal 8.
WAI-ARIA landmarks, live regions, roles & properties are included which improves the accessibility of dynamic areas of the page. Drupal’s Form API now puts errors in-line rather than having the errors displayed in different regions to the form element which had the input error.
A general approach in Drupal 8 is to use standardised libraries to deliver functionality rather than trying to develop well known and well developed functionality from scratch. By working with library developers, best-of-breed technologies can be developed in partnership with a larger community.
One of the effects of this is that accessibility for a particular function can be developed by teams of people who really understand that field. A good example here is using the jQuery UI library to provide autocomplete functionality in Drupal 8. The Drupal community can now help the jQuery UI community in producing a better, more accessible tool.
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 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 better tests which run much quickly than previous versions.
PHPUnit is a well recognised tool in the wider PHP developer community, hopefully meaning that 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).
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. There will always be complexities with such approaches but Drupal is flexible enough to alter it to your specific requirements.
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 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 this 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.
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.
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.
Drupal 8 also provides mechanisms for exporting its data via a RESTful API allowing it to easily integrate with other systems.
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.
The process of standardising on the Drupal Entity model began in Drupal 7 and has been extended in Drupal 8. 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.
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, and 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 a problem.
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.
Developers familiar with Symfony and not Drupal will now be able to move into Drupal development. 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.
The caching system was completely re-written in Drupal 8. 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 with greater precision. 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 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 site, 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’ principal used by the Drupal 8 developers which makes sure that nothing needs to be enabled to provide performance boosts for 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.
The Twig templating system is a major change from the old way of allowing PHP code within the template code. 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 by site builders manually configuring text filters for a variety of third party WYSIWYG editors. Such an editor is a must for a content management system but 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.