We make your website more than just pretty!!!

ArrowTheme is an experienced passionate team of developers, designers, QCs, writers, and artists.
We deliver premium Drupal themes, build user-friendly websites that get traffic, convert, and build brand.

Drupal Themes Membership is ideal for those who are seeking bundles of incentives without having to pay that much as of individuals. Besides, members are able to access to unlimited source of Drupal modules and themes including latest releases and updates. Pay just once but get a bunch of benefits.


Friday, September 9, 2016

24 Straightforward Answers To Drupal 8’s Most Commonly Asked Questions

If you’re a CTO who’s thinking of migrating to Drupal 8, you might be dealing with a number  of questions about what this change means for your business. With so much time lapsed between the releases of Drupal 7 and 8, it’s hard to know what this new era will bring.


This article, we’re focusing on some areas: planning for Drupal 8, the implications for Drupal 7, new functionality in Drupal 8, Drupal 8 in the enterprise, architecture changes, and the crucial issues of performance and security.

Planning for Drupal 8

1. Why did Drupal 8 take so long?

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.

2. When should I start building on 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.

3. How long until common contributed modules are going to be available?

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.

However, there are some significant omissions, e.g. Pathauto and Tokens which are used to automatically generate tags in emails or automatic URL aliases based on the title of content.

Our experience of Drupal 7 was that contributed modules started being usable one year after the initial Drupal 7 release.

4. How much do Drupal 7 developers have to learn?

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.

5. Will Drupal 8 make Drupal builds cheaper?

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.

6. Will Drupal 8 sites be quicker to build?

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.

Implications for Drupal 7

7. Is there an upgrade path from previous Drupal versions?

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.

8. How long will Drupal 7 support last now Drupal 8 is out?

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.

New functionality in Drupal 8

9. Does Drupal Commerce feature in the Drupal 8 release?

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.

10. Are multilingual sites handled differently in Drupal 8?

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.

11. How is the content editor experience different in Drupal 8?

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.

12. Does Drupal 8 handle complex user and content permissions any differently?

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.

The front-end and Drupal 8

13. Does Drupal 8 change theming and front-end standards approach?

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.

14. How is accessibility handled in Drupal 8?

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.

There is a JavaScript alert for audible announcements allowing site builders to include timely messages specifically for aural users. A new Tabbing Manager ensures a logical ordering to accessing page elements for users not using a mouse.

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.

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.

I hope you’ve found this post useful and that it’s answered some of your most pressing Drupal questions. Don’t forget to share it with your network on social media.