Planet Drupal

Subscribe to Planet Drupal feed - aggregated feeds in category Planet Drupal
Updated: 11 hours 6 min ago

PreviousNext: Decorated services in Drupal 8

18 February 2016 - 1:12am

One of the aspects of the new object oriented architecture in Drupal 8 is the introduction of services. Services can be provided by any module and provide a mechanism for exposing reusable functionality by way of interfaces and classes. All services are instantiated via the container which is responsible for injecting a service’s dependencies.

Since services implement interfaces and are always instantiated via the container, we have the opportunity to alter what the container returns, ultimately allowing us to swap any existing service with a new one.

Categories: Drupal

DrupalEasy: Contact + Contact Storage (contrib) Module as a Drupal 8 Webform/Entityform Replacement

17 February 2016 - 2:06pm

Looking to migrate your Drupal 6 or 7 site to Drupal 8 but can't do it yet because your site it too reliant on the Webform (or Entityform) module? There's actually very elegant solution that is ready to go today. The core Drupal 8 "Contact" module is now a fully-fledged fieldable entity - meaning you can create various "contact form" types with different sets of fields. Like Entityform, you can use any field types provided by Drupal core as well as contributed modules. When a contact form is submitted, the data is emailed to the assigned addresses.

The Contact Storage module provides the functionality missing from the core Contact form - the ability to save user submissions in the database. Furthermore, Contact Storage stores all submissions in a way that makes them automatically compatible with Views!

The Drupal 8 version of uses exactly this technique for all of our forms, including our main contact form, our Drupal Career Online application form, as well as our various training student surveys. 

Categories: Drupal

OSTraining: Using Entity Reference Fields in Drupal Views

17 February 2016 - 1:29pm

An OSTraining member came to us with a question. The member had two content types that were linked by an Entity Reference field. They wanted to use Views to automatically show import from one content type to another.

In this tutorial, I'm going to show you how to use Entity Reference fields inside Views.

Categories: Drupal

Jason Pamental's Blog: Beep Edition comes to Drupal8

17 February 2016 - 7:42am

I’ve never had particularly lofty ambitions for Beep Edition, the responsive base theme I started a few years ago. Rather than make a new ‘all singing, all dancing’ kind of theme, I wanted this to be my starting point, and include all of my collected experience in responsive design, accessibility, typography and general good practice.

Categories: Drupal

Promet Source: On the Road to DrupalCon Asia

17 February 2016 - 7:41am

Read some more updates from Promet's journeys across the Drupal-verse:

Categories: Drupal

Acquia Developer Center Blog: Drupal 8 Module of the Week: Metatag

17 February 2016 - 7:19am
Jeffrey A. "jam" McGuire

Each day, more Drupal 7 modules are being migrated over to Drupal 8; new modules are also being created for the Drupal community’s latest major release. In this series, the Acquia Developer Center is profiling some of the most prominent, useful modules available for Drupal 8. This week: Metatag.

Tags: acquia drupal planetmetatagmodules
Categories: Drupal

Cheppers blog: Big migration guide to Drupal 8 - Part I

17 February 2016 - 7:16am

Migrations are becoming a crucial part of Drupal 8, especially in connection with the upcoming Drupal 6 EOL. In this first article, we are going to show you how to quickly migrate your site to Drupal 8.

Categories: Drupal You need to update libc on all your Linux servers NOW!

17 February 2016 - 4:35am

If you don't follow security news, you might not be aware of the libc vulnerability published yesterday. The vulnerability was introduced in 2008 - so, it's likely this affects all Linux servers (and desktops, if you run Linux on the desktop) that you're responsible for.

It's a remote code execution vulnerability, meaning attackers can run arbitrary code on your server. It's in the function used to lookup domain names, so it can be exploited by any code that requests a URL, by giving it a special domain name!

While this isn't a Drupal vulnerability, it could definitely be exploited from Drupal, if you provide a way for users to ask the server to request a URL.

The first example that comes to mind, is if you're using the Feeds module, and allow authenticated users to create a new feed (either in the admin UI, or by creating a special piece of content). All they need to do is enter a URL with a special domain name, and when Feeds tries to download it, they'd be able to execute code on your server!

But there's probably countless other examples...

So, if you didn't update yesterday, then be sure to update today!

Categories: Drupal

InternetDevels: How we estimate our Drupal web development projects

17 February 2016 - 4:17am

In one of our previous blog posts, we shared our
project management experiences. Now it’s time to take a
closer look at the way we estimate Drupal projects.

Read more
Categories: Drupal

Lullabot: Javascript aggregation in Drupal 7

17 February 2016 - 3:20am

Javascript aggregation in Drupal 7

What is it? Why should we care?

Javascript aggregation in Drupal is just what it sounds like: it aggregates Javascript files that are added during a page request into a single file. Modules and themes add Javascript using Drupal’s API, and the Javascript aggregation system takes care of aggregating all of that Javascript into one or more files. Drupal does this in order to cut down on the number of HTTP requests needed to load a page. Fewer HTTP requests is generally better for front-end performance.

In this article we’ll take a look at the API for adding Javascript, paying specific attention to the options affecting aggregation in order to make best use of the system. We’ll also take a look at some common pitfalls to look out for and how you can avoid them using Advanced Aggregation (AdvAgg) module. This article will mostly be looking at Drupal 7, however much of what we’ll cover applies equally to Drupal 8, and we’ll take a look specifically at what’s changed in Drupal 8.

If fewer is better, why multiple aggregates?

Before we dig in, I said that fewer HTTP requests is generally better for front-end performance. You may have noticed that Drupal creates more that one Javascript aggregate for each page request. Why not a single aggregate? The reason Drupal does this is to take advantage of browser caching. If you had a single aggregate with all the Javascript on the page, any difference in the aggregate from page to page would cause the browser to download a different aggregate with a lot of the same code. This situation arises when Javascript is conditionally added to the page, as is the case with many modules and themes. Ideally, we would group Javascript that appears on every page apart from conditionally added Javascript. That way the browser would download the every page Javascript aggregate once and subsequently load it from cache on other page requests on your website. Drupal’s Javascript aggregation attempts to give you the ability to do exactly that, striking a balance between making fewer HTTP requests, and leveraging browser caching.

The Basics

Let’s take a step back and briefly go over how to use Javascript aggregation in Drupal 7. You can turn on Javascript aggregation by going to Site Configuration > Development > Performance in your Drupal admin. Check off "Aggregate Javascript files" and Save. That’s it. Drupal will start aggregating module and theme Javascript from there on out.

Using the API

Once you’ve enabled Javascript aggregation, great! You’re on your way to sweet, sweet performance gains. But you’ve got modules and themes to build, and Javascript to go along with them. How do you make use of Javascript aggregation provided by Drupal? What kind of control do you have over the process?

There are a couple API entry points for adding Javascript to the page. Most API entry points have parameters that let you tell Drupal how to aggregate your Javascript. Let’s look at each in turn.


This is a loaded function that is used to add a Javascript file, externally hosted Javascript, a setting, or inline Javascript to the page. When it comes to Javascript aggregation, only Javascript files are aggregated by Drupal, so we’re going to focus on adding files. The other types (inline and external) do have important impacts on Javascript aggregation though, which we’ll get into later.


Drupal also provides a mechanism to register Javascript/CSS "libraries" associated with a module. This is nice because you can specify the options to pass to drupal_add_js in one place. That gives you the flexibility to call drupal_add_library in multiple places, without having to repeat the same options. The other nice thing is that you can specify dependencies for your library and Drupal will take care of resolving those dependencies and putting them in the right order for you.

I like to register every script in my module as a library, and only add scripts using drupal_add_library (or the corresponding #attached method, see below). This way I’m clearly expressing any dependencies and in the case where my script is added in more than one place, the options I give the aggregation system are all in one place in case I need to make a change. It’s also a nice way to safely deprecate scripts. If all the dependencies are spelled out, you can be assured that removing a script won’t break things.

Instructions for using hook_library and drupal_add_library are well documented. However, one important thing to note is the third parameter to drupal_add_library, every_page, which is used to help optimize aggregation. At registration time in hook_library, you typically don’t know if a library will be used on every page request or not. Especially if you’re registering libraries for other module authors to use. This is why drupal_add_library has an every_page parameter. If you’re adding a library unconditionally on every page, be sure to set every_page parameter to TRUE so that Drupal will group your script into a stable aggregate with other scripts that are added to every page. We’ll discuss every_page in more detail below.


attached is a render array property that lets you add Javascript, CSS, libraries and arbitrary data to the page. #attached is the preferred approach for adding Javascript in Drupal. In fact, drupal_add_js and drupal_add_library are gone in Drupal 8 in favor of #attached. #attached is nice since it is part of a render array and can be easily altered by other modules and themes. It’s also essential for places where render arrays are cached. With caching in play, functions that build out a render array are bypassed in favor of a cached copy. In that scenario, you need to have your Javascript addition included in #attached on the render array, because a call to drupal_add_js/drupal_add_library in your builder function would otherwise be missed.

Drupal developers often fall back on drupal_add_js for lack of a render array in context. It’s common to add Javascript in places like hook_init, preprocess and process functions, where there is no render array available to add your Javascript via #attached. In these scenarios, consider whether your Javascript is more appropriately added via a hook_page_build, or hook_node_view, where there is a render array available to add your script via #attached. Not only will you begin to align yourself with the Drupal 8 way of doing things, but you open yourself up to being able to use the render_cache module, which can gain you some performance. See the documentation for drupal_process_attached for more information.

Controlling aggregation

Let’s take a close look at the parameters affecting Javascript aggregation. Drupal will create an aggregate for each unique combination of the scope, group, and every_page parameters, so it’s important to understand what each of these mean.


The possible values for scope are ‘header’ and ‘footer’. A scope of ‘header’ will output the script in the

tag, a scope of ‘footer’ will output the script just before the closing tag.


The ‘group’ option takes any integer as a value, although you should stick to the constants JS_LIBRARY, JS_DEFAULT and JS_THEME to avoid excessive numbers of aggregates and follow convention.


The ‘every_page’ option expects a boolean. This is a way to tell the aggregation system that your script is guaranteed to be included on every page. This flag is commonly overlooked, but is very important. Any scripts that are added on every page should be included in a stable aggregate group, one that is the same from page to page, such that the browser can make good use of caching. The every_page parameter is used for exactly that purpose. Miss out on using every_page and your script is apt to be lumped into a volatile aggregate that changes from page to page, forcing the browser to download your code anew on each page request.

What can go wrong

There are a few problems to watch out for when it comes to Javascript aggregation. Let’s look at some in turn.

Potential number of aggregates

The astute reader will have noticed that there is a potential for a lot of aggregates to be created. When you combine scope, group and every_page options, the number of aggregates per page can get out of control if you’re not careful. With two values for scope, three for groups and two for every_page, there is potential to climb to twelve aggregates in a page. Twelve seems a little out of control. Sure, we want to leverage browser caching, but this many HTTP requests is concerning. If you’re getting high into the number of aggregates it’s likely that modules and themes adding Javascript are not using the API as best as they could.

Misuse of Groups

As was mentioned, JS_LIBRARY, JS_DEFAULT and JS_THEME are default constants that ship with Drupal to group Javascript. When adding Javascript, modules and themes should stick to these groups. As soon as you deviate, you introduce a new aggregate. Often when people deviate from the default groups, it’s to ensure ordering. Maybe you need your script to be the very first script on the page, so you set your group to JS_LIBRARY - 100. Instead, use the ‘weight’ option to manage ordering. Set your group to JS_LIBRARY and set the weight very low to ensure your first in the JS_LIBRARY aggregate. Another issue I see is themes adding script explicitly under the JS_THEME group. This is logical, after all, it is Javascript added by the theme! However, it’s better to make use of hook_library, declare your dependencies and let the group default to JS_DEFAULT. The order you need is preserved by declaring your dependencies, and you avoid creating a new aggregate unessesarily.

Inline and External Scripts

Extra care should be employed when adding external and inline scripts. drupal_add_js and friends preserve order really well, such that they track the order the function is called for all the script added to the page and respect that. That’s all well and good. However, if an inline or external script is added between file scripts, it can split the aggregate. For example if you add 3 scripts: 2 file scripts and 1 external, all with the same scope, group, and every_page values, you might think that Drupal would aggregate the 2 file scripts and output 2 script tags total. However, if drupal_add_js gets called for the file, then external, then file, you end up getting two aggregates generated with the external script in between for a total of 3 script tags. This is probably not what you want. In this case it’s best to specify a high or low weight value for the external script so it sits at the top or bottom of the aggregate and doesn’t end up splitting it. The same goes for inline JS.

Scripts added in a different order

I alluded to this in the last one, but certain situations can arise where scripts get added to an aggregate in a different order from one request to the next. This can be for any number of reasons, but because Drupal is tracking the call order to drupal_add_js, you end up with a different order for the same scripts in a group and thus a different aggregate. Sadly the same code will sit in two aggregates on the server, with slightly different source order, but otherwise they could have been exactly equal, produced a single aggregate and thus cached by the browser from page to page. The solution in this case is to use weight values to ensure the same order within an aggregate from page to page. It’s not ideal, because you don’t want to have to set weights on every hook_library / drupal_add_js. I’d recommend handling it on a case by case basis.

Best Practices

Clearly, there is a lot that can go wrong, or at least end up taking you to a place that is sub-optimal. Considering all that we’ve covered, I’ve come up with a list of best practices to follow:

Always use the API, never ‘shoehorn’ scripts into the page

A common problem is running into modules and themes that sidestep the API to add their Javascript to the page. Common methods include using drupal_add_html_head to add script to the header, using hook_page_alter and appending script markup to $variables[‘page_bottom’], or otherwise outputting a raw

Use hook_library

hook_library is a great tool. Use it for any and all Javascript you output (inline, external, file). It centralizes all of the options for each script so you don’t have to repeat them, and best of all, you can declare dependencies for your Javascript.

Use every_page when appropriate

The every_page option signals to the aggregation system that your script will be added to all pages on the site. If your script qualifies, make sure your setting every_page = TRUE. This puts your script into a "stable" aggregate that is cached and reused often.


Advanced CSS/JS Aggregation (AdvAgg) is a contributed module that replaces Drupal’s built in aggregation system with it’s own, making many improvements and adding additional features along the way. The way that you add scripts is the same, but behind the scenes, how the groups are generated and aggregated into their respective aggregates is different. AdvAgg also attempts to overcome many of the scenarios where core aggregation can go wrong that I listed above. I won’t cover all of what AdvAgg has to offer, it has an impressive scope that would warrant it’s own article or more. Instead I’ll touch on how it can solve some of the problems we listed above, as well as some other neat features.

Out of the box the core AdvAgg module supplies a handful of transparent backend improvements. One of those is stampede protection. After a code release with JS/CSS changes, there is a potential that multiple requests for the same page will all trigger the calculation and writing of the same new aggregates, duplicating work. On high traffic sites, this can lead to deadlocks which can be detrimental to performance. AdvAgg implements locking so that only the first process will perform the work of calculating and writing aggregates. Advagg also employs smarter caching strategies so the work of calculating and writing aggregates is done as infrequently as possible, and only when there is a change to the source files. These are nice improvements, but there is great power to behold in AdvAgg’s submodules.

AdvAgg Compress Javascript

AdvAgg comes with two submodules to enhance JS and CSS compression. They each provide a pluggable way to have a compressor library act on the each aggregate before it’s saved to disk. There are a few options for JS compression, JSqueeze is a great option that will work out of the box. However, if you have the flexibility on your server to install the JSMIN C extension, it’s slightly more performant.

AdvAgg Modifier

AdvAgg Modifier is another sub module that ships with AdvAgg, and here is where we get into solving some of the problems we listed earlier. Let’s explore some of the more interesting options that are made available by AdvAgg Modifier:

Optimize Javascript Ordering

There are a couple of options under this fieldset that seek to solve some of the problems laid out above. First up, "Move Javascript added by drupal_add_html_head() into drupal_add_js()" does just what it says, correcting the errant use of the API by module/theme authors. Doing this allows the Javascript in question to participate in Javascript aggregation and potentially removes an HTTP request if it was a file that was being added. Next “Move all external scripts to the top of the execution order” and “Move all inline scripts to the bottom of the execution order” are both an attempt at resolving the issue of splitting the aggregate. This is more or less assuming that external files are more library-esque and inline Javascript is meant to be run after all other Javascript has run. That may or may not be the case depending on what you’re doing and you should definitely use caution. Such as that is, if it works for you, it could be a simple way to avoid splitting the aggregate without having to do manual work of adjusting weights.

Move JS to the footer

As we discussed, you typically add Javascript to one of two scopes, header or footer. A common performance optimization is to move all the Javascript to the footer. AdvAgg gives you a couple choices in how you do that ranging from some to all Javascript moved to the footer. This can easily break your site however, and you definitely need to test and use caution here. The reason of course is that there could be other script that aren’t declaring their dependencies properly, and/or are ‘shoehorning’ their Javascript into the page that are depending on a dependency existing in the header. These will need to be fixed on a case by case basis (submit patches to contrib modules!). If you still have Javascript that really does need to be in the header, AdvAgg extends the options for drupal_add_js and friends to include a boolean scope_lock that when set to TRUE, will prevent AdvAgg from moving the script to the footer. There always seems to be some stubborn ads or analytics provider that insists on presence in the header, and is backed by the business that forces you to make at least one of these exceptions. Another related option is "Put a wrapper around inline JS if it was added in the content section incorrectly". This is an attempt to resolve the problem of inline Javascript in the body depending on things being in the header. AdvAgg will wrap any inline Javascript in a timer that waits on jQuery and Drupal to be defined before running the inline code. It uses a regular expression to search for the scripts, which while neat, feels a little brittle. There is an alternate option to search for the scripts using xpath instead of regex, which could be more reliable. If you try it, do so with care, test first.

Drupal 8

Not a lot is different when it comes to Javascript aggregation in D8, but there have been a few notable changes. First, the aggregation system has been refactored under the hood to be pluggable. You can now cleanly swap out and/or add to the aggregation system, whereas in Drupal 7 it was a difficult and messy affair to do so. Modules like AdvAgg should have a relatively easier time implementing their added functionality. Other improvements to the aggregation system that didn’t quite make the D8 release will now have a clearer path to implementation for the same reason. In terms of its function and the way in which Javascript is grouped for aggregation, everything is as it was in Drupal 7.

The second change centres around adding Javascript to the page. drupal_add_js and drupal_add_library have been removed in Drupal 8 in favor of #attached. The primary motivation is to improve cacheability. With Javascript consistently added using #attached, it’s possible to do better render array caching. The classic example being that if you were using drupal_add_js in your form builder function, your Javascript would be missed if the cached render array was used and the builder function skipped. Caching aside, it’s nice that there is a single consistent way to add Javascript. Also related to this change, is hook_library definitions have gone the way of the dodo. In their place, *.libraries.yml files are now used to define your Javascript and CSS assets in libraries, continuing the Drupal 8 theme of replacing info hooks with YML files.

A third somewhat related change that I’ll point out is that Drupal core no longer automatically adds jQuery, Drupal.js and Drupal.settings (drupalSettings in Drupal 8). jQuery still ships with core, but if you need it, you have to declare it as a dependency in your *.libraries.yml file. There have also been steps taken to reduce Drupal core’s reliance on jQuery. This isn’t directly related to Javascript aggregation per se, but it’s a big change nonetheless that you’ll have to keep in mind if you’re used to writing Javascript in Drupal 7 and below. It’s a welcome improvement with potential for some nice front end performance gains. For more information and specific implementation details, check out the guide for adding Javascript and CSS from a theme and adding Javascript and CSS from a module.

HTTP 2.0

Any article about aggregating Javascript assets these days deserves a disclaimer regarding HTTP 2.0. For the uninitiated, HTTP 2.0 is the new version of the HTTP protocol that while maintaining all the semantics of HTTP 1.1, significantly changes the implementation details. The most noted change in a nutshell is that instead of opening a bunch of TCP connections to download all the resources you need from a single origin, HTTP 2.0 opens a single connection per origin and multiplexes resources on that connection to achieve parallelism. There is a lot of promise here because HTTP 2.0 enables you to minimize the number of TCP connections your browser has to open, while still downloading assets in parallel and individually caching assets. That means that you could be better off not aggregating your assets at all, allowing the browser to maximize caching efficiency without incurring the cost of multiple open TCP connections. In practice, the jury is still out on whether no aggregation at all is a good idea. It turns out that compression doesn’t do as well on a collection of individual small files as it does on aggregated large files. It’s likely that some level of aggregation will continue to be used in practice. However as hosts more widely support HTTP 2.0 and old browsers fall off, this will become a larger area of interest.


Whew, we’ve come to the end at last. My purpose was to go over all of the nuances of Javascript aggregation in Drupal. It’s an important topic when it comes to front end performance, and one that deserves careful consideration when you're trying to eek every last bit of performance out of your site. With Drupal 8 and HTTP 2.0 now a reality, it’ll be interesting to watch as things evolve for the better.

Categories: Drupal

Modules Unraveled: 156 Using BigPipe to Achieve Incredible Site Speed in Drupal 8 with Wim Leers - Modules Unraveled Podcast

17 February 2016 - 1:00am
Published: Wed, 02/17/16Download this episodeBig Pipe
  • What is Big Pipe?
  • This isn’t a Drupal specific thing right? Where did the idea of BigPipe come from?
  • How does it work?
    • Builds on Drupal 8’s caching system, specifically cacheability metadata (tags, contexts, max-age)
    • Rendering system (bubbling, placeholders)
    • page cache / dynamic page cache
    • BigPipe is built ON TOP OF ALL OF THE ABOVE
  • Does it work for anonymous and authenticated users?
  • Is this compatible with reverse proxies like Varnish?
  • Does BigPipe affect the need for something like redis or memchache?
  • How does BigPipe relate to authcache?
Use Cases
  • How can we start using it? What’s the install process?
  • What do we need to do to configure it for our site?
  • Is BigPipe ready to be used?
  • Is there anything like this for Drupal 7?
Questions from Twitter
  • Daniel Noyola @danielnv18
    What can I do to make my site compatible with BigPipe? O what shouldn't do?
  • Daniel Noyola @danielnv18
    Is it compatible with contrib modules like panels or display suite?
  • Ryan Gibson @ryanissamson
    I may have missed it, when BigPipe is included in D8.1, will it be enabled by default?
  • TheodorosPloumis @theoploumis
    Is the bigpipe caching working with the RESTful responses?
Episode Links: Wim on drupal.orgWim on TwitterBigPipe ModuleBigPipe DemoFacebook Engineering blog post about BigPipeRendervizWimleers.comTags: Drupal 8Big PipePerformanceplanet-drupal
Categories: Drupal

Vardot: 5 Security Modules That Every Drupal Website Must Have

16 February 2016 - 11:57pm

With intruders, thieves, hackers and spammers ready to perpetuate threat to most businesses online, virtual security is definitely the top concern in today's web that a firm should focus. While there are several hundred CMSs out there to provide a digital platform, Drupal is considered one of the top secure platforms that can seamlessly address the firm's security needs.

Do you know what makes Drupal a ‘credible content management system’? Backed with some phenomenal modules and themes, this great CMS is heartily manned by a dedicated community of developers. Unlike other content management systems, Drupal offers the most consistent security updates, keeping the chances of risks as minimal as possible. However, if you are already using Drupal, then it is necessary to keep your website extra secure with the gifted grace of ‘security modules’ available for Drupal. Here we have listed the 5 best security modules that every Drupal website must include - have a look!


1. Password Policy

Usage: For now, Password Policy is used by more than 20k websites. The module has also been downloaded more than 260k times.

According to Verizon’s Data Breach Investigation Report statistics for the year 2013, 4 out of every 5 data breaches occur due to exploited or stolen credentials.

Thus, defining the password policies of your website and enforcing restrictions on user passwords is important. Make it possible with the help of ‘Password Policy’ module that brings a defined set of constraints implemented right before a website accepts the password changes of a user. With each constraint, the module has some pre-defined parameters that have to be ‘satisfied’ to validate the conditions. Password Policy has recently updated a brand new version for Drupal 8, introducing the constraints as plugins. Apart from this, the module comes with a password expiration feature where a user is either forced to change the password or it is optionally blocked once the old password expires.

Functionality: The module sets a credible policy for passwords, manning control through constraints while the password is generated. With Password Policy module, you can also control the structure of password in terms of length, capitalization, unique character, numbers, reuse of password, and so on.


2. Security Kit

Usage: Currently, about 11k sites are using Security Kit as a reliable easy-to-use module. The module has reported more than 143k downloads.

Do you know at Annual Website Security Statistics report 2012, Whitehat has identified cross-site scripting and cross-site request forgery as two most prevalent vulnerabilities?

The module promises security under four major categories- cross-site scripting, cross-site request forgery, clickjacking, and SSL/TLS. Cross site scripting safeguards content policies, handling browser reporting and violation management. Through cross-site request forgery, you can control the Origin HTTP request header. Similarly, Clickjacking works on the implementation of X-Frame-Options HTTP response header and Javascript (coupled with CSS and Noscript protection and customized text to disable the JavaScript message). Last but not the least- SSL/TLS handles the implementation of HTTP Strict Transport Security (HSTS) response header. With this, you can simply prevent the role of middleman and possibly control the potential attacks by eavesdropping.

Functionality: Security Kit brings the best security-hardening options that you can use on your website! Security Kit module enables safekeeping by lowering the risks of exploitation of different web application vulnerabilities.


3. Security Review

Usage: About 34k websites are using this module, which has been downloaded over 270k times.

Your site might have some silly easy-to-make mistakes that could be a bit embarrassing at times. Don’t worry and avoid the humiliation of making silly mistakes in your Drupal website with the help of Security Review module. How does it work? Well, Security Review module automates the testing process of a website in the simplest manner. It is a quick and easy to implement module. With Security Review Module, you can check the safe file system permission of your website that limits the execution of any arbitrary code. The module protects a site against dangerous XSS tags available in the text formats. It enables safety in reporting errors, avoids unnecessary information disclosure, promises security of private cum personal files, enables easy and safe uploading of extensions, and checks the large database for errorless usage. Moreover, you can have one Drupal admin as permission to protect your website against any form of malice or misconfiguration.

Functionality: Security Review will not add automated changes to your website, unless and until the checklist and its resources are not manually secured. The module is readily available for the latest Drupal 8 interface.


4. Username Enumeration Prevention

Usage: The module has been used by more than 7k sites and has been downloaded by almost 29k Drupal users.

Though Drupal is quite a secure interface yet the chance of exploitation is evident in the CMS, especially for Drupal 6. As Drupal 6 doesn’t come with brute force prevention functionality, it makes the website vulnerable for easy hacking through just a username. It means a hacker can quite easily attack a site through a username, followed by brute force hack. The best security practice is to keep the usernames protected. And this is exactly what Username Enumeration Prevention does - with this module, you can make your usernames hard to find for the hacker. The technique ‘username enumeration’ can enable an attacker to find usernames by using the ‘forgot password’ form. By simply adding the username that doesn’t exist in real, the attacker will get Drupal’s response. An attacker can thereby follow a simple process i.e. to keep trying different usernames on the ‘forgot password’ form until he find a valid username. With the enabling of this module, the attacker will be redirected back to the login form, while the error message will also replace the preview message. It works through replacing the message that appears to the user when requesting a new password to something more ambiguous instead of indicating that the user exists or not, which allows the attacker to figure the username through the status message that appears.

Functionality: Username Enumeration Prevention is an important way to secure the usernames of your website. The module simply disables the status message that could let the attacker know that a username exists through the "Request new password" function.


5. Generate Password

Usage: Almost 6k websites are currently using the Generate Password module. The module has almost 32k downloads.

Generate Password module works with a simple trick. It makes the password field optional or rather hidden on the new user registration page, so that when the password is not set during the registration process, the system generated a generic password. As an admin, you can optionally choose to display this password by the time it is created in the registration process. How does it work? For the configuration settings, just visit the account settings of the user page and change the behavior of the password generation.

Functionality: Customize the structure of password generation as in the length of the password, generated password entropy, nature of characters (capitalization, special character, and numbers), password algorithm, and password display as per your requirements.


Use these 5 Drupal security modules for your website to keep all those unwanted hackers and attackers away. So while you might wish to keep your website secure with all these modules, we would also recommend you to ensure the perfect dose of necessities with Varbase, an enhanced Drupal distribution built, packaged and maintened by Vardot, that users some of the most important and widely used Drupal modules, features, and configurations. What is the best part about Varbase? Well, the little ‘bundle of Drupal joys’ has these 5 modules bundled and configured in the "Security" feature. Varbase is highly recommended for certain reasons - it speeds up the Drupal developmental process, provides the most sorted/standardized configurations, offers one stop solutions for diverse Drupal development needs and ensures ease in implementation. The Drupal distribution is also quite frequently updated by the developers. Varbase is successfully used by almost 70 sites and has registered more than 10k downloads.

As said, the security of your business is highly important, so don’t forget to monitor your website regularly. We hope this article will resolve some of your security concerns related to the Drupal development. Do you have any others? Share them with us in comments.

Tags:  Drupal Planet Drupal Modules Security Title:  5 Security Modules That Every Drupal Website Must Have
Categories: Drupal

Dries Buytaert: When traffic skyrockets your site shouldn't go down

16 February 2016 - 8:06pm

This week's Grammy Awards is one of the best examples of the high traffic events websites that Acquia is so well known for. This marks the fourth time we hosted the Grammys' website. We saw close to 5 million unique visitors requesting nearly 20 million pages on the day of the awards and the day after. From television's Emmys to Superbowl advertisers' sites, Acquia has earned its reputation for keeping their Drupal sites humming during the most crushing peaks of traffic.

These "super spikes" aren't always fun. For the developers building these sites to the producers updating each site during the event, nothing compares to the sinking feeling when a site fails when it is needed the most. During the recent Superbowl, one half-time performer lost her website (not on Drupal), giving fans the dreaded 503 Service Unavailable error message. According to CMSWire: "Her website was down well past midnight for those who wanted to try and score tickets for her tour, announced just after her halftime show performance". Yet for Bruno Mars' fans, his Acquia-based Drupal site kept rolling even as millions flooded his site during the half-time performance.

For the Grammys, we can plan ahead and expand their infrastructure prior to the event. This is easy thanks to Acquia Cloud's elastic platform capacity. Our technical account managers and support teams work with the producers at the Grammys to make sure the right infrastructure and configuration is in place. Specifically, we simulate award night traffic as best we can, and use load testing to prepare the infrastructure accordingly. If needed, we add additional server capacity during the event itself. Just prior to the event, Acquia takes a 360 degree look at the site to ensure that all of the stakeholders are aligned, whether internal to Acquia or external at a partner. We have technical staff on site during the event, and remote teams that provide around the clock coverage before and after the event.

Few people know what goes on behind the scenes during these super spikes, but the biggest source of pride is that our work is often invisible; our job well done means that our customer's best day, didn't turn into their worst day.

Categories: Drupal

OSTraining: How to Change the Main Language of a Drupal site

16 February 2016 - 7:36pm

One OSTraining had set up a site in English and wanted to move everything over to their native language.

In this tutorial, I'll show you how to completely change the main language of a Drupal 7 site.

I'm going to use the example of an English-language site that needs to be changed to Spanish.

First, go to "Modules" and enable the Locale module:

Categories: Drupal

DrupalCon News: Limited number of DrupalCon tickets to be sold on site

16 February 2016 - 6:10pm

Every DrupalCon has a few walk-up attendees, and we expect DrupalCon Asia to be no different. In spite of some technical limitations, and in the interest of keeping DrupalCon Asia inclusive and true to the “come one, come all” spirit of the Drupal community, we have worked hard to make sure that a limited number of tickets will be available on-site for walk-up attendees.

Categories: Drupal

Promet Source: Cool Modules for Content Editors

16 February 2016 - 3:14pm

Our in-house marketer Rory took a closer look at nifty modules specifically geared towards the unsung heroes of content management: Content Editors.

Need more module mojo? Read some of these other fine entries in our archives:

Categories: Drupal

Wim Leers: A RESTless week

16 February 2016 - 2:29pm

I spent about a week of my time at Acquia on improving Drupal 8’s REST support.

That time was spent fixing, reviewing, triaging and documenting.

Drupal 8’s REST works very well, we just have to make it more friendly & helpful, remove Drupalisms and support more REST capabilities.

Fixing, reviewing & triaging

I went through the entire issue queues of rest.module, serialization.module and hal.module. I was able to mark about a dozen bug reports as duplicates, fix a dozen or so support requests, have reviewed probably a few dozen patches, rerolled about a dozen patches, created at least another dozen patches and … triaged 100% of the open issues. I clarified titles of >30 issues.

Now the rest.module issue queue (the most important one) fits on a single page again!1 I collaborated a lot with neclimdul, klausi, damiankloip, dawehner and others.

dawehner and I decided to tag the issues that were especially relevant using the RX (REST Experience) issue tag.

I felt it was important to get a comprehensive picture of Drupal 8’s REST support state, so I insisted on going through all open issues (and was given the time to do so). This enabled me to document the current state of things (and upcoming improvements).


So, I spent several days doing nothing else but writing and improving documentation, just like I did for the modules and subsystems I co-maintain. The following handbook pages have either received minor updates, received complete overhauls or were written from scratch:

So, there you go, documentation covering fundamentals, like that for the Serialization API:

Serializing & deserializing
Using the serializer service’s (\Symfony\Component\Serializer\SerializerInterface) serialize() and deserialize() methods: $output = $serializer->serialize($entity, 'json'); $entity = $serializer->deserialize($output, \Drupal\node\Entity\Node::class, 'json');
Serialization format encoding/decoding (format → array → format
The encoder (\Symfony\Component\Serializer\Encoder\EncoderInterface) and decoder (\Symfony\Component\Serializer\Encoder\DecoderInterface, to add support for encoding to new serialization formats (i.e. for reading data) and decoding from them (i.e. for writing data).
Normalization (array → object → array)
The normalizer (\Symfony\Component\Serializer\Normalizer\NormalizerInterface) and denormalizer (\Symfony\Component\Serializer\Normalizer\DenormalizerInterface), to add support for normalizing to a new normalization format. The default format is as close to a 1:1 mapping of the object data as possible, but other formats may want to omit e.g. local IDs (for example node IDs are local, UUIDs are global) or add additional metadata (such as URIs linking to related data).
Entity resolvers
In a Drupal context, usually it will be (content) entities that end up being serialized. When given an entity to normalize (object → array) and then encode (array → format), that entity may have references to other entities. Those references may use either UUIDs (\Drupal\serialization\EntityResolver\UuidResolver) or local IDs (\Drupal\serialization\EntityResolver\TargetIdResolver). For advanced use cases, additional mechanisms for referring to other entities may exist; in that case, you would add an additional entity resolver.

… to more practical information, such as the Getting started: REST configuration & REST request fundamentals handbook page for the rest module:

1. Configuration

First read RESTful Web Services API — Practical.

Now you know how to:

  1. expose data as REST resources
  2. grant the necessary permissions
  3. customize a REST resource’s formats (JSON, XML, HAL+JSON, CSV …)
  4. customize a REST resource’s authentication mechanisms (cookie, OAuth, OAuth 2.0 Token Bearer, HTTP Basic Authentication …)

Armed with that knowledge, you can configure a Drupal 8 site to expose data to precisely match your needs.

2. REST request fundamentals 2.1 Safe vs. unsafe methods

REST uses HTTP, and uses the HTTP verbs. The HTTP verbs (also called request methods) are: GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS, CONNECT and PATCH.
Some of these methods are safe: they are read-only. Hence they can never cause harm to the stored data, because they can’t manipulate them. The safe methods are HEAD, GET, OPTIONS and TRACE.
All other methods are unsafe, because they perform writes, and can hence manipulate stored data.

Note: PUT is not supported for good reasons.

2.2 Unsafe methods & CSRF protection: X-CSRF-Token request header

Drupal 8 protects its REST resources from CSRF attacks by requiring a X-CSRF-Token request header to be sent when using a non-safe method. So, when performing non-read-only requests, that token is required.
Such a token can be retrieved at /rest/session/token.

2.3 Format

When performing REST requests, you must inform Drupal about the serialization format you are using (even if only one is supported for a given REST resource). So:

  1. Always specify the ?_format query argument, e.g.
  2. When sending a request body containing data in that format, specify the Content-Type request header. This is the case for POST and PATCH.

Note: Accept-header based content negotiation was removed from Drupal 8 because browsers and proxies had poor support for it.

3. Next

Now you’re ready to look at concrete examples, which start on the next page.

If that particular handbook page had already existed, it would have saved me so much time! The next page then contains examples for how to do GET requests, using various tools:

cURL curl Guzzle $response = \Drupal::httpClient() ->get('', [ 'auth' => ['username', 'password'], ]); $json_string = (string) $response->getBody(); jQuery jQuery.ajax({ url: '', method: 'GET', success: function (comment) { console.log(comment); } });

… and the following pages then provide concrete examples (in those same tools) for POST, PATCH and DELETE requests2.


Why I did all of the above

It took me about three days to successfully PATCH a Comment entity3.

Why days?

I first forgot to specify the Content-Type request header. Then it turned out I also forgot the X-CSRF-Token request header — which was not documented anywhere to be a thing. I eventually found out about that Drupal-specific request header by analyzing the REST PATCH test coverage. Why did I not find it sooner? Because Drupal 8 was giving utterly unhelpful, and actually downright nonsensical (and incorrect!) responses4. It doesn’t end there though. Turns out that if you try to update an entity using JSON (and not HAL+JSON, which works fine), you MUST specify the bundle (otherwise it’s impossible to denormalize the entity you’re sending), but you also MUST NOT specify the entity type’s bundle if it’s a Comment (because you’re not allowed to modify this by CommentAccessControlHandler). So … it literally was impossible to update a comment5!

I didn’t have any experience with/knowledge about Drupal 8’s REST API. But I’m deeply familiar with Drupal 8. And it still took me days. Of course I wanted to prevent anyone from ever having to go through that.

Today, anybody would start at d.o/documentation/modules/rest/start and then look at d.o/documentation/modules/rest/patch and would hence be able to avoid all these pitfalls. Soon, Drupal will provide more helpful responses4 and allow comments to be updated5 using JSON.

  1. Once the “fixed” issues disappear. 50 issues fit on a single page. I didn’t count the number of issues before I started, but it was at least 70, and I think ~90. 

  2. These handbook pages already existed mostly, but lacked clarity, coherence and completeness. That’s what I tried to add. 

  3. We’re working on an experiment in progressive decoupling. For that to work, you of course need solid REST support. Once those experiments become worth sharing, we will. 

  4. I’m fixing that in

  5. I’m fixing that in

  • Acquia
  • DX
  • Drupal
Categories: Drupal

Web Wash: Display Paragraphs Edge-to-edge using Bootstrap in Drupal 8

16 February 2016 - 11:28am

So far I've introduced you to the Paragraphs module where we created a basic paragraph type which allows you to display content as movable components. Then we looked at how to create container paragraphs, and this time we created a Banner which let us display nested paragraph items.

By now you should have a basic understanding of why you should use Paragraphs and how to use the module.

Today I want to teach you how to display paragraphs edge-to-edge using Bootstrap as the theme. We'll use the Banner paragraph, which we created in the last tutorial, to display an image full width but have the nested paragraphs centered.

Categories: Drupal

Palantir: The Secret Sauce podcast, Ep. 05

16 February 2016 - 9:47am

This time we're joined by Engineer Kelsey Betham who tells us all about exporting features in drupal, including why and when you should, and how doing so could be a huge benefit should something go horribly wrong with your site. The full transcript of the episode is below.

We'll be back next week with another episode of the Secret Sauce hosted by Account Manager Allison Manley, but for now subscribe to all of our episodes – including our monthly long-form interview series called On the Air With Palantir – over on iTunes.

iTunes | RSS Feed | Download | Transcript Want to learn more ways to get the most out of Drupal? Let's schedule a time to talk.


AM: Hello and welcome to The Secret Sauce, brought to you by This is a super short podcast, just a few minutes every week, that offers a quick tip on some small thing you can do to help your business run better.

I’m Allison Manley, an Account Manager here at Palantir, and today’s advice comes from Kelsey Betham, one of our fantastic engineers, who is going to talk about exporting your features in drupal.

KB: Hi. I’m Kelsey Bentham and I’m going to tell you about why should should export all of your features. This seems like the sort of thing you don’t need to do after you launch your site. But you’d be wrong, because at some point or another someone else is going to have to set up your site. Whether it’s because they are fixing a bug, or they are learning how it works, they’ll need to know what’s going on. And if you don’t keep your features up to date and exported, the only place that information will exist will be in your database. And there’s a chance that something, somewhere, will go horribly wrong, and you want to have it backed up in as many ways as you can manage.

And you can backup your features by going in through the Drupal Admin interface. You can log in with a user that has the appropriate permissions to update your features. Go to the “Configuration” menu on your Drupal site and go to “Features.” Here you will find a helpful list of all of your features and their current status: whether they be up to date with your database, or in some way different.

If you have the Diff Module installed you can also check to see exactly how the code differs from the database. You’ll want to check on this to see exactly what’s changed and be able to verify that all the changes that have been made are changes that you actually want to keep. Once you verify that all the changes you have are ones that you should have, you can go and click on the “Recreate the Feature” button. This will allow you to export the feature to exactly where it is, but updated with all your current configurations.

Doing this sort of thing will help in the long run because it makes it much much easier to ramp people up on projects, as well as keeping anyone outside of the immediate project team aware of exactly how things are working at any given time.

Thank you very much for listening, and I hope that you keep all of your features updated in the future!

AM: Thanks for listening to this week’s Secret Sauce! For more great tips, follow us on twitter at @palantir, or visit our website at Have a great day!

Categories: Drupal

DrupalCon News: First North American Project Management Track

16 February 2016 - 9:14am

This will be the first year that Project Management will have it’s own track at a DrupalCon in North America. Usually a part of the Business track, Project Managers now have a specific track that is being shaped and molded into two levels of sessions, one for the new project managers that are looking to catch up to speed with best practices and basic techniques and then an intermediate session level to discuss some of the more technical aspects of project management.

Categories: Drupal