Planet Drupal

Subscribe to Planet Drupal feed - aggregated feeds in category Planet Drupal
Updated: 32 min 2 sec ago

Mediacurrent: Easy Ways to Make Your Website More Accessible

Tue, 22/03/2016 - 17:56

I recently had the opportunity to give a beginners talk about website accessibility at MidCamp 2016 where I covered some easy ways to promote accessibility in terms of structure, color and contrast, fonts, links, and media. It was a wonderful experience for me and I was grateful for the audience who had some nice feedback and interesting questions. Here are the highlights of the presentation, plus the audio recording and links to related resources.  

Categories: Elsewhere

Jeff Geerling's Blog: Use Drupal 8 Cache Tags with Varnish and Purge

Tue, 22/03/2016 - 17:52

Over the past few months, I've been reading about BigPipe, Cache Tags, Dynamic Page Cache, and all the other amazing-sounding new features for performance in Drupal 8. I'm working on a blog post that more comprehensively compares and contrasts Drupal 8's performance with Drupal 7, but that's a topic for another day. In this post, I'll focus on cache tags in Drupal 8, and particularly their use with Varnish to make cached content expiration much easier than it ever was in Drupal 7.

Categories: Elsewhere

Disruptive Library Technology Jester: Modify Islandora objects on-the-fly using Devel “Execute PHP Code”

Tue, 22/03/2016 - 16:45

Alan Stanley taught me this trick at an Islandora Camp a few years ago, and when trying to remember it this morning I messed up one critical piece. So I’ll post it here so I have something to refer back to when I need to do this again.

The Drupal Devel module includes a menu item for executing arbitrary PHP code on the server. (This is, of course, something you want to set permissions on very tightly because it can seriously wreck havoc on your day if someone uses it to do bad things.) Navigate to /devel/php on your Islandora website (with the Devel module enabled), and you’ll get a nice, big ≶textarea> and an “Execute” button:

Execute arbitrary PHP using Drupal Devel module.

In this case, I’m generating the TECHMD datastream using the FITS module and displaying the results of the function call on the HTML page using the Devel module’s dpm() function:

include drupal_get_path('module', 'islandora_fits') . '/includes/'; $object= islandora_object_load('demo:6'); $results = islandora_fits_create_techmd($object, False, array('source_dsid' => 'OBJ')); dpm($results);

Works like a charm!

Categories: Elsewhere

Acquia Developer Center Blog: Do You Need to Upgrade Your Drupal Site?

Tue, 22/03/2016 - 16:01

We've been talking to our clients about Drupal upgrades a lot lately. This is not surprising, of course, given the recent release of Drupal 8, which signaled the end of life for Drupal 6.

The Drupal community is excited about all that Drupal 8 has to offer.  If you’re on Drupal 6, however, that excitement may be muted by the feeling that you're between platforms. You want to be thoughtful about your next steps. You want to anticipate all the possible consequences. The stakes are high.

Here at Advomatic we've been involved in many, many Drupal upgrade decisions in the last few months. We've gotten good at helping customers navigate the options.

So what are we now telling our current customers, and prospective customers? Read on.


Tags: acquia drupal planet
Categories: Elsewhere

Danny Englander: Drupal 8 Theming: How I got Inspired by Drupal All Over Again

Tue, 22/03/2016 - 15:53

When Drupal 8 and its innovative architectural changes were first announced several years back, there were a variety of reactions within the community ranging from euphoria and elation, to FUD and potential abandonment of the platform altogether. I remember feeling caught in the middle of these two camps, not really being able to come to any conclusion for some time to come.

Admittedly, I had my reservations about Drupal 8 but I really wanted to give it a chance. I experimented with it while in the early alpha stages, but for a themer it was frustrating as there were constant code changes to core (as was to be expected), and the theming layer was constantly evolving.

In fact, these broad changes with Drupal 8 prompted the forking of Drupal 7 into a new platform called Backdrop CMS, which would carry the essence of Drupal 7 into the future while taking some of the refinements made to Drupal 8 and splitting the difference. I tested out Backdrop during that time as well, but honestly I was not happy with Backdrop's theming layer; it seemed disjointed to me.

Getting inspired all over again

Fast forward to 2016 and now that Drupal 8 has been out for almost six months, I decided to dig in again. It all started with attending SANDCamp here in San Diego at the end of February. Thanks to my company, Jackson River for making my attendance to the camp possible, I was inspired by Drupal all over again and moreover, by Drupal 8. I was especially taken by how awesome and logical theming is in Drupal 8; it's now super refined and powerful. At the camp, I took an all day Drupal 8 theming workshop led by the good folks at Chapter Three, and by the end of the day I saw the light and was a believer.

A lot of this has to do with two new base themes in Drupal 8 called "Classy" and "Stable," as well as the underlying Twig and YAML frameworks. Out the box, Classy and Stable each give you 100 + templates to override and modify into your own custom sub-theme.

Classy has class "Its purpose is to provide many classes throughout the markup that help annotate and describe markup elements that render on the page. In the past, the extra effort that Drupal applies to elements in annotating them this way has been viewed as helpful by some and a hindrance by others. In Drupal 8, you now have the option of either including or excluding this extra help." Go minimal, don't use classy "Not using Classy is a great idea when you don't want the classes defined by Drupal to conflict with CSS and JavaScript frameworks being used by your theme. Excluding Classy gives you full responsibility over the classes your theme has."

I'm now in the process of designing and developing a Drupal 8 theme and I'm still deciding whether to use Classy or Stable as my base-theme. I'm thinking I'll use Classy and then in any of my template sub-theme overrides, I can alter or remove markup as needed. Using either of these as a base-themes in combination with Twig debugging makes Drupal 8 a theming force to be reckoned with.

Less preprocessing, more Twig

Much of what used to be done altering things like field markup with theme_field in Drupal 7 is much more accessible and alterable directly in Twig templates now in Drupal 8. Thus, less of a need to use theme preprocess functions compared with Drupal 7. However, when you do need to write a preprocess function, you'll typically use minimal code. The other thing that I love with Drupal 8 theming is that theme hooks seem to be more accessible and easier to write via quick and easy alter hooks. Write a hook and magically see your new template suggestion(s) appear in your Twig debug area. In addition, the Drupal 7 module, View Modes in now part of Drupal 8 core so you get easy creation of view modes AKA Display Modes with a UI right out of the box. This is great news for themers, and I've become a huge fan theming using view modes over the past few years.

Devel Kint

As a themer, if you were used to exploring data arrays in Drupal 7 with Devel's venerable dpm functions, with Drupal 8 you can use Devel "Kint". Kint is somewhat mind boggling at first but it does do very similar things asdpm did with Drupal 7. The one big feature missing for me with Kint is a search function similar to the Search Krumo module in Drupal 7. I hope that becomes available in the future. Kint most definitely comes in handy for designing your theme hooks.


I am really excited about theming with Drupal 8, I feel like I did when I first discovered and started developing with Drupal 6 back in 2009. In the coming months here on my blog, I hope to share some of this new-found theming knowledge. One of the main takeaways is that Drupal 8 theming presents far less of a barrier to entry than I thought it would.

  • Drupal Planet
  • Drupal 8
  • Twig
  • Drupal
Categories: Elsewhere

Code Enigma: Drupal Security Audits: What to look for

Tue, 22/03/2016 - 14:59
Drupal Security Audits: What to look for Language English Drupal Security Audits: What to look for

Security audits in Drupal are not a trivial thing. This is how we do it.

Tue, 2016-03-22 13:59By salva

Site audits are one of the services that some of our clients have requested from us in the past. While a site audit might be done with a specific objective in mind, there's always a common reason: find, understand, and fix any potential holes or problems that could cause a service outage on the site, or on the server where it is hosted. In some cases, that's the only reason, whereas in other cases the outcome of the audit will inform a more important decision, such as a platform or server move, or a site rebuild, to name a few.

Depending on the goal of an audit, the things to look at on the site might change a bit: is it a performance audit, a security one, or a general review to check the overall status of the site and the feasibility of keep evolving it in an efficient way? This post covers the details concerning security audits in particular, although some of the practices mentioned here do not belong exclusively to the realm of security, and will be equally needed in other audits. Let's get started.

General aspects

There are some things that an audit should always cover, as they give a good overview of the site and how well it's been looked after. Some of these aspects are:

  • General codebase observations: Get an overview of the structure and organisation of modules and custom php scripts (if any). In big projects, where people come and go and different developers get to work on the code, it's not uncommon to see a big mess in custom code, structured without consistent patterns or styleguides. This might not affect security directly, but it might be a sign that not much care has been put into how things are done, and it will surely impact maintenance.
  • General code inspection: Performed through an IDE or automated tools, to find extensive uses of bad practices in code. Again, this might not necessarily surface any potential security holes, but depending on the tools used, there are cases in which it could actually do so. A good tool for a general review of Drupal modules is the Coder module, which can be tuned to look only for problems of a specific nature (e.g: only check Drupal standards).
  • Site Audit Script: The Site Audit module is worth a look as well. While it's not the most feature-complete audit tool, it provides useful info about certain areas of a Drupal site, and includes some security checks too.
  • Watch out for patched modules: The Hacked! module can help you to easily identify which contributed modules have been altered by developers after the official version was added to the codebase.  It compares the installed version with the official one available in, to highlight the differences. If the development team have behaved well, all these patches will be documented in some way in the codebase, so make sure you consider them in more specific audits, in particular for security.
Finding the security holes

Drupal core is great when it comes to security, and it also encourages module developers to follow good practices when contributing to the community, by providing clear guidelines about how to write secure code. However, considering the low entry barrier of the platform for anyone who has some basic PHP skills, it's not hard to find projects in which some of the standard APIs and guideliness are either overlooked, or bypassed entirely. This opens possible security holes in the system.

Being a CMS, the possible security holes of a Drupal site may not lay only in the codebase, but also in how the different modules are configured, often in a too-permissive fashion. Enabling PHP Filter to allow PHP execution from the UI, or a bad configuration of input (text) formats, are just a couple examples of how a bad configuration could be used to breach into the site. You can find more details about this in this page of the Administration & Security Guide.

In this article, I'd like to focus a bit more in the possible issues that can be generated at the codebase level. The next list covers the most common vulnerabilities that should be looked for when auditing a Drupal project, and some other aspects to consider. These checks are normally for the custom code. Some details are given next to each vulnerability type, with the common functions or elements that can be used to exploit the vulnerability, or where it might be introduced:

  • SQL Injection: Make sure no $_GET data is used without proper sanitisation, specially if it's going to be used in queries to the database. The term is a classic, I know, and it's been used and abused all over the web for a lot of years, but not without cause: it's been less than two years since I came across a vulnerability of this type (don't get excited, you won't find any name and shame in this post). 

    • Check as well for usage of drupal_get_query_parameters(). If not treated safely, data received from there can be as dangerous as $_GET.

  • Remote code execution: Make sure $_POST data is being used safely.  Not usually an issue if Drupal Form API is used. While not encouraged, it's possible for developers to use $_POST or $form_state['input'] to retrieve user-submitted data. So, when searching for places where this kind of data is used in code, make sure those variable names are included in the search.

    • Pay also attention to custom data stored in the database that is later used for custom logic, but having being previously retrieved through a custom form.

    • Some functions can be used to exploit vulnerabilities with malicious data captured through any of the methods described. Most of these functions are not too common for small websites, but they can be very dangerous if not used with care, so it's always worth looking for any usages of these in code, and in case you see any of them, ensure they're used safely:

      • eval

      • preg_replace

      • create_function

      • include_once

      • require_once

      • system

      • exec

      • shell_exec

      • pcntl_exec

  • XSS / Persistent XSS: Another classic. Check that all user input is sanitised before being output as HTML. See Handle text in a secure fashion:

    • General checks. Make sure these functions or statements are used according to the documentation, and with data sanitised where relevant:

      • print.

      • echo.

      • l().

      • t().

    • Custom blocks:

      • Make sure anything contained in blocks content is sanitised, since these contents are output "as is".

    • Other possibly dangerous Drupal elements:

      These elements are not dangerous as such, but they're used to display HTML contents. The general idea here is: sanitise data before displaying it!

      • theme(‘placeholder’).

      • drupal_set_title().

      • theme(‘username’).

      • Custom forms.

      • Form API #title and #description

      • Form API #markup types.

      • Review usages of rich text fields in code, and make sure they're always displayed using their appropriate text format.

    • Treatment of incoming URL data in usage of HTML attributes. Arguments that might be used in HTML attributes could be encoded in a way that malforms the HTML to ultimately inject Javascript.

    • Views fields without sanitising (e.g: using the "raw” contents from a views template).

  • Privilege escalation:

    • Do all custom hook_menu functions have access arguments declared?

    • Do all custom queries use the node_access tag where required?

    • Are permissions respected when displaying entities retrieved via EntityFieldQuery?

  • CSRF: Make sure all custom forms use Drupal's FAPI or confirmation forms / tokens.

  • General configuration:

    These are some of the most common checks to go through when reviewing the site configuration:

    • HTTPS configured correctly.

    • PHP filter is disabled.

    • Access to text formats.

    • Private files directory is in a secure location outside of webroot.

    • Execution of PHP files in subfolders disabled.

  • ​Everything else covered in the Writing secure code page of the Drupal developer handbook.

  • Anything listed in the OWASP Top 10 should be always present in a security audit.


Some of the points listed there are rather uncommon to see these days. However, no matter how unlikely they are, a security vulnerability is always a risk, so as good developers is our duty to, at least, try our best to make sure we follow good practices and don't create holes in the system, or fix them if we find any.

Once in the auditor role, there are tools to automate the search for some of the possible issues in code. One example is the Security Review module for Drupal, which makes some checks on a given site (none on the codebase itself) and generates a report highlighting the areas where the configuration should be changed. Taking it a step further, the Paranoia module will automatically make some changes to your site, disabling certain sections or features that could make it insecure.

Security is not a setting, it's a process, and even experts (except Code Enigma sysadmins) make mistakes. The worst mistake one can make about a site is taking its security for granted. 


PageDrupal Security Updates PageSecure Drupal Hosting BlogMeet the YubiKey PageDrupal Support
Categories: Elsewhere

OpenLucius: Better quality images on your Drupal website | When using Insert module

Tue, 22/03/2016 - 14:21

The Drupal Insert module is a convenient module to easily place images in content, without hassling around with a WYSIWYG editor. It is rightly a popular Drupal module (nearly 80,000 active installs). We are also using it in our blogs; in combination with Markdown you can easily and quickly format content.

The only problem is that the images are not looking good. The quality of the scaled images can be set in Drupal (Administration > Configuration > Media > Image toolkit), but I noticed they are never really good enough. Also because you have to deal with many different kinds and sizes of screens of visitors: you would like everybody to see a nice image (mobile, tablet, desktop, retina etc).

Solution for better quality images
Categories: Elsewhere

Acquia Developer Center Blog: Defining and Altering Routes in Drupal 8

Tue, 22/03/2016 - 14:15

Drupal's menu system API underwent a large number of significant changes in Drupal 8, just like many other areas in Drupal's newest version. 

The way we define what piece of PHP logic should respond to a particular path, e.g. /example, is no longer part of the menu; instead it is now defined via the route system. The menu system - as it should logically - is now used to define how a particular page (a route) fits into the menu system, tabs, and contextual links. Let’s take a quick look at how the familiar tasks of defining and altering such entries have changed.

Tags: acquia drupal planet
Categories: Elsewhere

Drop Guard: Essential Drupal security modules

Tue, 22/03/2016 - 13:40
Essential Drupal security modules Igor Kandyba Tue, 22.03.2016 - 13:40

We, at Drop Guard, are extremely concerned about all things Drupal security. Security is not something that can be taken for granted after ordering a security review, or passing through a "security checklist", or even after switching to Drop Guard for updates handling. We should always remember that security is a continuous process, and it consists of numerous bits and pieces requiring your attention all the time.

Luckily enough, Drupal is a highly modular system, and instead of reinventing the wheel we can take advantage of the existing and battle tested solutions which are aimed at helping us with ensuring the continuous security for our applications.

We've collected the essential security-related modules in our view, and split them into two categories - passive (designed to monitor and provide information) and proactive (designed to take action or make changes to application configuration to ensure stronger security).

Modules Security Drupal Planet
Categories: Elsewhere

Dries Buytaert: How should you decouple Drupal?

Tue, 22/03/2016 - 11:03

With RESTful web services in Drupal 8 core, Drupal can function as an API-first back end serving browser applications, native applications on mobile devices, in-store displays, even in-flight entertainment systems (Lufthansa is doing so in Drupal 8!), and much more. When building a new website or web application in 2016, you may ask yourself: how should I decouple Drupal? Do I build my website with Drupal's built-in templating layer or do I use a JavaScript framework? Do I need Node.js?

There is a lot of hype around decoupled architectures, so before embarking on a project, it is important to make a balanced analysis. Your choice of architecture has implications on your budget, your team, time to launch, the flexibility for content creators, the ongoing maintenance of your website, and more. In this blog post, I'd like to share a flowchart that can help you decide when to use what technology.

This flowchart shows three things:

First, using coupled Drupal is a perfectly valid option for those who don't need extensive client-side rendering and state management. In this case, you would use Drupal's built-in Twig templating system rather than heavily relying on a JavaScript framework. You would use jQuery to take advantage of limited JavaScript where necessary. Also, with BigPipe in Drupal 8.1, certain use cases that typically needed asynchronous JavaScript can now be done in PHP without slowing down the page (i.e. communication with an external web service delaying the display of user-specific real-time data). The advantage of this approach is that content marketers are not blocked by front-end developers as they assemble their user experiences, thus shortening time to market and reducing investment in ongoing developer support.

Second, if you want all of the benefits of a JavaScript framework without completely bypassing Drupal's HTML generation and all that you get with it, I recommend using progressively decoupled Drupal. With progressive decoupling, you start with Drupal's HTML output, and then use a JavaScript framework to add client-side interactivity on the client side. One of the most visited sites in the world, The Weather Channel (100 million unique visitors per month), does precisely this with Angular 1 layered on top of Drupal 7. In this case, you can enjoy the benefits of having a “decoupled" team made up of both Drupal and JavaScript developers progressing at their own velocities. JavaScript developers can build richly interactive experiences while leaving content marketers free to assemble those experiences without needing a developer's involvement.

Third, whereas fully decoupled Drupal makes a lot of sense when building native applications, for most websites, the leap to fully decoupling is not strictly necessary, though a growing number of people prefer using JavaScript these days. Advantages include some level of independence on the underlying CMS, the ability to tap into a rich toolset around JavaScript (e.g. Babel, Webpack, etc.) and a community of JavaScript front-end professionals. But if you are using a universal JavaScript approach with Drupal, it's also important to consider the drawbacks: you need to ask yourself if you're ready to add more complexity to your technology stack and possibly forgo functionality provided by a more integrated content delivery system, such as layout and display management, user interface localization, and more. Losing that functionality can be costly, increase your dependence on a developer team, and hinder the end-to-end content assembly experience your marketing team expects, among other things.

It's worth noting that over time we are likely to see better integrations between Drupal and the different JavaScript frameworks (e.g. Drupal modules that export their configuration, and SDKs for different JavaScript frameworks that use that configuration on the client-side). When those integrations mature, I expect more people will move towards fully decoupled Drupal.

To be performant, fully decoupled websites using JavaScript employ Node.js on the server to improve initial performance, but in the case of Drupal this is not necessary, as Drupal can do the server-side pre-rendering for you. Many JavaScript developers opt to use Node.js for the convenience of shared rendering across server and client rather than for the specific things that Node.js excels in, like real-time push, concurrent connections, and bidirectional client-server communication. In other words, most Drupal websites don't need Node.js.

In practice, I believe many organizations want to use all of these content delivery options. In certain cases, you want to let your content management system render the experience so you can take full advantage of its features with minimal or no development effort (coupled architecture). But when you need to build a website that needs a much more interactive experience or that integrates with unique devices (i.e. on in-store touch screens), you should be able to use that same content management system's content API (decoupled architecture). Fortunately, Drupal allows you to use either. The beauty of choosing from the spectrum of fully decoupled Drupal, progressively decoupled Drupal, and coupled Drupal is that you can do what makes the most sense in each situation.

Special thanks to Preston So, Alex Bronstein and Wim Leers for contributions to this blog post. We created at least 10 versions of this flowchart before settling on this one.

Categories: Elsewhere Happy birthday to me and Devel form debug module to you all

Tue, 22/03/2016 - 05:26
I’m turning 32 today. People love birthdays, to me it’s just another line number in a messed stack trace output (philosophy mode enabled).   Two years ago I released a drupal module called Get form id (deprecated from now on) that does one small task - it tells you any form's id ...

Read now

Categories: Elsewhere

2bits: Installing and Configuring Redis for Drupal 7, and other Memcached Alternatives

Tue, 22/03/2016 - 04:15

For years, we have been using and recommending memcached for Drupal sites as its caching layer, and we wrote several articles on it, for example: configuring Drupal with multiple bins in memcached.

Memcached has the advantage of replacing core caching (which uses the database) with memory caching. It still allows modules that have hook_boot() and hook_exit() to work, unlike external cache layers such as Varnish.

However, memcached has its limitations: It is by definition transient, so rebooting wipes out the cache, and the server can suffer if it has high traffic. It is also entirely memory resident, so to cache more items you need more RAM, which is not suitable for small servers.

For Drupal 7, there is a solution that does avoids this first limitation: Redis. It provides persistence, but not the second.

The following is a detailed guide to get Redis installed and configured for your server. It assumes that you are an Ubuntu Server 14.04, or the equivalent Debian release.

Installing Redis

First, download the Drupal redis module, which should go to sites/all/modules/contrib. You can do that in many ways, here is how you would use Drush for that:

drush @live dl redis

You do not need to enable any Redis modules in Drupal.

Then, install the Redis Server itself. On Debian/Ubuntu you can do the following. On CentOS/RedHat, you should use yum.

aptitude install redis-server

Then, install PHP's Redis integration. Once you do that, you do not need to compile from source, or anything like that, as mentioned in Redis README.txt file.

aptitude install php5-redis

Restart PHP, so it loads the Redis integration layer.
This assumes you are using PHP FPM:

service php5-fpm restart

If you are using PHP as an Apache module, then you need to restart it as follows:

service apache2 restart Configuring Redis

Then in your settings.php file, you should replace the section for memcache which would be as follows:

$conf['cache_backends'][] = './sites/all/modules/contrib/memcache/';
$conf['cache_default_class'] = 'MemCacheDrupal';
$conf['memcache_servers'] = array('' => 'default');
$conf['memcache_key_prefix'] = 'site1';

And replace it with the following configuration lines:

// Redis settings
$conf['redis_client_interface'] = 'PhpRedis';
$conf['redis_client_host'] = '';
$conf['lock_inc'] = 'sites/all/modules/contrib/redis/';
$conf['path_inc'] = 'sites/all/modules/contrib/redis/';
$conf['cache_backends'][] = 'sites/all/modules/contrib/redis/';
$conf['cache_default_class'] = 'Redis_Cache';
// For multisite, you must use a unique prefix for each site
$conf['cache_prefix'] = 'site1'; Cleaning Up

Once you do that, caching will start using redis. Memcached is not needed, so you should stop the daemon:

service memcached stop

And you should purge memcached as well:

aptitude purge memcached

And that is all there is to it.

Changing Redis Configuration

You can then review the /etc/redis/redis.conf file to see if you should tweak parameters more, such as changing maxmemory to limit it to a certain amount, as follows:

maxmemory 256mb

More below on this specific value.

Checking That Redis Is Working

To check that Redis is working, you can inspect that keys are being cached. For this, you can use the redis-cli tool. This tool can be used interactively, as in, you get a prompt and type commands in it, and results are returned. Or you can use the specific command as an argument to redis-cli.

For example, this command filters on a specific cache bin, the cache_bootstrap one:

$ redis-cli> keys *cache_boot*

Or you can type it as:

$ redis-cli keys "*cache_boot*"

In either case, if Drupal is caching correctly, you should see output like this:

1) "site1:cache_bootstrap:lookup_cache"
2) "site2:cache_bootstrap:system_list"
3) "site3:cache_bootstrap:system_list"
4) "site3:cache_bootstrap:hook_info"
5) "site2:cache_bootstrap:variables"

As you can see, the key structure is simple, it is composed of the following components, separated by a colon:

  • Cache Prefix
    This is the site name in a multi site environment.
  • Cache Bin
    This is the cache table name when using the default database caching in Drupal.
  • Cache Key
    This is the unique name for the cached item. For cached pages, the URL is used, with the protocol (http or https) and the host/domain name.

You can also filter by site, using the cache_prefix:

$ redis-cli keys "*site1:cache_page*"

The output will be something like this:

1) "site1:cache_page:"
2) "site1:cache_page:"

You can also check how many items are cached in the database:

$ redis-cli dbsize

The output will be the number of items:

(integer) 20344 Flushing The Cache

If you need to clear the cache, you can do:

$ redis-cli flushall Checking Time To Live (TTL) For A Key

You can also check how long does a specific item stay in cache, in seconds remaining:

$ redis-cli ttl site1:cache_page:

The output will be the number of seconds:

(integer) 586 Getting Redis Info

You can get a lot of statistics and other information about how Redis is doing, by using the info command:

$ redis-cli info

You can check the full documentation for the info command.

But here is one of the important values to keep an eye on is used_memory_peak_human, which tells you the maximum memory that was used given your site's specifics, such as the number of items cached, the rate of caching, the size of each item, ...etc.


You can use that value to tune the maxmemory parameter, as above.

You can decrease the Minimum Cache Lifetime under /admin/config/development/performance to make the available memory fit that number, or the other way around: you can allocate more memory to fit more.

Monitoring Redis Operations In Real Time

And finally, here is a command that would show you all the operations that are being done on Redis in real time. Do not try this on a high traffic site!

$ redis-cli monitor Performance Results

Redis performance as a page cache for Drupal is quite good, with Time To First Byte (TTFB) is ~ 95 to 105 milliseconds.

Alternatives To Redis and Memcached

We did fairly extensive research for Redis and Memcached alternatives with the following criteria:

  • Compatible With Redis or Memcached Protocol
    We wanted to use the same PHP extension and Drupal Redis (or Memcached) modules, and not have to write and test yet another caching module.
  • Non-Memory Resident Storage
    We want to reduce the memory foot print of Redis/Memcached, because they both store the entire key/value combinations in memory. But still wanted to get acceptable performance.

The following products all claim to meet the above criteria, but none of them worked for us. They were tested on Ubuntu LTS 14.04 64-bit:


Using MongoDB article for more details.


MemcacheDB is a Memcached compatible server which used the excellent Berkeley DB database for storage.

This MemcacheDB presentation explains what it does in detail.

It has an Ubuntu package right in the repository, so no need to compile from source, or manually configure it. It works flawlessly. The -N option enable the DB_TXN_NOSYNC option, which means writes to the database are asynchronous, providing a huge performance improvement.

Configuration in Drupal's settings.php is very easy: it is exactly like Memcached, with only the port number changing, from 11211 to 21201.

Alas, all is not rosy: it is not really a cache layer, since it does not expire keys/values based on time, like Memcached and Redis does.

Redis NDS

Redis-NDS is a fork of Redis 2.6, patched for NDS (Naive Disk Store).

It does compile and run, but when the line: 'nds yes' is added to the configuration file, it is rejected as an invalid value. Looking briefly in the source, we also tried 'nds_enabled yes', but that was rejected as well. So we could not get it to run in NDS mode.


ARDB is another NoSQL database that aims to be Redis protocol compatible.

We compiled this with three different storage engines: The Facebook RocksDB did not compile to begin with. Google's LevelDB compiled cleanly, and so did WiredTiger. But when trying to connect Drupal to it, Drupal hanged and never came back with both engines.


SSDB is also another NoSQL database that tries to be Redis protocol compatible.

It compiled cleanly, but had the same symptom as ARDB: Drupal hangs and never receives back a reply from SSDB.

There are a couple of sandbox projects, here and here, that aim for native integration, but no code has been committed so far in two years.

If you were able to get any of the above, or another Redis/Memcached compatible caching engine working, please post a comment below.

Resources Tags: Contents: 
Categories: Elsewhere

2bits: MongoDB as a caching solution for Drupal 7

Tue, 22/03/2016 - 04:05

MongoDB is a NoSQL database that has Drupal integration for various scenarios.

One of these scenarios is using MongoDB as the caching layer for Drupal.

This article describes what is needed to get MongoDB working as a caching layer for your Drupal site. We assume that you have an Ubuntu Server LTS 14.04 or similar Debian derived distro.

Download The Drupal Module

First, download the MongoDB Drupal module. You do not need to enable any MongoDB modules.

drush @live dl mongodb Install MongoDB Server, Tools and PHP Integration

Then install MongoDB, and PHP's MongoDB integration. Note that 'mongodb' is a virtual package that installs the mongodb-server package as well as other client tools and utilities:

aptitude install php5-mongo mongodb Restart PHP

Restart PHP, so that MongoDB integration takes effect:

service php5-fpm restart Configure Drupal With MongoDB

Now, edit your settings.php file, to add the following:

$conf['mongodb_connections']['default']['host'] = 'mongodb://';
$conf['mongodb_connections']['default']['db'] = 'site1';
$conf['cache_backends'][] = 'sites/all/modules/contrib/mongodb/mongodb_cache/';
$conf['cache_default_class'] = 'DrupalMongoDBCache';

Note, that if you have multisite, then using a different 'db' for different sites will prevent cache collision.

Monitoring MongoDB

You can monitor MongoDB using the following commands.

mongotop -v
mongostat 15 Tuning MongoDB

Turn off MongoDB's journaling, since we are using MongoDB for transient cache data that can be recreated from Drupal.

Edit the file /etc/mongodb.conf and change journal= to false.

Performance Results

Quick testing on a live site showed that MongoDB performance is acceptable, but not spectacular. That is specially true when compared to other memory resident caching, such as Memcached or Redis.

For example, on the same site and server, with Redis, Time To First Byte (TTFB) is ~ 95 to 105 milliseconds. With MongoDB it is ~ 200, but also goes up to ~350 milliseconds.

Still, MongoDB can be a solution in memory constrained environments, such as smallish VPS's.

Tags: Contents: 
Categories: Elsewhere

Chromatic: Civil Comments Drupal Module

Mon, 21/03/2016 - 21:46

Civil Comments is a platform that brings real-world social cues to comments sections via crowd-sourced moderation and powerful community management tools. Civil Comments is the first commenting platform specifically designed to improve the way people treat each other online.

Unlike others who have thrown up their hands and accepted that the comments sections of the Internet would either be dominated by bullies and trolls, or become a moderation burden for a site's editors, the team at Civil is attempting to solve the problem with community moderation. It is an exciting new take on a widespread problem, and Chromatic is thrilled to bring Civil Comments integration to Drupal with a new contrib module.

It should be noted (and is on the project page!) that there is not currently a free version of Civil Comments. For the time being, it is only available with a subscription as Civil continues work on the platform, but from what I understand a free version is on the horizon.

A special thanks to Christopher Torgalson and Alanna Burke, whose contributions helped get this project off the ground!

Categories: Elsewhere

Acquia Developer Center Blog: Drupal 8: REST in Core

Mon, 21/03/2016 - 21:04

It's a good time to press your advantage as a Drupal developer. 

Drupal 8 has launched, and it's much easier now for Drupal developers to expose content and features on their sites via an API. The capability is built right into Drupal 8 Core. Some contrib modules are attempting to make such capabilities even better.

Tags: acquia drupal planet
Categories: Elsewhere

Drupal @ Penn State: Testing Drush concurrency

Mon, 21/03/2016 - 20:16

I had a question the other day on twitter as to if it’s possible to run drush sites aliases in parallel. Apparently I was asking the question the wrong way as @greg_1_anderson (Drush co-maintainer) told me that Drush supported –concurrent and apparently has for several years. In fact, its supported it so long and is so under used that they might remove it from Drush as a result :).

Categories: Elsewhere

Drupal @ Penn State: Drupal, A thesis.

Mon, 21/03/2016 - 20:16

I recently defended my Master of Sciences thesis with a central theme of open source, activism and Drupal. You can grab a copy here or in the article links. I started this research project in 2007, in part, life got in the way but also, I didn’t know how to tell the story.

Categories: Elsewhere