May 25 2015
May 25
This will be the second part of the code examples, and the third in the series about Drupal and the Internet of Things.

If you haven't read the other parts of it, you are going to be all fine. But if you want to, the front page has a complete list

In this part we will look at simplifying the request flow for the client, while still keeping a certain level of security for our endpoint. There are several ways of doing this, but today we will look at a suggestion on how to implement API keys per user.

Let me just start first by saying there are several additional steps you could (and ideally should) implement to get a more secure platform, but I will touch on these towards the end of the article.

First, let's look at a video I posted in the first blog post. It shows an example of posting the temperature to a Drupal site.

[embedded content]


Let's look at the scenario we will be implementing

  • A user registers an account on our Drupal 8 site
  • The user is presented with a path where they can POST their temperatures (for example
  • The temperature is saved for that user when that request is made

See any potential problems? I sure hope so. Let's move on.

Registering the temperature in a room and sending to Drupal

As last time, I will not go into details on the implementation of any micro controller or hardware specific details in the blog post. But the code is available on github. I will quickly go through the technical steps and technologies used here:

  • I use a Raspberry pi 2, but the code should work on any model Raspberry pi
  • I use a waterproof dsb18b20 sensor, but any dsb18b20 should work. I have a waterproof one because I use it to monitor my beer brewing :)
  • The sensor checks the temperature at a certain interval (per default, 1 minute)
  • The temperature data is sent to the Drupal site and a node is created for each new registration
  • To authenticate the requests, the requests are sent with a x-user-temp header including the API key

This scenario is a bit different from the very real time example in the video above, but it is both more flexible (in terms of having a history of temperatures) and real-life (since temperatures seldom have such real-time changes as the one above).

Receiving temperatures in Drupal

The obvious problem with the situation described above, is the authentication and security of the transferred data. Not only do we not want people to be able to just POST data to our site with no authentication, we are also dealing with temperatures per user. So what is to stop a person to just POST a temperature on behalf of another user? Last post dealt with using the same user session as your web browser, but today we are going to look at using API keys.

If you have ever integrated a third party service to Drupal (or used a module that integrates a third party service) you are probably familiar with the concept of API keys. API keys are used to specify that even though a "regular" request is made, a secret token is used to prove that the request originates from a certain user. This makes it easy to use together with internet connected devices, as you would not need to obtain (and possibly maintain) a session cookie to authenticate as your user.

Implementation details

So for this example, I went ahead and implemented a "lo-fi" version of this as a module for Drupal 8. You can check out the code at github if you are eager to get all the details. Also, I deployed the code on Pantheon so you can actually go there and register an account and POST temperatures if you want!

The first step is to actually generate API keys to users that wants one. My implementation just generates one for users when they visit their "user temperatures" tab for the first time.

Side note: The API key in the picture is not the real one for my user.

Next step is to make sure that we use a custom access callback for the path we have defined as the endpoint for temperatures. In my case, I went with making the endpoint per user, so the path is /user/{uid}/user_temp_post. In Drupal 7 you would accomplish this custom access check by simply specifying something like this in your hook_menu:

'access callback' => 'my_module_access_callback',

In Drupal 8, however, we are using a my_module.routing.yml file for routes we are defining. So we also need to specify in this file what the criteria for allowing access should be. For a very good example of this, I found the user.module to be very helpful. My route for the temperature POST ended up like this:

  path: '/user/{user}/user_temp_post'
    _controller: '\Drupal\user_temp\Controller\UserTempController::post'
    _title: 'Post user temperatures'
    _access_user_temp_post: 'TRUE'

In this case '_access_user_temp_post' is what will be the criteria of allowing access. You can see this in the file of the module. From there you can also see that Drupal\user_temp\Access\PostTempAccessCheck is the class responsible for checking access to the route. In this class we must make sure to return a Drupal\Core\Access\AccessResult to indicate if the user is allowed access or not.

Some potential questions about the approach

From there on in, the code for the POST controller should provide you with the answers you need. And if the code is not enough, you can try to read the tests of the client part or the Drupal part. I will proceed with making assumptions about theoretical questions to the implementation:

How is this different from using the session cookie?

It is different in 2 aspects. The API key will not expire for reasons beyond your control. Or more precisely, the device's control. You can also reset the API key manually if you would want it to expire. The other big difference is that if your API key should be compromised, your account is not compromised in any way (as would be the case if a valid session cookie were to be compromised). Beyond that, please observe that in one area this is not different from using a session cookie: The requests should be made over https, especially if you are using a wifi connection.

How can I further strengthen the security of this model?

One "easy" way to do this is to not expose the API key as part of the request. I was originally planning to implement this, but realised this might make my original point a little less clear. What I would do as a another "lo-fi" hardening would be to make the x-user-temp header just include a hash of the temperature sent and the user API key. This way, if someone were sniffing the requests, they would just see that the x-user-temp header would change all the time, and so it would take a considerable effort to actually forge the requests (compared to just observing the key in the header).

Why are you using nodes? Isn't that very much overhead for this?

This is a fair point. It might be a bit overkill for something so simple. But there are two bonus parts about using nodes:

  • We can use views to display our data.
  • We can ship the views, content types and fields as configuration with our module.
This last part is especially powerful in Drupal 8, and incredibly easy to accomplish. For the files required for this particular implementation, you can reference the config/install directory of the module.

But since you are posting nodes, why aren't you using the REST module?

I admit it, I have no good reason for this beyond that I wanted to make this post be about implementing API keys for authentication. Also, here is a spoiler alert: Code examples part 3 will actually be using the REST module for creating nodes.

What if I want to monitor both my living room and my wine cellar? This is only one endpoint per user!

I am sorry for not implementing that in my proof of concept code, but I am sure you can think of a creative solution to the problem. Also, luckily for you, the code is open source so you are free to make any changes required to monitor your wine cellar. "Pull requests welcome" as they say.

As always, if you have any question or criticism (preferably beyond the points made above) I would love to hear thoughts on this subject in the comments. To finish it all off, I made an effort to find a temperature related gif. Not sure the effort shows in the end result.

May 25 2015
May 25

Drupal 8

Four years ago we made an important decision at Netstudio: We would migrate to Drupal. Drupal 7 had just come out, and despite our having mastered Joomla at online-store level, we simply could not ignore Drupal’s embedded Content Construction Kit, its multi-lingual support, safety, stability, scalability, search engine friendliness, but, most of all, the professionalism of the Drupal community.

Drupal 7 helped us undertake even bigger and more complex projects, and build all of our solutions for ecommerce and presentation websites, including even our ERP, project management tool, quotes generation and hiring systems and our project management tool. It was on Drupal we based our company’s projects, like and, as well as more than 200 websites and online stores for our customers.

Not for a single moment have we regretted our migration to Drupal, despite our having to learn a new ecosystem from scratch.

Just six months after Drupal 7 was launched, the Drupal community set off for Drupal 8. Dries Buytaert set very high standards for the new version of Drupal defining the main pillars to set it on the crest of the wave.

Four and a half years of development later, beta 10 release is here, signalling the approach of the final release in less than 6 months from now!

More than 2800 programmers ? twice as many as for its predecessor ? have contributed for Drupal 8 developing hundreds of new features.

The most significant structural change made was that it was based on Symfony2 framework thus turning it into an object-oriented platform. From now on, large chunks of code, such as Guzzle, Twig (the new theming system), the Composer, etc. come from the Symfony2 community.

Moreover, Drupal 8 brings along enormous changes in the way we develop websites.


Multilingual support is very important for us, since we are based in Greece and our many international clients require the operation of their website in English and the language spoken in their country. Some of our clients run multilingual websites ??(eg is available in 14 languages). Drupal 7 supports multilingual websites much better than Joomla or WordPress, but requires installing and configuring over 15 additional modules. In some extreme cases full support requires a programmer’s intervention, so it is not fully manageable by the non-technical administrator.

Multilingual support is embedded in the core of Drupal 8 requiring the activation of only 4 modules. Drupal can now be installed and operated in the administrator’s native language from start to finish. Gábor Hojtsy, heading a large team of contributors for this pillar, did an excellent job solving dozens of issues on Drupal 7, and transforming Drupal 8 into the most comprehensive platform available for developing multilingual websites and open-source-code applications!

Views in Core

For many, the views module is the basic reason for choosing Drupal. It allows displaying data to the user, without them having to write SQL queries. In Drupal 8 the Views module is conveniently embedded in Core. You can start building your website without having to install an additional module offering stability, full integration and interoperability. Furthermore, all administration screens are now Views, allowing the administrator to change fields and their appearance with just a few clicks.

WYSIWYG and Inline Edit

Drupal 8 Inline Edit

Content editing in Drupal 7 hasn’t been the best experience for the administrator. WordPress is still the leader in convenience and usability in this area. At Netstudio we have been installing dozens of modules in order to provide our customers with an environment almost as friendly as that of WordPress. Drupal 8 is a huge step in that direction. Its basic installation offers the content manager enhanced usability in a much friendlier environment (in fact, Netstudio has contributed some usability tests via The new release features a configured built-in WYSIWYG editor, as well as the impressive cutting-edge Inline Edit, making quick content interventions piece-of-cake for the front-end administrator.

Anything left for the next Drupal 8 (maybe 8.1) release? Well, yes. Media administration (photos, videos etc.). Although there have been improvements, additional modules need to be installed for a comprehensive solution, as is the case of the recently released Entity Embed and Entity Browser.

Mobile friendly

Now that the mobile web is a reality, it all seems so matter-of-fact. In 2011 however, at the onset of the Drupal 7 era, all we knew about the mobile web was forecasts. Fortunately, Dries Buytaert took these forecasts seriously, so he set the requirements for Drupal 8 aiming at its full compatibility with mobile devices. And his efforts were not in vain. The environment all around Drupal 8 is not only responsive, but also very easy for mobile and tablet users, even regarding contextual links, the admin menu and inline editing. The bottom line is that any administrator can manage their website comfortably commuting on a bus seat, on their bed or enjoying the sunshine on the beach!

Performance & Scalability

A platform’s performance and its ability to juggle sudden spikes of traffic have been major concerns of ours, partly explaining why we migrated to Drupal 7. Initially, Drupal 8 was much slower than Drupal 7, as shown in a comparative analysis we published two years ago. The obvious reason of course was that it was still under development and lacking the necessary speed optimization. This now has been changed. About a month ago, internal cache was set to on by default. We’re talking about a much smarter cache than that in Drupal 7. Speed racing is in progress, with developer Wim Leers in the lead. Here we expect dramatic improvements and capabilities once "SmartCache" and "PigPipe", Facebook-style page loading have been embedded in the core.

Configuration Management

I have a crush on this one, can’t wait for it, as it solves the issue of maintaining the site configuration under version control. In Drupal 7 website configuration and content were stored in the database, sometimes in the same tables, making their management almost impossible. We have repeatedly tried to resolve this issue using features, strongarm etc, but have given up as these solutions were too time-consuming and costly. We’ve been going out of our way creating scripts to control functionality, and checking over 300 points regarding security, performance, SEO etc. before delivering a website to our client. Still, this may not be considered a comprehensive solution. In Drupal 8 configuration is stored in YML files. That makes version control management, and data transfer from website to website or from environment to environment (e.g. development > staging > testing > live) a breeze.

Next Releases

Another important change in Drupal 8 is the rate of publication of new releases. In Drupal 7 subsequent releases (7.01, 7.02, and the most recent one, 7.37) focused exclusively on fixing bugs and security issues During these last four and a half years only few features have been added, in accordance to the backward compatibility policy. This is changed in Drupal 8. Versions 8.1, 8.2, etc. will not comprise of "minor updates", but will add new functionality. What it boils down to is that from now on, Drupal will be integrating technology innovation much faster.

More Novelties

Over and above the most important new features mentioned above, Drupal 8 comes with many more innovations like fieldable blocks, a greater range of integrated field types (date, entity reference, phone, email, link), the tour module, embedded output, enhanced accessibility, content publishing preview, friendlier front-end development, and more. What’s your main reason you can’t wait for Drupal 8?
Leave your comment below.

When will it be ready?

DrupalCon Los Angeles, with dozens of developers racing in Coding Sprints for the completion of Drupal 8, is now over. Only 20 critical issues (tasks and bugs) were left unsolved!

Teh RC (Release Candidate) version will be released once the last of these issues will have been resolved. The final version of Drupal 8 will be released 15 days after critical tasks and critical bugs have been brought down to zero. This is likely to take less than six months, but we’ll need to wait for another few months before we see the top contributed modules upgraded to Drupal 8. Knowing us, however, I’m sure we’ll start developing some simple presentation websites on the release of the almost final version. However, we’ll have to wait for 3-6 extra months before we can use Drupal 8 in more demanding installations. Meanwhile, we can all keep an eye on the top 100 contributed modules and their Drupal 8 updating status at:

We can’t wait for Drupal 8. Can you?

Now you know our reasons of impatience to start working on Drupal 8. What about your reasons? Do you plan on using Drupal 8? Have you used it already? What do you like most about it? Write your comment here.

May 25 2015
May 25

I was working on a big website with many contrib and custom modules. And I had to debug a very annoying redirect that started happening sometime in the recent past, not sure when. Some pages simply just redirected to other URLs.

I figured out that the problem was one of a 301 redirect. My browser told me that at least. But good luck figuring out where in the code I can find the culprit. Xdebug breakpoints everywhere but to no avail. A search for drupal_goto in the custom modules directory didn't help either, and God be with anyone trying to search through a contrib folder of that size.

Then it hit me. Isn't there a hook invoked inside drupal_goto? At this point I was assuming (and hoping really) that the redirect was happening somehow with a drupal_goto. And it turns out there is one: hook_drupal_goto_alter.

Armed with a new dose of hope, I implemented the hook and cleared the cache. Inside, I added the obligatory $test = ''; statement and put a breakpoint on it. Let's see what happens. After loading one of the offending pages, the breakpoint halted the execution and the Xdebug call stack in my PHPStorm immediately pointed out the problem: Global Redirect. There was some URL rewriting happening on the site so GR got a bit confused and was redirecting back to the original path. The details of the issue are however not important.

My point is that using this hook, I could see exactly who and why was calling drupal_goto. I didn't use it for anything else, apart from learning why the redirect is happening which in turn allowed me to write some code that prevented that.

Awesome. I learned about a new hook. And maybe now you as well.

May 24 2015
May 24

When preparing an email newsletter, one part of it that is time consuming is gathering together all the content that is needed. In my experience, virtually all the content already exists elsewhere, such as in the local CMS, in CiviCRM, or on a blog, or some other online source.    So I was thinking how can I make this process easier.  What I did: I created mail merge tokens for CiviCRM that autofill a list of recent blog posts, stories, or any other type of CMS content.  So the end-user sees a list of tokens, one for each content type, each term/category, each aggregator feed,  and for each date range. Such as "Content of type 'blog' created in the last 7 days" .  What is particulary powerful about this approach, is that if you are also using a CMS aggregator (such as the aggregator module in Drupal core) then virually any external RSS feed is turned into CMS content, which is now available as a CiviCRM token. (The original blog post about this extension is at: )

Thanks to community involvement (specifically thanks to, there is a new version of the Content Token extension.  This version now supports Joomla, in addition to Drupal7, Drupal6, and WordPress.

The lastest version is 2.9 and can be downloaded from:

If you like this extension, you will also likely enjoy my other extension: the "Fancy Token" extension which provides tokens for upcoming events, contribution pages, profiles, and WebForms. 

I am looking forward to getting feedback on this.

May 23 2015
May 23

I plan on doing a more in depth article on how I've been using Panels instead of templates or contexts for laying out this Drupal 7 site, but I feel like I still have more to learn.  Until then, I wanted to share what I found to be a missing piece of the puzzle, Page Manager Existing Pages.

PMEP allows you to override any page that is in the admin menu for use in Page Manager.  That way, you can create variants, and add whatever layout, content, selection rules, that you want.  Without this plugin, you get an error message in Page Manager when trying to overwrite an existing URL.

So, where would I use this?  Page Manager comes with defaults for Node, Taxonomy, and some User pages, most of what you need to present your site to the world.  But there are certain administration pages, when viewed in a front end theme that slipped through the cracks.  For example, node/add, which lists all the content types you can add, or the Style Guide Module generated /admin/appearance/styleguide

Install and configure Page Manager Existing Pages

May 22 2015
May 22

In this guest post, Luke Herrington shares his experience with integrating an existing Drupal backend with a Backbone.Marionette Todo app.

If you're reading this, you probably already know about all of the great work that Gizra has done in the Drupal/REST space. If you haven't, I highly recommend you check out their github repo. Also see the RESTful module.

One of the projects that Amitai has contributed is Todo Restful. It shows an Angular implementation of the canonical TodoMVC Javascript app connecting to a headless Drupal backend. It's a great demonstration of how easy exposing Drupal content with the RESTful module is. It also shows that when a RESTful API adheres to best practices, connecting it with clients that follow the same best practices is like a nice handshake.

I saw the Todo Restful project and it got me thinking, "If Amitai did this right (hint: he did), then I should be able to get this working with Backbone pretty easily". I was pleasantly surprised!

View demo Get the source code

Todo app with a Drupal backend

Here's a simplified list of everything I had to do to get it working:

  1. Fork the repo
  2. Delete everything in the client/app directory. (the Angular TodoMVC stuff)
  3. Put Backbone.Marionette implementation of TodoMVC into client/app directory.
  4. Change the API endpoint in the Backbone code Override parse functions on Todo model/collection to dig into the data portion of the response from Drupal. This was necessary because Backbone expects the response for a collection to be an array of models. The RESTful module sends back other data so it places the models inside an array named data. All I had to do is tell Backbone where to look.
  5. Edit Grunt file to work with the new app code. This was the hardest part because it was specific to the Angular app.
  6. Test, Commit, Deploy. Amitai setup a Grunt task to deploy the client side code to a github project page

Note: There are detailed instructions on how to get the app running locally on in the repo readme.

Notice I didn't have to touch any code on the Drupal side. Amitai's amazing installation script spun up the Drupal site for me with todo content type created and exposed with RESTful. It just worked. In fact the Backbone.Marionette demo app points to the same backend as the Angular app!

Also notice, except for steps 4 and 5 I didn't have to touch the Backbone code!

Now imagine applying this to your project... If your requirements demand a lot of interactivity and slick UI elements, go for it! You don't even have to go fully headless if you don't want to! See the RESTful module documentation on how to expose your content and start innovating. The possibilities are endless!


Amitai and Josh Koenig (Pantheon), in their talk at DrupalCon LA, spoke about Headless Drupal and showed how Drupal can still be relevant in an age where client side frameworks (Angular, Ember, React, Backbone…) rule. It made me excited about Drupal again and showed a whole new way that Drupal can further "Get off the island" and start to play nicely with other technologies.

In the end, that's why I went through this exercise: To show that Drupal is a viable CMS backend for not just Angular, but also Backbone.Marionette or any other front end framework for that matter! There's a ton of front-end developers out there that don't know what Drupal is capable of. I hope that by showing how easy this was, front-end devs can see that Drupal is more relevant than ever and that it makes their life really easy. I also did this to show current Drupal devs that with Headless Drupal we can imagine displaying and interacting with our content in ways we never have before.

So who's next? React? Ember?

May 22 2015
May 22

Last week, many of us were in sunny Los Angeles for DrupalCon 2015. Though many were seasoned veterans, it was my first time at a Con. It was a whirlwind of team building, a magical Prenote, great one-on-one coversations and plenty of Drupal talk. Needless to say, I'm still recovering! But one thing is certain, our team had a wonderful time. Here are some of their takeaways:

Mario Hernandez

Mario Hernandez - Front-end DeveloperHaving DrupalCon in my hometown of Los Angeles was great because I could enjoy the conference, meet with my friends and go home every night to my wife and kids.

I attended several sessions mostly front-end related but the biggest event for me was being able to speak at DrupalCon for the first time.  The topic was Advanced Layouts with Flexbox.

I have to admit I was concerned because my talk was scheduled as one of the last sessions of the conference right along with my colleagues Matt Davis and Jason Smith who would be talking about the front-end framework they put together for The Weather Channel.  Not to mention it was also at the same time as Dries’ Q&A session.  I was certain there will be no audience in my session.  
The time came for me to speak and I was shocked when I realized the room was almost full.  I estimated a minimum of 150 attendants in my session which completely surprised me.  I thought the presentation went well and the feedback I received was positive.  I walked out the room singing in the back of my mind the words of Ice Cube “Today was a good day!”.

Mark Casias

I had a great time in LA with all my favorite, and newly favorite Drupalists. I decided to take the twelve hour drive from Albuquerque to LA (and back) and that wasn’t as horrible an idea as I thought it would be. This was also my first ‘con with an actual supporting company, so it was fun to see the other side. Talking to people at the booth, and playing corn hole at the Mediacurrent booth was a blast. Additionally it was a lot of fun hosting the karaoke machine at the Mediacurrent after party. I would be a jerk if I didn’t thank the fine Canadians at Digital Echinda, where I won the nifty Drupal Hockey Jersey, and at Opin who is also from Canada, and gave me a TV! Of course the reason that we go there is the learning. My most memorable session was given by David Diers at Four Kitchens. His session was API Design: The Musical, which was a great primer on how to create a good program API along with his guitar and some pretty catchy, original songs. I truly hope he gets that album to drop

Bob Kepford

This is the second DrupalCon I've attended in my home state. As usually my favorite part of DrupalCon was meeting and reconnecting with people. My favorite session this year was 
Decoupled Drupal: When, Why, And How with Amitai Burstein and Josh Koenig. These two teamed up to talk about Decoupled Drupal. They offered reasons why a decoupled approach is a good idea but also why it is not a panacea. When you take Drupal's head off you lose a lot that Drupal does well. Josh mentioned several times that the Drupal has the opportunity to become one of the best backends for the hot frontend frameworks like Angular and Ember. They raised a rallying cry to Drupal developers to solve the problems that decoupled Drupal creates. Mark, Jason, Mario, and I also recorded a live episode of our podcast which was a lot of fun.


Damien McKenna

Having missed the past two Drupalcons, it was great to be back. My week focused around all things Panels, with a dash of Metatag and usability for good measure. On Tuesday I lead a panel session providing a State Of The Union update for all things Panels-related. My fellow Panels-ists and I demonstrated the latest 'n greatest in the Panels world, concluding with a brief preview of things to come in Drupal 8. Later that day we had a BOF where we had a round-table discussion of how to use Panels modules and some of the pain-points ("pane-points"?) site builders experienced. On Wednesday there was a BOF on Panopoly, a customized distribution based upon many Panels modules. We rounded off the week with a code sprint focusing on stability improvements. The best part of this was getting so many maintainers and active users together to discuss our goals, pain points and how to collaborate further. It was also great to catch up with friends I'd not seen in several years and finally meeting many others I'd gotten to know via and Twitter.

Nathan James

I have heard that it almost never rains in LA. Well, during my first DrupalCon, it absolutely rained!  Besides the water falling from the sky, it rained t-shirts, nerf guns, inspiring and informative sessions, great interactions with coworkers and the Drupal community, musical numbers, after parties, and valuable knowledge and ideas.  Being newer than most to the community, I found it empowering in the Driesnote to get a history of Drupal and a better vision of the impact this technology currently has and where it is going.  Seeing Mediacurrent give some sessions made me proud to be a part of this company.  I also appreciated the honest evaluation of Decoupled Drupal.  Going in expecting more hype talk, it was good to see Josh koenig and Amitai Burstein give a reality check, highlighting that there are many things in Drupal that we take for granted and would need to be rebuilt when using the Drupal backend with a different frontend.  Lastly, it would be simply wrong not to mention how Mediacurrent gave the most amazing after party.  Standing room only, in the loud roar of conversation and fun, you could just feel community growing and memories being made as good beer flowed and karaoke … happened.


Plugging into the Drupal community is a wonderful thing. Though we've wrapped up in Los Angeles, we're already gearing up for DrupalCon New Orleans! Will you be there? Laissez le bon temps rouler!

May 22 2015
May 22

Commercial Progression presents Hooked on Drupal, “Episode 9: DrupalCon LA 2015 Highlights with Steve Burge from OSTraining".  In this special DrupalCon edition of Hooked on Drupal we conferenced in Steve Burge of OSTraining for an on the ground report from Los Angeles.  Held on May 11-15, 2015 DrupalCon LA was the premiere event for the Drupal community.  Steve brings us the inside scoop of highlights and takeaways as the conference wraps up.  Additionally, Alex Fisher (also a DrupalCon veteran) shares his memories and insights from past DrupalCons.  Commercial Progression has recently sponsored OSTraining with a $5000 kickstarter backing to bring Drupal 8 upgrade training to the masses.  This new collection of video resources will be released in September 2015.  With Dries call to support Drupal as public utility from DrupalCon, this announcement seems especially timely.

Hooked on Drupal is available for RSS syndication here at the Commercial Progression site. Additionally, each episode is available to watch online via our YouTube channel, within the iTunes store, on SoundCloud, and now via Stitcher.

If you would like to participate as a guest or contributor, please email us at

[email protected]


Content Links and Related Information

OSTraining logo


Hooked on Drupal Content Team

ALEX FISHER - Founder of Commercial Progression

STEVE BURGE - Founder of OSTraining

Alex Fisher Steve

Left, Alex Fisher, founder and owner of Commercial Progression in Northville, Mich.
Right, Steve Burge of Sarasota, Fla., founder and CEO of OSTraining

Podcast Subscription

Hooked on Drupal Episode 9 - DrupalCon 2015 Review with Steve Burge of OSTraining Podcast

May 22 2015
May 22
 * Implements hook_action_info().

function mymodule_action_info() {
  return array(
    'mymodule_update_products' => array(
      'type' => 'entity',
      'label' => t('Update products by 2%'),
      'configurable' => FALSE, 
      'triggers' => array('any'),
      'pass rows' => TRUE,
function mymodule_update_products(&$entity, $context) { 
  $product_id = $entity->product_id; 
  $price = $entity->commerce_price[LANGUAGE_NONE][0]['amount'];
  $updated_price = 1.02 * $price;
  $affected_rows = db_update('field_data_commerce_price')
    ->fields(array('commerce_price_amount' => $updated_price))
    ->condition('entity_id', $product_id)
function mymodule_round_up_line_item_price($line_item_id) {
  $line_item = commerce_line_item_load($line_item_id);
  return round($line_item->commerce_unit_price[LANGUAGE_NONE][0]['amount'],-2);
May 22 2015
May 22

The Drupal 8 multilingual team is really great in spreading know-how on the new things in the upcoming version, so we had our session (1h) and workshop (2h) recordings published and widely available. While we of course love our baby and can talk all day about it, who has hours when they just want to explore what is coming up? We just addressed that this week with the following.

1. New 2m22s introduction video with the key benefits

[embedded content]

2. A quick summary of key benefits and an easy to skim features list lists the top 12 benefits and provides the more detailed information in an easy to skim text form. And yeah, that 1h session video if you have the time.

3. Easy to launch demo to try features out

Thanks to our work on the multilingual workshops for DrupalCons, BADCamp and DrupalCamps, we have a demo with sample content in 4 languages that you can try out in your browser for 30 minutes without any registration or local software install required thanks to

4. Check out who voted with their feet already

Drupal 8 is not yet released, yet there are numerous live multilingual Drupal 8 sites helping with nature preservation, finding health professionals or concert tickets among other good uses. Now there is a handy list to review at

If you like what you see, we still have guided workshops (those that last 2h). The next one is coming up right this Sunday at DrupalCamp Spain. We also believe that the multilingual team is one of the best to get involved with if you want to know Drupal 8 better and give back some to improve the new version as well. We have weekly meetings and a huge sprint coming up at DrupalCon Barcelona. Maybe we'll have some opportunity to celebrate as well. See you there!

May 22 2015
May 22

Years ago now, the Drupal community adopted Git as a version control system to replace CVS. That move has helped development since the distributed nature of Git allows better tracking of work privately before uploading a patch to

Sandbox repositories allow contributors to clone an existing project to work on independently (therefore not needing permissions for the canonical repository), but there is currently no way that I know of to request that those changes are pulled back, facilitate a review of changes and then merge the changes in (a pull request).

Hopefully that functionality is on the way!

But as a community the challenge is not just the development on, collaboration with GitHub, or whatever form the technical change takes. Alongside those changes, we need the workflows that will help us better manage multiple versions, allow fast bug fixes whilst features are being tested, and provide for reviews without alienating developers. And the technical element goes hand in hand with the workflow.

As an example, for the Drupal PM module, we recently debated how to set up Git branches to allow more flexibility than the traditional "single line of code" inheritted from CVS.

There were a few criteria that the new solution had to have:

  • Flexibility that allowed bug fixes to be more quickly applied to a release: Under the "single line of code" approach, Releasing bug fixes only would require adhoc branches and tags.
  • Fit with infrasturcture: In particular, we'd like users to be able to test a development version without cloning from Git. So the development release on needed to correspond to an appropriate codeset for people to test.
  • Alignment to industry standard approaches where possible: Looking into what is used elsewhere in the software world, the Gitflow model has been received well.

Putting all of this together and discussing on Skype and a issue, we came up with a branching model that seems to fit these criteria.

For each major version of the module (i.e., 7.x-1.x, 7.x-2.x, 8.x-1.x), we will have the following branches:

  • Release branches: There will be one release branch for each major version, named after the version (for example: "7.x-1.x"). The codebase in here will always be the release candidate for the next point release, and those point releases will always be tagged from this release branch.
  • Development branches: There will be one development branch for each major version, named "develop-[version]" (for example: "7.x-1.x"). This will effectively be a staging branch for the next release but one. Features will be merged into here, and then this development branch will be merged into the release branch when the next release candidate is required.
  • Feature branches: There will be one feature branch for each feature ( issue), named "feature-[issue]-[title]" (for example, "feature-12345-add-feature"). These will be worked on until the given feature is finished. Once completed, the feature branch is merged into the development branch.
  • Hotfix branches: There will be one hotfix branch for each bug fix ( issue), named "hotfix-[issue]-[title]" (for example, "hotfix-12345-fix-bug"). These will be worked on until the bug is confirmed fixed. Once completed, the hotfix branch is merged into both the development and release branches.

We're just beginning to use this system in entirety, and I hope that it works out.

One caveat is that the system only works for developers with permissions on the project repository. I would love for any contributor to be able to fit into this model and to have the pull request system available for the final merge... perhaps soon...

May 22 2015
May 22

If you're building a Drupal website with a lot of content for a community of users, chances are you'll need to set up some editorial controls. Starting with the Workbench and Workbench Moderation modules, you can create editorial workflows for content types. Nodes pass through different 'States', like Draft, Needs Review, and Published. Different User Roles control the flow of nodes through these different states. For example, you could create a Contributor role, who has permission to create new nodes and promote them to the Needs Review state. Content in the Needs Review state isn't published, so you could also create an Editor role, who can then promote nodes in the Needs Review state to Published, or reject nodes in the Needs Review state by setting them back to Draft. Drupal has fairly extensive documentation on working with Workbench and how to set up Moderation. 

Workbench Moderation works very well for high-level editorial controls, but if you need more granular control of your content, you should check out the Workbench Access module. For this example, we are going to enforce content moderation where only certain users can edit or moderate changes to Membership pages while other users can edit or moderate changes to Career pages. I like working with examples and screenshots (videos and screenshares make my eyes glaze over) so here is the basic setup.

We have three Content Types that we want to moderate with Workbench:

  1. Webinars: custom content type with date, time, and location.
  2. Internships: custom content type with dates, location, and description.
  3. Pages: Drupal's page content type out-of-the-box. This website has hundreds of pages, divided into many sections. For simplicity's sake, we'll just sat there are three sections: Membership, Careers, and Professional Interests.

We have three levels of access on this site:

  1. Administrators: can pretty much do anything and everything, and can publish any new content or edits to existing content without asking anyone’s permission.
  2. Content Editors: are in charge of moderating content. They are the ones who have the final say in terms of approving new content for publication, as well as approving new edits to existing content for publication. In Workbench-ese, editors can promote nodes in the 'Needs Review' state to 'Published' or reject nodes in the 'Needs Review' state by setting them back to 'Draft'.
  3. Content Contributors: can edit content, but need their edits to be approved by editors before they are published. In Workbench-ese, contributors can only create new 'Drafts' and then submit them for review by editors by promoting nodes to the 'Needs Review' state. 

These three levels of access work well for specialized content types (for example, Webinars and Internships) where we can set permissions and editorial controls globally on a content-type basis. All contributors can create new Webinars and edit all Webinars, and all editors can approve Webinars for publication. This system breaks down for the page nodes. We need a way to differentiate the editorial controls of the pages in the Membership section from the pages in the Careers section and the Professional Interests section. This isn’t something Workbench Moderation does out of the box, so we will need to add Workbench Access for this granular control of the different sections.

I'm going to skip the Workbench Moderation setup, as this was pretty straightforward and is covered already pretty well in the Drupal documentation. 

The setup assumes the following:

  • You have downloaded and enabled Workbench, Workbench Moderation, and Workbench Access.
  • You have already configured workbench (admin/config/workbench/moderation) in terms of the states (draft, needs review, published) you need.
  • You have set up permissions correctly for Workbench Moderation so the correct roles can edit and approve different content types for publication.
  • You have made sure that any content type you want to moderate with Workbench has been set up correctly (admin/structure/types/manage/[content-type). Make sure to select the Enforce Workbench Access control option.

workbench access

OK, now on to getting Workbench Access configured. 

Set permissions

Contributors need to be able to be assigned to sections and view access information. Editors need to be able to administer all settings for Workbench Access while Contributors need to be able to access Workbench Access sections. 

workbench access permissions

Also, confirm contributors and editors have necessary page node permissions - we want Editors and Contributors to be able to edit any page node. Workbench Access will then add the most granular control of which pages (Membership vs Careers) they can edit. 

workbench access node permissions

Editorial Section Taxonomy

Set up the Taxonomy you will be using for enforcing editorial controls. Workbench Access can use either Menus or Taxonomies for editorial sections, but to me a taxonomy seems more straightforward. This taxonomy isn’t used for tagging content, so doesn’t need to be assigned to any content type. You will be associating the taxonomy with the desired content types in Workbench Access. For this example, I have created an 'Editorial Sections' taxonomy with 2 terms, Membership and Careers.

Configure Workbench Access settings.

This is the first thing we'll do at  admin/config/workbench/access/settings. In this case, we’ll be using our newly created Editorial Sections Taxonomy on Page nodes.

workbench access settings

Add roles and users to the Editorial Sections

When adding roles or users to different Editorial sections, it’s important to realize that we are just assigning users to these sections - what the users can do in these sections (edit, approve edits for publication etc) is still controlled by Workbench Moderation and permissions. We’re adding a layer on top of the content moderation provided by Workbench Moderation. Add the administrator roles to all sections at /admin/config/workbench/access/roles - adding it to the whole taxonomy will then add it to all terms within this taxonomy. Click on the '0 roles' and then add all administrators and save. Back on the Roles tab you can now see one role has been assigned to all Editorial Sections.

Now we want to individually assign users to be able to edit or moderate pages in different editorial sections of the website. For demonstration purposes, I’ve created 4 users - Member Editor, Member Contributor, Career Editor, and Career Contributor. Here is how we're going to use Workbench Access:

  • Member Editor and Career Editors are both Content Editors, so can promote nodes in 'Needs Review' to 'Published.  
  • Member Contributor and Career Contributor are both Content Contributors, so can create new nodes and submit the for review. 
  • Member Editor and Member Contributor will only have rights to edit/moderate pages in the Members section
  • Career Editor and Career Contributor will only have rights to edit/moderate pages in the Careers section.

Click on the Editors tab, and then the 0 roles link next to the Membership section. Add the users in the auto-complete field and then hit save. Don't get confused by Workbench Access' terminology - when it says 'Editors' that is just the individual users who will be able to edit or moderate a section. It has no relationship with the Editors and role we have set up previously. 

workbench access add editors

Do the same for Editors of the Careers section, and you'll see now that 2 editors are assigned to each of these sections. 

workbench access editors

Add pages to sections

Now that we’ve got our Editorial sections set up and users and roles assigned to these sections, we need to add pages to these sections. Remember, we only set up the Taxonomy that will be used to divide the pages into different Editorial sections. We haven’t assigned pages to these sections yet. We can see this if we go to any of the pages on the site - they still say Editorial Section: Unassigned

There are two ways to assign pages to Editorial sections. You can edit the individual node, and select your Editorial Section in the new field that Workbench Access has added, or you can do a batch update through the Content Overview page at admin/content. After you've done that, now if you view one of the node you have updated, it should have the Workbench Access section assigned:

Confirm it's working

To make sure the controls are working the way you want, try logging in as the different editor and contributor users. You will see that the Career Editor/Contributors can only edit and moderate any nodes you have assigned to the Career section, and only the Membership Editor/Contributor users can only edit and moderate node assigned to the Membership section. 

Important note: until pages have been assigned to an Editorial Section, Workbench Access isn’t being enforced. So, if we view a page node as the Member Contributor and it says ‘Editorial Section: Unassigned’ we will be able to edit that page

Another important note: If you want to take this another step and integrate Workbench Access with rules, you will need to apply this patch (see issue This patch will then give you the ability to set conditions using Workbench Access. 

May 22 2015
May 22

Earlier this week Matt Mullenweg, founder and CEO of Automattic, parent company of, announced the acquisition of WooCommerce. This is a very interesting move that I think cements the SMB/enterprise positioning between WordPress and Drupal.

As Matt points out a huge percentage of the digital experiences on the web are now powered by open source solutions: WordPress, Joomla and Drupal. Yet one question the acquisition may evoke is: "How will open source platforms drive ecommerce innovation in the future?".

Larger retailers with complex requirements usually rely on bespoke commerce engines or built their online stores on solutions such as Demandware, Hybris and Magento. Small businesses access essential functions such as secure transaction processing, product information management, shipping and tax calculations, and PCI compliance from third-party solutions such as Shopify, Amazon's merchant services and increasingly, solutions from Squarespace and Wix.

I believe the WooCommerce acquisition by Automattic puts WordPress in a better position to compete against the slickly marketed offerings from Squarespace and Wix, and defend WordPress's popular position among small businesses. WooCommerce brings to WordPress a commerce toolkit with essential functions such as payments processing, inventory management, cart checkout and tax calculations.

Drupal has a rich library of commerce solutions ranging from Drupal Commerce -- a library of modules offered by Commerce Guys -- to connectors offered by Acquia for Demandware and other ecommerce engines. Brands such as LUSH Cosmetics handle all of their ecommerce operations with Drupal, others, such as Puma, use a Drupal-Demandware integration to combine the best elements of content and commerce to deliver stunning shopping experiences that break down the old division between brand marketing experiences and the shopping process. Companies such as Tesla Motors have created their own custom commerce engine and rely on Drupal to deliver the front-end customer experience across multiple digital channels from traditional websites to mobile devices, in-store kiosks and more.

To me, this further accentuates the division of the CMS market with WordPress dominating the small business segment and Drupal further solidifying its position with larger organizations with more complex requirements. I'm looking forward to seeing what the next few years will bring for the open source commerce world, and I'd love to hear your opinion in the comments.

May 22 2015
May 22

If you’re anything like me, right now you’re thinking: Finally! It’s a very exciting moment for those in our field who have craved ways to collaborate, learn from experiences and refine our craft. The Drupalcon team has heard our request loud and clear, and we can now enjoy the very first Project Management Track!

What makes this awesome news

We can finally dedicate these sessions to Project Management in its own right, instead of treating it like it’s some sort of sales or business solution that needs to be sold. Those of us in the field know this universal truth: it’s about delivery, not just sales!

Who should submit and who should attend

We want seasoned professionals to submit sessions, but anyone is welcome to attend. Sessions will assume some PM knowledge is already acquired by the audience. We only get 7 sessions, so we want to make them count!

Timeline reminder

- Submit by 8 June midnight CEST

- Selection from 8-20 June

- Sessions announced 28 June 

Do this to get your session picked

Don’t submit general project management sessions. Let’s get into the nitty-gritty. Keep the emphasis off business (eg: how to sell your estimate), and more on practice (eg: how to make your estimate). Workshops would be great for this kind of content! Do propose sessions that solve real PM problems, explore new concepts, and challenge our preconceived notions. We want the good stuff; the advice and tips that come from years of experience, and many projects under the belt. Propose a variety of content formats into the selected sessions, from workshops that focus on teaching, to case studies to panels and your more “classic” presentations.

Let’s make it happen people

Share this post! We need to get the word out!
Submit a session! You have until Midnight CEST (that’s 6pm Eastern) on 8 June 
Share your ideas! What do you want to learn from sessions? Tell us in comments
RALLY! Let’s get so much great content we will have a dickens of a time choosing!


Bonus: Content Ideas for you!

Back in the day, I proposed a lot of session ideas and it helped generate content, so I’m repeating the experiment! I highly encourage you to steal them, tweak them, and reinvent them -  whatever you want! I hope to inspire you to share your hard-earned wisdom, check out the list at the end of this post.

Here are a few of my session ideas up for grabs:

  • Project estimation techniques
  • Project planning tips
  • Scope and Change management and handling tough conversations
  • Risk management tools, techniques and handling frequent project risks
  • Your experiences with different PM methodologies: what worked or didn’t?
  • Fixed bids pros, cons, good, bad, ugly, how to avoid them, how to use them to your advantage
  • Managing Portfolios: how to keep track and report on what matters
  • Leadership and coordination approaches
  • Pre-sales estimation: Benefits/Risks, Tips & techniques
  • PM Tools comparison: what’s the best one? why?
  • The shift: changing methodologies, issues and advice on implementing new processes
  • Handling difficult and demanding customers who don’t know the meaning of “out of scope”.
  • Priority management and backlog grooming tips/advice/tactics
  • Defining Done: techniques to make things clear
  • Lessons Learned, Post-Mortems and Retrospectives: learning from past mistakes & successes
  • Team cohesion: staying united & motivated during tough projects
  • Authority: how to wield it without being a jerk
  • The long project: how to manage big, long, projects and how they differ
  • The big nasty: worst project you ever had, and what you learned from it
  • Difficult team members: bringing up the quality of work on projects, and dealing with
  • Drupal Risk Management: Common Drupal project risks and how to mitigate them
  • Watergile for Drupal: Hybrid PM Tips and Techniques for Agile + Waterfall Projects
  • Drupal Resources: How to PM Volunteer Projects
  • Drupal Iterations: An agile process case study
  • Drupal Estimation Panel: Tips and Techniques for Estimating S/M/L projects
  • Drupal Estimation: Did you forget something? (things we should estimate, but often don't)
  • Before You Win: Project Estimation and Assessment
  • Drupal Assumptions: Common Assumptions that Kill Projects (and how to educate your clients)
  • Drupal Project Reporting: The Good and Bad News about Reporting Progress
  • When you’re wrong: handling project estimations & assumptions that went south bigtime.
  • Turning it around: bringing projects back on track when they are off the rails
  • Drupal Projects: Good, Bad & Ugly -- what do we love and hate about Drupal projects
  • Testing: assumptions, estimations and pitfalls of drupal testing
  • Managing different kinds of projects, do some techniques work better than others?
  • How to make estimators out of developers
  • OTOBOS: umm, does it really exist across an entire project? Has anyone ever delivered every single iteration on time on budget on scope?? If not, why is that?
  • Chaos report: top contributing factors to project failure and techniques to mitigate those risks on your drupal projects
  • Do you hate agile or some other methodology? Why? What would make it “better”?
  • Best project you ever ran case study: why was it good, what worked, what did you learn?
  • Bad PM: worst mistakes you can make.

So, let’s get cracking! Submit your sessions, spread the word and come join us in Barcelona!


Shannon Vettes
Project Management Track Chair
DrupalCon Barcelona

May 22 2015
May 22

DrupalCon LA

So I did not make it along to DrupalCon Los Angeles, but I did spend some time reading twitter, and watching the sessions online. Here are some of the sessions I found entertaining and insightful and would recommend to others.

Driesnote Keynote

Dries, as always, sets the lay of the land with Drupal. He also goes into the early days of Drupal, and how some key people he was involved with and have now gone on to form organisations that centre around Drupal.

Best quote:

Obstacles don’t block the path, they are the path

[embedded content]


Larry Garfield gives an interesting talk on why sometimes it is best to say NO in order to give focus to the things that actually matter.

Best quote:

Case and point, the new Macbook Airs, they say NO TO EVERYTHING.

[embedded content]

PHP Containers at Scale: 5K Containers per Server

David Strauss explains the history of web hosting, and how this is now far more complex. David is CTO of Pantheon, and they now run 100,000+ websites, all with dev + test + production environments. Pantheon run 150+ containers on a 30GB box (205MB each on average). Really interesting talk on how to run large amounts of sites efficiently.

[embedded content]

Decoupled Drupal: When, Why, and How

Amitai Burstein and Josh Koenig give a really entertaining presentation on monolithical architectures and some developer frustrations. And then introduce REST web services in Drupal 8, and how this can be used to provide better consumer interfaces for other frameworks.

[embedded content]

Features for Drupal 8

Mike Potter goes through what role features played in Drupal 7, and how features will adapt in Drupal 8 now that CMI is in. Features in Drupal 8 will be going back to it’s roots and provide ‘bundles’ of configuration for re-use.

[embedded content]

Meet Commerce 2.x

Ryan and Bojan go through 1.x on Drupal 7, and how they have chosen to develop Commerce 2.x on Drupal 8. This is a complete rewrite. The hierarchical product model is really exciting.

[embedded content]

How, When and Why to Patch a Module

Joshua Turton goes over what a patch is, when you should patch contributed modules, and how to keep track of these with Drush make.

[embedded content]

My colleague Josh also wrote a blog post on how to use Drush make.

CI for CSS: Creating a Visual Regression Testing Workflow

I topic that I am passionate about is visual regressions, here Kate Kligman goes through some tools that can help you test your site for visual changes. Tools covered include PhantomJS, SlimerJS, Selenium, Wraith.

[embedded content]

Speeding up Drupal 8 development using Drupal Console

Eduardo and Jesus give us an introduction to your new best friend in Drupal 8. Drupal console is a Symfony CLI application to help you write boilerplate code, e.g. to create a new module. Personally, I am excited for the form API generator, and the ability to create a new entity with a single command.

[embedded content]

For more information see

Q&A with Dries

As Drupal heads down from 130 critical issues down to 22 currently, what are some key concerns by people. The questions are answered by dries, xjm, webchick and alexpott.

[embedded content]

Where can I find more videos

Don’t worry there are plenty more videos on the Drupal Association Youtube page.

If you have any awesome sessions that I have missed let me know in the comments.

May 21 2015
May 21

There’s many dirty little secrets in Drupal 7 core’s API when it comes to inconsistencies and oversights. It’s a big part of why so much care is being placed in D8 and its taking so long, because people realize this is a platform that’s used for the long haul and core decisions today will have lasting impacts a decade from now.

That said, I discovered one a year or so ago and kept putting it off, hoping it would go away on its own. Well, it hasn’t and here comes a potential scenario that I detail in an ELMSLN issue queue thread I like to call Role-mageddon. While this doesn’t just affect distributions and install profiles and features, it is a lot more likely you could run into a problem there with them; and so here we go.

Example Scenario

Site 1 (Profile A)

  • Developer Adds a Feature X that adds 2 roles
  • Then creates Views, Rules, and blocks and associates roles to access / visibility
  • Then they create Feature Y with 1 role and do the same as before

Site 2 (Profile A + the additions above)

  • Developer Enables Feature Y
  • Developer Enables Feature X
  • All access / visibility criteria of Roles / functionality supplied in Y is flipped with X
  • Oh Sh….

So What happened?

Roles in drupal are stored as id, name, weight. id is generated based on the database being incremented, so anonymous is always user rid 1 and authenticated rid is always 2. After that, it’s the wild west of whoever comes first gets the next id.

Well, if Roles 1 and 2 are created then Role 3, they’ll get ids of 3,4,5.

If Role 3 is created then Roles 1 and 2, they’ll get ids of 3,4,5 but all views, rules, blocks, anything associated to the rid identifier is now associated with the wrong role!

Without this knowledge you could have oh, i don’t know, made all your admin blocks visible the ‘bosswhopays’ role on production and not understood why ). This would also happen if your in dev and have a role that doesn’t move up to production that was created prior to the others that are about to. You move the features up, and none of the settings are kept.

So how do we avoid Role-mageddon?

Role Export adds a column called machine_name to the role table, and then uses the machine_name value to generate a md5 hash value which is used to create the rid. Then, so long as machine_names are unique, it effectively gaurentees that rid’s are unique and won’t collide with other roles that you import / migrate.

The import / export order no longer matters because they’ll always map to

Great for the future, but what about my existing site?

Role Export had support for automatically remapping the updated rid so your users roles don’t get lost, as well as the admin role variable and the permissions associated to the role. That’s great, without those this would have been basically worthless for existing sites.

What my patch of infinite lack of sleep provides, is the same exact thing but for Views, Rules, Blocks, Masquerade settings (since that has security implications and is popular) as well as a hook that can be invoked to fix your other variables like IMCE, Piwik, and LTI.

May 21 2015
May 21

Mediacurrent Dropcast: Episode 5

Our first foray into public during Drupalcon Los Angeles. Bob, Jason and Mark are live interviewing anyone who showed up to our BOF (Birds of a Feather) and gave away fancy Weekly Drop T-shirts. We also talked about our favorite sessions in this years North American ‘Con. Special thanks to Benztown Radio for the use of their equipment.

Episode 3 Audio Download Link


Bob, Jason, Mario, Mark

Show Updates:

Show Links:

May 21 2015
May 21

Javascript code

Business is keenly aware of the importance of page-load time, and its impact on conversion and search engine optimization. It’s now a priority at companies like Wal-Mart, Amazon, and Mozilla.

At Acquia, we hear about it from virtually every customer. They all want to know how our platform and services can improve the performance of their websites. How much can we speed up the responsiveness of the digital experience they are offering their users and customers.

Performance is often considered to be primarily a back-end problem, but frankly what we find after we dig through back-end code: often poor front-end optimization is the culprit and not Drupal itself.

While internet users don't have a page-load value in mind — they’re not counting seconds — they do want their content now. A content owner’s fear is that with a finger hovering over the back button, a user's brain is doing an automatic cost-benefit analysis on whether the loading content is worth the wait. If the site is too slow, they are impatiently wondering if they can get what they’re looking for somewhere else, somewhere quicker.

Its important for business to understand the impact of design and feature-level decisions on performance, and the importance of balancing a sophisticated and elegant user experience with nimble performance. As Engagement Managers, Architects, and Developers, it’s up to us to inform stakeholders of the impacts of their choices, offer compromises where we can, and to implement in smart and responsible ways. Regardless of the heroic efforts we are asked to make at the code level, we should all be able to agree on this:

Faster Page Loads = Happier Users

This article kicks off a series about optimizing the requests made by a Drupal site after the DOM loads. The goal of the series is to give site and product owners a new set of tools to evaluate their internal performance and to provide architects and developers specific recommendations. Today we’ll tackle image handling. Subsequent posts will cover JavaScript and CSS optimization, Content Delivery Networks (CDN), semantic HTML and better content selection. We’ll start with image handling because it’s low-hanging fruit and a front end swing-and-miss we often see.

Our first post is divided in two: Theme Images, the images comprised in your design, and Content Images, the images chosen and uploaded by authors, editors, and producers.

In Theme Images we cover sprites: why you should use them, how we employ them at Acquia, and some resources to get you going. In Content Images we explore how to deliver high quality images, optimized using compression and size adjustments, and how we accomplish this at Acquia. Finally, we’ll link to some additional resources.


Your images need to be optimized. Full stop. Apply some lossy compression to that 50 image gallery. Dump all your theme images into one sprite file. Don’t serve a retina-quality image to an outdated smartphone. All of these impact page-load times, and we’ll touch on each one here.

Theme Images

We have the most control over theme images because the end users who create content on a site rarely need to manipulate them. Theme images don’t change much after the designer has created them. That makes them ideal for combining into CSS sprite files. A sprite works by combining all theme images into one file and using the x and y positioning values of the “background” CSS property to control which portion of the image is visible.

Sprites hold the advantage of existing in a singular file that is almost always smaller than the sum of its would-be piecemeal parts, plus it can be downloaded with a single HTTP request and cached for reuse. While nothing new, if you’re unfamiliar or need a refresher on sprites, CSS Tricks has a great introduction.

There are a lot of ways to create sprites, including manually in Photoshop. Various Ruby gems and Grunt/Gulp plugins make the process easier. Here at Acquia, we tend to rely on Compass to do the heavy lifting for our Professional Services builds. When creating sprites with Compass, you can use directories to group images that will form separate sprites. So, instead of creating one enormous sprite for all of my styles, I'll break them up into logically grouped images based on their use. These almost always end up being PNGs. When employing icons, I try to use a font-icon or an SVG icon if possible. And if you’re considering SVGs because they look great at different resolutions and screen sizes, you can sprite those too.

Content Images

Content images differ from theme images in that we as designers don’t have full control. We’re shackled to the whims of a writer or a content producer with a burning desire for that full-window 50-image slideshow. Nevertheless, we need to make sure those 50 images hit a sweet spot for size and compression. That means we’re applying an acceptable amount of lossy compression on our JPGs and sizing them to correspond with viewport size and device resolution.

We see a lot of designers and developers getting around responsive challenges by simply loading a larger image then necessary, not declaring dimensions on the image, and scaling the image using styles.

Instead, we should use our current best option, Drupal’s Picture Module. The picture module uses the (soon to be accepted) HTML5 picture element and is a backport of Drupal 8's Responsive Image module which is a part of core Drupal 8. For many, the current preferred solution is to use an image tag with “srcset” and, yes, I am aware of the ongoing conversation around Drupal 8 image handling. Presently, however, the picture element and a polyfill is Acquia’s go-to solution for responsive images. It uses the Breakpoints Module to load the correct image according to viewport size and pixel density, and adopts our defined image styles to create derivatives for different viewports.

This solution takes care of both image size and compression, doing the math to find that optimized sweet spot so you don’t have to.


Drupal can be a speedy back-end workhorse, but sloppy front-end implementations can quickly undo all your hard work. Employing the strategies I’ve outlined here can decrease your page-load times by a significant amount. Using sprites for theme images reduces the number of HTTP requests, and enables caching for future use. Drupal’s Picture Module takes the guesswork out of image delivery, optimizing with appropriate compression and size manipulation.

And this is just a start towards your faster Drupal website. In the next post in this series, I’ll show you how to optimize your javascript and cascading style sheets -- two more ways you can improve your site’s front end to create faster page loads, and happier customers.

May 21 2015
May 21

Drupal is an awesome tool for building sites! You imagine, you create and finally you publish your work online.

But, if you are asking yourself “What now? Is all the work finished?” , then this track is exactly what you were looking for.

Every site needs to be deployed, hosted, monitored, upgraded, scaled, security patched and maintained. DrupalCon Barcelona DevOps track can help you to achieve those goals and ensure the success of your site.

DevOps bridges the gap between the world of developers and operations.

Drupal development is well understood by the community - it is all about code. Writing code, implementing code, testing code, re-writing code… relax, have a drink, and do some more code.

Operations is all about looking after the systems that runs that code. Figuring out how much CPU, RAM and disk you will need to run your Drupal site, ensuring patch security, automated testing, scalability, etc - basically how to keep the site running and growing flawlessly.

In this track we want to expand these core concepts of DevOps for the Drupal community, and help both developers and operations achieve the long-lasting success of Drupal sites. If you want to share your experience submit your now.

Submit a Session


Ricardo Amaro
DevOps Track Chair
DrupalCon Barcelona

May 21 2015
May 21

In this article, we will create a basic view to display a Drupal calendar with events.

By the end of this article, you will be able to configure a basic Drupal event calendar for your website that looks like this:

Drupal Event Calendar

In order to get started, I want you to download and unzip the following modules to your Modules folder:

1.Drupal Calendar Module (

Drupal Calendar Module

2. Drupal Date Module (

Drupal Date Module

Enable the modules after you are done with the downloads.

Click “Modules” on the top-level menu:

Search and enable the following modules:

  • Calendar
  • Date
  • Date API
  • Date Popup
  • Date View

We assume you already have Views module downloaded and enabled.

Let’s now create a new content type to feature the events. I will be creating two events for June – World Environment Day and Father’s Day.

Click “Structure”:

Click “Content types”:

Click “Add content type”:

I am adding the new content type as “Events”. I have given “Title of Event” as the label. Click “Save and add fields”. View the screenshot below for more info:

Under Add new field, I have provided the value “Date of Event”. Under FIELD TYPE, I chose "Date" from the dropdrown. The WIDGET field gets automatically updated with the value “Pop-up calendar”. Click “Save”:

The next screen that comes up is the FIELD SETTINGS screen. Here are the important fields you will come across:

  • Date attributes to collect: It lets you choose the attributes you want highlighted in the Date field. I have kept the values as default.
  • Collect an end date: It allows you to provide an end date for an event. I ticked the box.
  • Time zone handling: Provide your time zone. I have gone with the default “Site’s time zone”.

Click “Save field settings”:

You won’t have to do anything in the new screen. Enter content for Help text if you wish to:

Scroll further below and click “Save settings”:

Notice the newly created “Title of Event” and “Date of Event”. Click “Save”:

Let’s now create the Events! Click "Content" on the top-level menu:

Click “Add content”:

Click “Events”:

In the new page, provide the title and details about your event. I have pasted from Wikipedia for this page:

Scroll below and you will be asked to fill in the timings for the event by using a pop-up calendar:

This is how the timings for the event looks like after details have been filled:

Click “Save” at the bottom of the page:

Your event for World Environment Day has been created:

Let’s create one more event:

Click “Save” and the page for Father’s Day shows up:

Let’s now configure the calendar to show these events. We can do this by creating a View that highlights the calendar.

Click “Structure”:

Click “Views”:

Click “Add view from template” to completely personalize your view:

You will be allowed to select a template based on a pre-configured value. In this case, Date.

In the new screen search for the newly created field created above – Date of event. Click “Add on the extreme right. Refer the screenshot below:

Click “Continue” to go to the next screen:

You will be taken to the following screen. It features basic configuration for your calendar. On the top-left, you will find several buttons – Month (default), Week, Day, Year, Block and Upcoming. Clicking them will take you to similar screens. I want you to click “Save” on the top-right:

Click “View Month” as shown below:

You will now be able to see the calendar with the events featured. Clicking on any event will take you to its respective page:

We have now completed the basic configuration to enable a Calendar view with events.

May 21 2015
May 21

The Drupalcon song - with actions!

I am never missing the #DrupalCon #prenote again. So brilliant.

— Kelley Curry (@BrightBold) May 12, 2015

DrupalCon always leaves me full of energy, and Amsterdam 2014 was no exception. The three of us – Adam Juran, me, and my wife Bryn – sat together on the short train ride back home to Cologne. Some chit chat and reminiscing quickly led to anticipation of the next DrupalCon, in LA. We were excited about the possibilities of this world-class host city. The home of Hollywood, Venice Beach, and Disneyland sounded like a great destination, but after three years of co-writing the DrupalCon “opening ceremony” with Jam and Robert, we were more excited about the possibilities for the Prenote. We knew we had to up the ante, make something new and different from previous years, and LA seemed like a gold mine of possibilities.

Every DrupalCon, before the keynote from Dries, this small group has staged a “pre-note.” The goal of the prenote is to break the ice, to remind everyone present that Drupal is a friendly, fun, and above all, inclusive community. It’s often themed after the host city: in Munich, Jam and Robert taught everyone how to pour a good Bavarian beer, and brought in a yodeling instructor for a singalong (yodel-along?) at the end. In Portland we held a “weirdest talent” competition, featuring prominent community members juggling and beat boxing. Every year it gets more fun, more engaging, and more entertaining for the audience.

Learning how to pour beer at the Drupalcon Munich prenote, 2012

Learning how to pour beer at the Drupalcon Munich prenote, 2012

On that train ride home, we threw around a lot of possibilities. Maybe the prenote could be set on a muscle beach, with Dries as the aspiring “98 pound weakling.” Or the whole thing could be a joke on a hollywood party. We briefly considered a reality-TV style “Real coders of Drupalcon” theme, but nobody wanted to sink that low. That’s when the idea struck: we could do it as a Disney musical!

Part of Your World

The Prenote was Jam and Robert’s baby, though. We knew that we would have to have some absolutely knock-down material to convince them of our concept. With beer in hand, the three of us started work on Part of your world from the Little Mermaid, as the client who is excited for the worst website idea ever.

“I’ve got sliders and icons a-plenty,
I’ve got OG with breadcrumbs galore.
You want five-level dropdowns?
I’ve got twenty!
But who cares? No big deal.
I want more!”

We quickly moved on to the song for the coder who would save the day, You ain’t never had a friend like me from Aladdin. We got halfway through this fun number before we realized that the song titles alone could do a lot of the convincing. Another beer, and we had a list of potential songs. There was so much material just in the song titles, we knew that the music would take center stage.

Some of our favorite titles from this first list were ultimately cut. Maybe someday we’ll flesh them into full songs for a Drupal party, but in the meantime you can let your imagination run wild. Hakuna Matata from The Lion King was to become We’ll Build it in Drupal! The Frozen parody, Do You Wanna Build a Website was a big hit, and so was Aladdin’s A Whole New Theme.

We showed our idea to Jam and Robert the first chance we got. They took one look at our list of songs and said the three words we wanted to hear: “run with it.”

You Ain’t Never had a Friend Like Me

Forum One's Adam Juran and Campbell Vertesi as

Forum One’s Adam Juran and Campbell Vertesi as “Themer” and “Coder” at the Drupalcon Austin prenote, 2014

We divided up responsibility for  the remainder of the songs and started to experiment with the script. What kind of story could we wrap around these crazy songs? How much time did we really have, and could we do all this music? We were all absorbed in our normal work, but every chance we got, the group of us would get together to throw ideas around. I don’t think I’ve ever laughed as much as while we wrote some of these songs.

Writing parody lyrics is entertaining on your own, but as a duo it’s a laugh riot.  More than once we checked the Drupal song lyrics project for inspiration. We riffed on ideas and tried different rhyme schemes until things seemed to just “fit.”

Heigh Ho, Heigh Ho

In the last few weeks leading up to DrupalCon, Adam and I met two and three times a week for long sessions, brainstorming new lyrics. We powered through writing the script around the whole thing, and started to address the logistical problems of backtracks, props, and costumes as well.

via Mendel at Drupalcon LA. Ronai Brumett as the perfect hipster Ariel

via Mendel at Drupalcon LA. Ronai Brumett as the perfect hipster Ariel

Finally we set about casting the different songs. Adam and I had always wanted to sing the Agony duet from Into the Woods, so that one was easy. We had a tentative list of who we wanted in the other songs, but we had no idea who would be willing. All of a sudden the whole endeavor looked tenuous again. Why did we think Dries would be OK to make a joke about Drupal 8 crashing all the time? Would Jeremy Thorson (maintainer of the test infrastructure on even be interested to get up on stage and sing about testing? We realized that we’d never heard these people sing karaoke, much less in front of thousands of people!

One by one we reached out to the performers and got their approval. Some of them were more enthusiastic than others. Dries replied with “OK, I trust you guys,” while Larry Garfield and Jeremy Thorson insisted on rewriting some of their lyrics and even adding verses! The day before the show, Larry was disappointed that we couldn’t find giant foam lobster claws for his version of Under the Sea from the Little Mermaid. Aaron Porter bought a genie costume and offered to douse himself in blue facepaint for his role, and Ronai Brumett spent a weekend building the perfect “hipster Ariel” costume.

When You Wish Upon a Star

On DrupalCon – Monday the day before the show – the cast assembled for the first time for their only rehearsal together. I arrived a few minutes late, direct from a costume shop on Hollywood Boulevard. Jam had built karaoke tracks on his laptop, and Robert had put together a prompter for the script, so the group huddled around the two laptops and tried to work through the whole show.

Via <a href=

Via Mendel at Drupalcon LA. The prenote cast rehearses. From left to right, Larry Garfield, Aaron Porter, Adam Juran, Jeffrey McGuire, Campbell Vertesi.

The rehearsal showed us what a hit we had created. The performers had embraced the motto: “if you can’t sing it, perform it” and they started to feed off each other’s energy. We all laughed at Ronai’s dramatic rendition of Part of My Site, and the Agony Duet raised the energy even further. It turned out that Dries had never heard When You Wish Upon a Star from Pinocchio before, but he was willing to learn as long as he could have someone to sing along with him!

via Mendel at Drupalcon LA. Aaron Porter codes with his butt - on Dries Buytaert's laptop!

via Mendel at Drupalcon LA. Aaron Porter codes with his butt – on Dries Buytaert’s laptop!

The rehearsal really started to hit it’s stride when Aaron delivered You Ain’t Never had a Dev Like Me. Aaron had never sung in public before, and we could tell he was nervous. Then the backtrack started playing with its blaring horns, and he came alive. It’s a difficult piece, with lots of fast moving text and a rhythm that can be hard to catch. Aaron launched into it with gusto. He had us in stitches when he shouted “can your friends do this!” and grabbed Dries’ laptop to start typing with his butt. When he nailed the high note at the end with a huge grin on his face, it was a deciding moment for the group.

From that moment on we were on a ride, and we knew it. Simpletest (to the tune of Be Our Guest from Beauty and the Beast) turned out to be a laugh riot, and Jeremy led us naturally into a kick line for the grand finale. We cheered Larry’s choreography skills during the dance break of RTBC, and Ben Finklea was a natural (as ever) at leading us all in Commit, to the tune of Heigh Ho from Snow White.

Forum One UX lead Kristina Bjoran, had protested the most of everyone about having to sing, but the moment she started with our version of Let it Go from Frozen, we were caught up in the feeling of it. I don’t think anyone expected the goosebumps that happened when we sang that chorus together, but we all appreciated what it meant.

Let it Go

The morning of the show saw the whole cast up bright and early. Though we joked about doing a round of shots before going on stage, no one seemed nervous. In fact we spent most of the setup time laughing at one another. Larry discovered that he has great legs for red tights. Aaron got blue face paint everywhere. We cheered at Jam and Robert’s Mickey and Minnie costumes, and laughed at Ronai’s perfect Hipster Ariel.

Some of us had last minute changes to make: Jeremy spent his time crafting oversized cuffs for his costume. I had forgotten the belt to my ninja outfit, so we made one out of duct tape. Kristina discovered that her Elsa costume limited her movement too much for the choreography she had planned. Dries was the only one who seemed nervous to me – this guy who has spoken in public countless times was afraid of a little Disney! We sang through the song together one last time, and it was time to go on.

via Mendel at Drupalcon LA. Jeremy Thorson leads the

via Mendel at Drupalcon LA. Jeremy Thorson leads the “Simpletest” song. Behind him, from left: Campbell Vertesi, Ronai Brumett, Adam Juran, Aaron Porter, Dries Buytaert

Everyone knows the rest – or at least, you can see it on youtube. What you probably don’t know is how hard we all laughed as we watched the show backstage. Even knowing every word, the energy from the audience was infectious. In the end, there’s nothing quite like standing in front of three thousand people and shouting together: “we come for code, but we stay for community!”

Previous Post

Evolving the Nation’s Report Card – A Study of Designing New Reports

May 21 2015
May 21

Broken links suck. It's incredibly frustrating to read a great article that links to an external resource that covers a subtopic in detail only to find the link is broken. In that moment I curse whatever developer or webmaster of the external site didn't think that creating a 301 redirect was worth the effort. I end up going to the root domain to hunt for the article by topic, hopefully the link text or URL slug gives enough topic or keyword clues to find it. Sometimes the external resource is gone completely and then I'm off to to try to find a cached copy.

You know what's worse than a broken external link for your Drupal site? A broken internal link.

A broken internal link is a slap in the face for user experience. You didn't create a 301 redirect from the old URL to a relevant new URL. You didn't update the link you have control over. Do you care about your reader's experience at all? I want to help you prevent broken internal links in your Drupal sites and show you a process to automate link updates. Don't slap your users, follow this process!

What are internal links

Internal links are simply links which are to URLs on the same domain or website. For example, this is an internal link to our Drupal CMS guides. The link is to a page on the domain from a page on the domain. We have full control over both the link href (an anchor attribute which creates a hyperlink, the link destination URL) and linking page. The opposite, external links, are simply links to a different domain. You don't have any control over the link destination.

Why internal links are important in Drupal

Inbound links (external links on other sites to your site) are important to build domain authority for SEO, improving search rankings. Similarly, internal links help create content relationships within your site and give context to content through their link text.

Sidenote: Search engines account for internal link anchor text. Ideally, you don't want anchor text to simply say "click here", "more", or some other non-contextual, non-descriptive anchor text.

How to create internal links in Drupal body text

The primary way you'll create Drupal internal links is through body text on pages. More than likely, your WYSIWYG offers a link button that'll pop-up a dialog to input a link URL. This gives you a few methods to create internal links.

Absolute internal links

If you create a link with a fully qualified URL (the complete http(s)://subdomain.domain.extension/page-name), that's an absolute link. No part of the link is "variable", its destination will forever be the exact URL you've input. If any part of the destination URL were to change in the future, your absolute links will become broken. You'll need to manually update them.

Relative internal links

You can create links that are relative to the linking page. There's a few methods of creating these relative internal links.

If you were to simply add the href of "page-name-2" to a link from a page at this URL:


The href would be relative to the current location and so the link will actually go to:


The link destination will retain the depth, and target a sibling page ("page-name-2" within /topic/).

You could also link to a page on the current domain from the top level by using a leading forward slash. If your link href was set to "/page-name-2" in the above example, with a leading forward slash, your destination would become: 


The forward slash causes the hierarchy to collapse, leading from the top level domain: "/topic" is dropped.

There's some additional advanced methods of creating internal links in HTML documents, but this should give you an idea of how they work. In essence, they create variables so that your links will work when certain conditions change. If your domain name were to change but your content hierarchy remained the same, your relative links would still have destinations that match your hierarchy and become relative to the new domain name. This gives you more flexibility than absolute internal links, but it's still not the best method.

Canonical internal links

Drupal's internal URL scheme creates canonical locations for content. These are the "non-pretty" URLs. Drupal's node system is reflected in these internal URLs:<nid>

In this scheme, the <nid> represents the internal node ID (a unique identifying integer) for a particular piece of content. This works similarly for Drupal's taxonomy and term system:<tid>

The <tid> is the term ID, identifying a taxonomy term. Using our example above, this is the canonical URL to our Drupal CMS guides:

The "Drupal CMS guides" term ID is 23. If you inspect or hover the actual link above, you'll see that the URL is pretty, human readable:

We've setup Drupal to have an alias for "/guide/drupal" to display our "Drupal CMS guides" term. Drupal creates these pretty aliases by default ("clean URLs"). 

However, this is the literal HTML code that Drupal stores for that body text internal link:

<a href="">Drupal CMS guides</a>

This is a relative internal link to a canonical URL. Our WYSIWYG is configured to translate these internal canonical URLs to their pretty aliases on the fly. This takes care of multiple issues:

  1. If we were to decide to change our domain or store this blog post on a subdomain, the relative link would automatically reflect the domain change
  2. If we were to alter the alias from "/guide/drupal" for this particular term to "/guides/cms/drupal", the canonical URL would point to the appropriate pretty URL

This works the same way for nodes: if we link to their canonical URL and their alias is updated, Drupal will automatically translate the canonical URL to the new pretty URL on the fly. Tracking down the canonical URL manually for each internal link can be a pain, though. We're getting to automating the internal link creation process, but first let's make sure we understand why it's important.

Why creating Drupal canonical internal links is important

As your Drupal website develops, you'll undoubtedly create more content: more nodes, more terms. You'll also come up with new URL strategies and ways to classify your content through the pieces of your URLs. Perhaps you'll decide to add a portion of the date within the URL, maybe a category the content resides in, or you just want to manually alter a piece of content's URL to make it shorter or better reflect the contents. This will happen over time. When it does, you don't want to either have to go back and update all your internal links to reflect the change, or even worse, cause broken links and leave them broken. Broken internal links will degrade your search engine performance two ways:

  1. You'll lose the internal link anchor text context and relationship between pages
  2. Search engines will devalue your content due to having broken links

Don't cause broken internal links. You have full control over fixing them and implementing a strategy to avoid them in Drupal. Let's automate the process.

Drupal Internal Link modules

What we want to do to automate internal link updates is simply make sure that all of our internal link destinations (hrefs) are to canonical URLs wherever possible. You can do this by tracking down the internal path and ID of every term or node you want to link to. That requires a lot of extra effort. There's a better way. Thankfully, Drupal's community of contributed modules comes to the rescue.

Drupal WYSIWYG Module and editor plugin (TinyMCE, etc)

If you're using the WYSIWYG module plus one of the editor plugins it supports, your best bet is the LinkIt module. LinkIt provides a button in the WYSIWYG and a dialog to search for content on your site to link to. Once you click the LinkIt button in your WYSIWYG, it's just a matter of following the prompts to create internal links:

Creating Internal Links in Drupal with LinkIt

LinkIt will automatically create your link with the relative canonical URL. You don't have to hunt down the content ID or fuss with the HTML of the anchor.

Drupal CKEditor Module and CKEditor Link Module

All of our Drupal projects now utilize the CKEditor module for a WYSIWYG. This is the direction Drupal 8 has gone and so we try to make sure the eventual progression will be seamless for our Drupal services clients.

The CKEditor module has an extension or submodule that performs similar work to LinkIt, the CKEditor Link module. This allows you to use the lovely CKEditor WYSIWYG to create internal paths quickly. We love it.

After following the module instructions to setup and configure CKEditor Link to work with CKEditor, you'll have a simple process to creating internal, canonical links. This is our internal link workflow using CKEditor and CKEditor Link modules:

CKEditor Link Workflow Internal Path Process How To

  1. Select the anchor text you wish to use in the WYSIWYG
  2. Click the CKEditor Link button
  3. Make sure the "Link type" in the dialog is "Internal path"
  4. Start typing the title of our content in the autocomplete text input, select the right suggestion

This process creates a link to the internal canonical Drupal path to the content.

CKEditor Link creates internal Drupal paths

If you ever change your domain or alter the destination page's alias pattern, this internal link will still work. Combining CKEditor and CKEditor Link modules is our favorite way to handle internal path and link creation within Drupal.

Checking for broken internal links

Now that you have a process to create proper internal links (if you haven't, make changes now), you may need to check for any broken internal links. Drupal offers an excellent module for broken link checking, but first let's look at Google's Webmaster Tools. The free tool offers excellent insight for broken links.

Using Google Webmaster Tools to check for broken internal links

You do have a Google Webmaster Tools account, right? If you don't, sign-up. If you're a manager or webmaster, ask your developer to follow these steps to check for broken links. It's quick, easy, and free. This is a great way to fix search issues, raise your ranking, and properly distribute your internal traffic. Don't slap your users with broken internal links.

After logging into the Google Webmaster Tools (GWT) and selecting your domain, find your broken internal links this way:

Use Google Webmaster Tools to find broken links

  1. Expand the "Crawl" menu
  2. Select "Crawl Errors"
  3. Select the "Not found" tab

This will provide you with a list of URLs with problems. You're interested in those that aren't found (404 errors). The URLs listed tell you which URLs Google has stumbled across and received a 404 error. These are great candidates for creating 301 redirects to the right, or at least relevant, content on your site. What you really want to check for though is where these broken URLs are linked from. Are they your own internal pages? GWT to the rescue again! Click any of the URLs listed:

Find the source of broken internal links with Google Webmaster Tools

The pop-up dialog will indicate the broken URL and where it is linked from. Go to those pages and fix your broken internal links.

Automate broken link checking in Drupal with Link Checker module

If you've got a large Drupal site, manually checking GWT for broken links may not be the most effective way to find them. Drupal's Link Checker module will automate this process for you. Setup the module and it will scan your new and existing content for links, follow them, and identify any problems with them through their HTTP status code. Fix any 403s or 404s! The Drupal Link Checker module works with both internal and external links.

Why are internal broken links bad for your Drupal site?

Search engine spiders or crawlers are very busy workers. There's an entire web worth of pages to crawl and re-crawl. When they run into a broken link, they may stop where they are and move onto the next page. Broken links are a negative signal to search crawlers. Don't give them a reason to devalue your page.

I'm sure you've run into a broken link or two in your life while reading a page on some website. I bet it may have tempted you to stop where you are on the page and try to find a more authoritative, updated page about what you were reading. If the page owner hasn't checked their content over time to verify the links work, what's to say the content is still accurate? Not only do broken links discourage search engines, but they discourage users. It's especially embarrassing where the links are internal because the webmaster has control over both the destination page and the linking page.

Broken internal links can easily be avoided. Create a workflow to utilize canonical, relative internal links. Automate your internal linking process as much as possible by following the steps above. Identify any existing broken links with GWT or Drupal's Link Checker module and setup a process to routinely check for broken internal links. Make sure to create 301 redirects if you update existing content paths to prevent external sites from linking to now nonexistent paths. Don't slap your users with broken links, they're quick to fix!

This post was inspired by reading Mike Gifford's spring cleaning tips for Drupal sites, be sure to show your Drupal site some love with routine maintenance! Did you like this article or know someone that needs some link workflow help? Share it! If you're still having trouble getting your links in order, you can hire our Drupal team!

May 21 2015
May 21

This article was submitted by our Premium Hosting Supporter Linode.

We’ve all experienced these before: slooow server hardware; unlimited disk space that is capped once you begin to actually fill it; local directory software installs because you’re not allowed to alter the root system. Managed hosting emerged to help solve these problems. And it did - but sacrificed the true power of a host’s infrastructure. Fortunately, an alternative exists that overcomes the deficiencies of both shared and managed hosting. I call it a “Freedom Host.”

What is a Freedom Host?

A Freedom Host respects your needs and creativity. It gives you full root access to the server leaving you with the most powerful processors and lightning-fast, solid-state storage.
Why choose a Freedom Host?

“Getting off the Island.”

This counters a long-standing community practice of exclusively using Drupal. We now see large opportunities in combining Drupal with other powerful auxiliary software. Managed providers have long offered users click-to-deploy for Drupal; but where’s the Node.js button? HA Proxy button? Split-DNS? Magento? These options don’t exist on a managed host.

A Freedom Host allows you to run what you want when you want.

Security is a priority when running your Drupal website, right? You verify file permissions, sanitize all site forms and enforce strict password rules to protect against risky Internet traffic. But what about protection from other websites on the same server? What about local containers running on the same private subnet as your own? A Freedom Host, whether dedicated or VPS, offers you greater security than what’s provided through today’s shared-hosting or containers.

How do I get Managed comfort with Freedom’s power?

Deployment - Deploying on a Freedom Host doesn’t have to be difficult. Between pre-made images, StackScripts, cPanel, or Bitnami, plenty of Drupal deployment options exist.

Drush – You can install Drush in seconds with full functionality on any Freedom Host.

Control Panels - While many Freedom Hosts provide you with a remote terminal to get started, you can install and run the GUI you want, not just what you’re limited to.

Backups & Monitoring - Any reputable Freedom Host provides a backup solution but additional options are limitless. Save your Drupal site as a tarball, dump your MariaDB/MySQL database or mirror to an external slave server. You can even image the entire server to backup or test locally in VirtualBox. System metric software, including Longview, New Relic or Piwik, measure, graph and store server traffic.

So, what can I do with all this Freedom?

While impossible to compile a full list, some interesting Drupal projects I’ve seen include:

  • swapping out “Zen” PHP for Facebook’s HHVM for speed improvements in Drupal 8
  • testing Drupal 8 using PHP7
  • compiling Nginx to include custom features for Drupal
  • custom compiling a kernel for improved performance.

A Freedom Host provides options when choosing what and how you run your Drupal website. Options aside, a Freedom Host is more powerful and less expensive than most managed providers. You can’t lose with Freedom.

This article was written by Ricardo N Feliciano. He is currently a Developer Evangelist for Linode, and is an Information Systems Technician in the U.S. Navy.

May 21 2015
May 21

DrupalCamp 2015 St. Louis - SLU LAW

DrupalCamp St. Louis is scheduled for June 20-21, 2015, and will be held at SLU LAW in downtown St. Louis, MO. Less than a month away, there are a few important bits of news:

DrupalCamp STL.15 Keynote Speaker: Alina Mackenzie (alimac)

Alina Mackenzie is a developer and system administrator based in Chicago. In the Drupal community she is a camp organizer, speaker and communications lead for DrupalCon mentored sprints. She is passionate about learning organizations, automation, and making open source friendly for beginners.

Alina's keynote will focus on "Finding the entrance: Why and how to get involved with the Drupal community".

Alina's profile is

Session Submission Deadline: May 29

Please submit your session proposals by Friday, May 29—just over a week from today! We'll notify speakers on June 5th whether a session was accepted or not.

We hope to see you at DrupalCamp St. Louis 2015! Registration will open next Monday, and sessions will be announced on June 5th.

May 21 2015
May 21

 Gorilla It is one thing to be brought into a project as a team player, where the project is managed or you are delivering a predefined piece of it. However, that is typically not the way things happen when doing work for a small business or an initial project which will result in a business launch.

The more challenging and demanding opportunities for a freelancer are those one-man top-to-tail projects: creating the whole megillah[1]. Here is a brief look at the steps that could give the poor shlub[2] a fighting chance.

  1. Initial Meeting: The client transfers his vision to you. Determine what specifically makes or breaks its success.

    Output: Management Summary: Mirror the client’s vision back to him in your own words, for validation.

  2. Reference site(s): Ask the client to point to sites exemplifying functionality that works and functionality that doesn’t.

    Output: Create a spreadsheet that will contain a row for each function, and identify that function as either a launch requirement, nice to have for launch, post-launch, or unneeded.

  3. Conceptual design: Using the approved spreadsheet, decide what the site will look like.

    Output: Some conceptual prototype, such as wireframes, storyboard, etc.

  4. Functional design: The details behind the elements of the conceptual design; how front-end elements should work, as well as the back-end functionality, business rules, and the seemingly small details (being able to print receipts with a receipt printer, accepting input from card-swipers, syncing with third-party applications, etc).

    Output: Functional design document.

  5. Architectural design: With all the functionality designed, it’s time to determine the architectural stack that will support it. What is the caching strategy? What services will be required (wget, cron, curl, configuration outside the Drupal docroot, specific versions for applications or services, etc)?

    Output: Architectural design document.

  6. Database design Of course, the Drupal schema has already been done for you, but there could well be additional tables needed, indexes defined, perhaps even the use of alternative databases, like MariaDB, NoSql, etc.

    Output: Schema(s) supplemental to the core Drupal schema.

    At this point, you have everything you need to determine effort and pricing. But as the client reacts to sticker shock by removing features or altering priorities, additional iterations may be needed.

  7. Artistic design It’s time to develop the design from which the page layouts, templates, CSS, and themes, will emerge. It may not be your responsibility to develop the artistic design, but merely to ensure that the design embraces the functional and conceptual designs.

    Output: Artist comps, Photoshop files, etc.

  8. Hosting selection: Armed with the architectural design, it’s time to consider what hosting service will be used. What pieces are needed beyond the normal LAMP stack and Drupal? What access will be required (ssh? cPanel?) and what granularity of control is needed?

    Output: Requirements list for the client to verify with the hosting service.

  9. Development: Naturally, this is where most of your time will be spent. I normally do my development locally, with a privately accessible test site for the client to use for review. I take the site offline unless I have something I want the client to review, otherwise he can get antsy not seeing any change.
  10. Customer testing: As page, widgets, and features progress, it’s good to have the client review them as soon as possible. There is no easy answer as to whether one should point at the agreement when the client rejects something that was done as designed. That said, certainly successful element/feature/page tests should be a foundation for an ultimate system test.
  11. Production environment readiness: It’s best to install the test environment on the production environment for readiness testing in advance. That could be difficult if the domain name cannot be used yet; not having it available could cause some things to fail. But for now, this is more a test of whether all the pieces on the architecture, and all the configuration settings for the LAMP stack (or whichever is being used), are correct and viable.

This is a greatly condensed, summarized, and simplified approach; nothing in Drupal development is ever one-size-fits-all. I hope it sparks your imagination and gives you a helpful framework with which to succeed.

Image: "Eastern Lowland Gorilla Infant in Kahuzi Biega National Park" by jpmckenna is licensed under CC BY 2.0

[1] From the Yiddish megile, the scroll from which the story of Purim is read. Used to mean a long embroiled story. And yes, the source of the name for The Magilla Gorilla Show (in one episode he says, “Such a megillah over a gorilla.”)

[2] Yiddish, meaning a pitiful person.

Other articles from this issue:


Michael J. Ross

Drupal 8 may not be released until Winter, 2015. Meanwhile, there is REST for the weary; a simple, effective technique for leveraging the RESTful module in Drupal 7.

Coming Soon


Amber Himes Matz

Drupal 8 may not be ready... Oh right, we said that. Okay, so meanwhile, you want speed, you want beauty, you want passion that leaps off the screen. Here are two great methods for exposing your views components as JSON. A walk in the park, a kiss in the dark...

Coming Soon

Larry Garfield

Drupal 8 will have built-in RESTful web services. Sit tight. Or follow Palantir’s steps in setting up a major media client’s smo?rga?sbord of movies, TV shows, and other video as an API for a web app, iPhone or Android app, or even a set-top box.

Coming Soon

May 21 2015
May 21
Tags: access, d8, Drupal

Drupal 7

In Drupal 7, a hook_node_access implementation could return NODE_ACCESS_IGNORE, NODE_ACCESS_ALLOW and NODE_ACCESS_DENY. If any of them returned NODE_ACCESS_DENY then access was denied. If neither did but one returned NODE_ACCESS_ALLOW then access was allowed. If neither of these values were returned by any implementation then the decision was made based on other rules but at the end of the day some code needed to grant access explicitly or access was denied. Other entities didn’t have access control.

Also, blocks had some sort of access control in a very strange way: hook_block_list_alter is used -- even by core -- to remove the non-visible blocks.

Drupal 8

Drupal 8 brings a unified entity API -- even blocks become entities. It also uses many of the same objects and concepts for routing access. Instead of constants, we now use objects implementing the AccessResultInterface. You can get an instance by calling the rather self descriptive AccessResult::allowed(), AccessResult::forbidden(), AccessResult::neutral() methods. If you are handed an AccessResultInterface object you can figure out which one it is by calling the isAllowed, isForbidden, isNeutral methods on it. Only one of them can return TRUE. Access results can be cached and so have relevant cache contexts and tags -- this is why we bother with Neutral. This caching metadata is properly merged when doing various operations on access results.

These objects are returned by hook_entity_access implementations for entity access check and by the check method of services tagged with access_check used for routing access

Let’s first consider a node access case. The entity access checker fires hook_entity_access and hook_ENTITY_TYPE_access (in this case hook_node_access) and tries to put together the results in a sane way. If we do not want to change the behavior from D7, then any D7-deny (now called Forbidden) should result in a Forbidden end result. If there are no Forbiddens then any Allowed should result in a final Allowed return value. Finally, if there were neither Forbiddens nor Allows then only Neutral were present (if anything at all) so return a Neutral. This is called the orIf operation, if you have two result objects then run $result1->orIf($result2) to get the end result. The other doesn’t matter, $result2->orIf($result1) is the same.

Let’s take a look at the AccessResult::allowedIfHasPermission method. What results do we want? Obviously, if the permission is present we want an Allowed to be returned. But if the permission is not there? It can not result in Forbidden because then any hook_node_access simply returning the result of this method would immediately deny access to the node. It really can only return Neutral: the lack of a permission means we this method can’t form an opinion about access. (Using this method is strongly preferred to if ($user->hasPermission()) { return AccessResult::allowed();} because it adds the right caching metadata).

Let’s say we want to determine whether a field is editable! This requires the entity to be editable and the field to be editable. For the sake of simplicity, let’s presume both are controlled by a permission. So let’s say the user has “edit entity” permission but doesn’t have the “edit field” permission. So according to the previous paragraph AccessResult::allowedIfHasPermission($account, ‘edit entity’) is Allowed while AccessResult::allowedIfHasPermission($account, ‘edit field) is Neutral. We can not return Allowed in this case! So we can’t use orIf -- we need another operation: this is called andIf. Much like orIf we want any Forbidden input to result in a Forbidden output and again the same as orIf we want two Allowed to result in Allowed. The only difference is in the case detailed above: when one is Allowed, the other Neutral, here orIf results in Allowed but andIf results in Neutral.

If you want to use your knowledge and familiarity with AND/OR then consider first the iron rule of “any Forbidden input results in Forbidden” and only if that rule didn’t apply then consider Allowed as TRUE and Neutral as FALSE and apply the normal AND/OR to these values. This logic is called Kleene's weak three-valued logic where the “third value” is Forbidden. Most misunderstanding and confusion results from trying to treat Forbidden as FALSE instead of being the contagious “third value” it is. The name Neutral might make you think “oh, three values are not a problem, I will just erase any N I see and the resulting two values can be evaluated like normal AND/OR” this is absolutely incorrect! In fact, if you have two variables and both are Allowed / Forbidden then the results for $x->orIf($y) will be the exact same as $x->andIf($y)! The outcome will only differ if either $x or $y is Neutral (and the other is Allowed).

Routing vs Entity Access

We have clarified the necessity for two operators and we have two subsystems, each using one of them: routing uses andIf, entity uses orIf. The difference is subtle -- as we have seen the only difference is the end of result of two access checks where one is Neutral, the other is Allowed. This becomes a Neutral result in routing and an Allowed result in entity access.

Making a Decision

All this three value logic is nice but at the end of the day, this is all internal. The user wants to see a page, can we show it to them or do we show a 403 page? Can we show this entity? The answer cannot be “I do not know”, it must be yes or no. So the system looks at the result and says yes if it is explicitly allowed, otherwise says no. For routing (remember, andIf) this is very simple: if every access checker answered Allowed then and only then we can answer yes. For entity access (remember, orIf) there should be no Forbidden answers and at least one Allowed to say yes.

May 21 2015
May 21

28 pages of unmarred perfection. This book is pure unadulterated genius

- Chris Arlidge

Never Be Shocked Again! - Budgeting your Web Project

Are you having trouble figuring out an appropriate budget for your next web project? Our whitepaper can help!

Download your FREE COPY, to learn the different types of website projects, understand the factors that play a role in the budgeting process, and determine where your web plans will fit when it comes to costs!

Don’t ever be shocked by web costs again! A clear guide to help you plan the budget for your next web project.

Imagine this scenario. You add three different blocks in your footer region and the mockups call for them to be side by side. Here are 3 ways to accomplish this:


Using regions, we could add and create more footer regions and call them Footer first column, Footer second column, third and forth just like in bartik theme. I personally don’t like this solution because what if we decide in the future to only have 3 columns instead of four?  Then we will need to remove regions and change the css, clear the cache etc.. not ideal.


Another way to do this would be to go and do all the work in css and is the way I’ve been doing it for years.

.region-footer .block {
 position: relative;
 float: left;
 width: 33%;
 padding: 0 20px;

Or if you’re using sass or less you could extend bootstrap’s grid system default classes like this:

.region-footer .block {
 @extend .col-md-4;

This works perfectly fine and is easy to edit in the future if we want to change from 4 columns to 3.


The final solution that I will show you today is to use drupal’s preprocessors to change the html markup to take advantage of the existing styles that bootstrap provides.

In your template.php file create or add to the existing block preprocess hook.

* Implements hook_preprocess_block().
function themename_preprocess_block(&$variables) {
 if($variables['block']->region == 'footer') {
   array_unshift($variables['classes_array'], 'col-md-4');

This tells all the blocks within the region “footer” $variables['block']->region == 'footer' to append bootstrap’s col-md-4 class to the classes_array

This same method can be use also to add grid classes to nodes and regions with their respective hook.  hook_preprocess_node() hook_preprocess_region().

May 21 2015
May 21

Normally, I would do this video style, but I'm a wildcard people and today we write! Thanks to one of our Code Karate supporters, Pieter, I am going to walk you through how to use Drupal views, date and content types to automatically hide/show nodes based on date field. Let's get started.

Make sure that you have Drupal Views installed. If you're new to Drupal, Views is like oxygen to humans, you REALLY need it. Also, you can learn more about Views by watching this video. Also, I installed the Drupal Date module. I will use this module to set the date for the node (explained more below). Besides Views and Date, you shouldn't need any other modules besides what already comes with Drupal core.

For my example, I am going to display a list of training times people could sign up for and then once the training session has passed the view will no longer show that training. Make sense? Let's build!

A quick note before we get ahead of ourselves. When you enable the Date module, make sure that you enable Date, Date API, Date Popup, and Date Views. These additional modules will make your life a little easier. You're welcome.

I think we're ready. To start, I am going to create a training content type. For the fields, I am just going to keep the defaults Title and Body and add additional field training date. Naturally, you can add other fields that fit your unique situation, but for the purpose of this example we won't need any other fields.

With that content type, I am going to create five different nodes. Each of these nodes will have a different date. For the sake of showing how to hide content based on date, I am going to make one of the nodes have a date in past. This node will be used to prove that my view is only showing training dates in the future.

With the nodes created, we now need to create a view. Before we start excluding dates from showing in the view, let's make sure we get a view that displays all the content we want. To do this, make sure you add all the fields you want for the training content type. For me, that means I have added the Title, Body, and Training Date fields. Also, under the Filter Criteria section I have limited it to only showing training content types. Doing this will show that I can display all the training content.

Next, we need to add a filter that will only show the training dates that are in the future and exclude those that have already happened. Remember, in my example I have added a date in past for my 1st training node. If the view is built correctly it shouldn't exclude the 1st training node, but still show the remaining four training nodes.

The first step to do this is to add a filter to your view. For the field, you will want to select the Training Date field (or whatever field you are using for the date). For the settings, keep everything default except for the granularity. I change this to be minute. The reason for this is because I want the training to be available to be seen right up until they start. If I kept the granularity at a day, it would be hidden at the beginning of the day.

The filter criteria are where we do the filtering for the view. In other words, this is what is telling the view to show or not show. Again, the goal is to hide old training once the date and time have passed. To do this, select the Is greater than operator and change the drop down to Enter a relative date. Within the relative date text field, enter "now". Why now? Now is a PHP date format that specifies the current date and time. So "now" is an always changing value, which is exactly what we want. There are tons of other PHP date strings that you can use if "now" isn't exactly what you are looking for. To learn more about those formats just go here.

That is it! Once you save your filter go ahead and take a look at the view. Again, if done correctly, we shouldn't see the 1st training node as that contains a date field less than "now".

Hopefully, you were able to follow along and get your view and content displaying correctly. Remember, you can use other PHP date formats to show/hide content based on your unique situation. There are an almost unlimited amount of possibilities.

This was a very simple way to filter content. Do you use a different way? If so, share it in the comments below.

Until next time, Happy Coding!

May 20 2015
May 20

At Drupal Camp London 2015, I spoke with Piyush Poddar, Director of Drupal Practice at Axelerant. We talked about Piyush's history in Drupal, Drupal as a business-ready solution, India's coming of age in open source culture, and how that is driving business value.


"Drupal really has become a business-ready solution. It allows those of us running businesses or selling solutions to clients to really not think about anything more, just go ahead and use it for production sites–large, huge production sites."

On working in proprietary v open source software: "I've done both. We sued to buy expensive books when we worked on [a proprietary technology], just to know how to do things the right way. Then we realized that it doesn't tell you how to do things the right way, just how to use the software. So best practices, how other folk are doing it, lessons learned, there was nothing there. Nothing to be shared. No platforms. No camps, no events. Now [using Drupal], it's out there. It just depends on you what you wanna grab."

On the Drupal community and the Drupal project: "Solid. Rock solid. It's an awesome project. Without community, I don't know if it would have been so useful. It's an awesome community, but without a project, what would we have been doing? Together, we are doing a wonderful job."

From consumption to contribution in India

Piyush says that it was pretty quiet on the Drupal front until Dries Buytaert, the Drupal Project Lead, visited India in 2011. "A lot of excitement happened. A lot of traction came into the ecosystem. There were a lot of camps in the country."

"The way Drupal started, it was seen as a job-based technology. We were consuming Drupal then. Most folks were looking at Drupal as a job, a 9 to 5 job ... Go to the office, work on a Drupal project, come back, forget about it. But now, companies and individuals have realized that it's not just using Drupal, not just consuming Drupal, but investing in the Drupal ecosystem locally, nationally (and perhaps internationally as well) is where the real value lies. And that's where you're getting good Karma and besides that, it's also about establishing your reputation, your stand, your maturity up in the marketplace. So organizations understood that over the years and a lot of them started that.

I would say the journey is still on. We still need to get to a stage where we can say we are all there. But a lot of companies are participating in domestic [Drupal] Camps and meet-ups in different cities in India, with 300-700 people in each of these meet-ups. I've seen a lot of companies starting to push their developers towards contribution, at times even during their day job. There are companies offering jobs with Drupal contribution as KPIs; Axelerant is one of them. We encourage a lot of contribution in-house," during both busy and less busy times, "And from a profit and loss perspective, we are absolutely fine about that." Axelerant, in fact employs the top Indian contributor to Drupal 8, Hussain Abbas.

Contribution generates business value

I asked Piyush what Axelerant gets back out of encouraging and paying for so much contribution to Drupal.

"Being an IT company, acquiring good talent and retaining them is probably more important than sales itself. There's a lot of business, a lot of leads, a lot of opportunity out there. You can just go grab them, but you have to deliver them and you have to do that constantly. And for that you need a team, you need people who are excited about this thing, who know their stuff, people who are experts. Hiring is a big problem. The two most important things we've don to solve this problem are getting onto Drupal–people love working in Drupal and people love working with companies that are so active in the community. They feel they'll learn more and how to become like Hussain and other [role models]."

"Lately, a lot of clients are asking how active we are in terms of contribution. How mature are we from that perspective. Our Marketplace profile has really helped up a lot for that. We track our references and ask our clients how they came to us. A lot of them tell us that our profile is very strong, enough for them to build the first level of trust and give us the first few projects. I cannot imagine this sort of advantage in a proprietary technology."

"My personal conclusion on that front is that in India we believe a lot in Karma. And what we are seeing is that it's the karma we do is coming back to us already in business, in happiness, in these awesome people that we work with. It's happening."

Guest author dossier

Drupal Camp London 2015 CxO Day presentation

From Consumption to Contribution - Lessons from India

YouTube video

Interview video

[embedded content]

May 20 2015
May 20

Did you have a great time at DrupalCon Los Angeles but want something to show for it?  

We are happy to issue a certificate of attendance in PDF format for anyone who picked up their conference badge or signed in at a training.

Simply submit your request via our contact page with the subject "Request a Certificate of Attendance", and be sure to include the associated order number.

May 20 2015
May 20

How would you like to present at one of the largest PHP conferences in Europe? DrupalCon Barcelona is coming, and we are actively looking for sessions for our new PHP track.

Unlike the Coding and Development track, the PHP track is all about the larger PHP community. We're not looking for Drupal-specific talks but for sessions about PHP itself (PHP 7 anyone?), about related PHP tools like Guzzle, general PHP leading practices, software architecture, and so on.

Want to speak to the community that has reinvented itself in recent years as a modern PHP powerhouse? We want to hear about all the power of PHP that we haven't adopted yet, and how we can get even better at our favorite server-side language.

Have a look at our suggested topics, and send us your sessions!


Larry Garfield

PHP Track Team | DrupalCon Barcelona

May 20 2015
May 20

Yesterday (May 19), the Louisiana Legislature’s House Civil Law and Procedure Committee voted 10-2 to return HB707 to the calendar, effectively voting it down, at least for the current session. The bill would allow businesses to refuse, in accordance with religious beliefs, to provide goods and services on the basis of a patron’s sexuality.

Described as the protection of “the free exercise of religious beliefs and moral convictions”, were the bill to pass it would preclude the state from taking “any adverse action against a person, wholly or partially, on the basis that such person acts in accordance with a religious belief or moral conviction about the institution of marriage.”

However, hours after the committee’s vote, Louisiana Governor Bobby Jindal issued an executive order in an attempt to accomplish much of what HB707 is intended to achieve. We’re aware that at least some of the bill’s opponents doubt the executive order may create substantive law. We’re also aware that the U.S. Supreme Court may issue a ruling (before its current term ends in late June) that preempts any contradictory Louisiana law.

Why We’re Talking About Louisiana

Earlier this year, we chose New Orleans as the site for DrupalCon North America 2016. Section 86-33 of New Orleans’ municipal code explicitly forbids discrimination by public businesses and stores. In much the same spirit as New Orleans’ code, we want to take this opportunity to unequivocally state that no one at any DrupalCon should be denied service, assistance, or support because of who they are or whom they love.

Community. Collaboration. Openness. These are our ethos. At our core, we’re as committed to these values being principles for how we treat each other as we are for how we do our work.

The very nature of open source means contributions can come from anyone. That means muting voices is inconsistent with our values. That means we believe inclusivity is progress. And that means it’s important we speak when our community asks questions about the risk of discrimination.

Along with logistics—such as available event space, and costs—our DrupalCon site selection process has always considered whether we’d be able to truly celebrate the diversity of the Drupal community and the spirit of the Drupal Code of Conduct. We believe, despite the bill and executive order, that we can still create a safe, diverse, celebratory space for our community in New Orleans next year. We’re happy to bring the diversity of DrupalCon to New Orleans, and we’re confident it’ll be a fantastic event.

Talk To Us

We want to hear about your experiences at DrupalCon New Orleans—any and all of them. Tell us your opinions, voice your perspectives, and share what you see. In the meantime, comment on this post, or email us, with your questions and insights.

May 20 2015
May 20

Promet Source Support Developer Kabenla Armah shares his gameplan for DrupalCon LA in 2015. He came, he saw, he deftly avoided dairy products.

Normally I’m sitting at home in Iowa, rocking the boxer shorts on the couch. The Xbox controller is in arm’s reach. Or maybe I’m tearing up a single track course on my mountain bike. But this week, none of that. This week is different.

It’s DrupalCon, so you know I have to put away the games and pack up the power brick so I can join in the fun. I ran through this quick Q&A about my plan for DrupalCon with Promet's marketing team to help understand my goals for this year's big show.

Q: What's one new area of Drupal you want to explore?

A: I’ve done lots of php development, but I’ve never done any theming. 

Q: What are your goals for this year’s Con? 

A: I'd like to pick up one new technology and then go experiment and be conversant in it. I think the winner is going to be using Twig to theme in Drupal 8. 

Q: Who do you want to see in person? Why him or her?

A: MortenDK. Because he’s been a main handler of theming in Drupal 8. And his personality is great. 

Q: Which game station has the hottest action? Ping pong? Air hockey? 

A: It's definitely ping pong. 

Q: How many members of your team made the journey with you? 

A: I'm actually the sole rep of my current project team to make the journey. No pressure, right? 

Q: Any foods you'd like to sample while on the west coast?

A: As long as it doesn't have any cheese in it, not even a single molecule, then I'm good. I'll try anything.

Want to share your highlights from DrupalCon LA? Fill out the form below and let us know about your experience!

May 20 2015
May 20

Mapping in drupal with open layers and views is hella awesome.  Add in the heatmaps and you've got some pretty sweet visualizations.  open layer heatmap exposed view filter using the content type with our geolocation field from our first exercise we first create a view - since we're using points we'll need a vector overlay to start with vector data overlay in views.  For those looking to test on their own site I've added an updated feature with the mapping in it.  The settings for the overlay are also pretty straightforward.  I use EPSG 4326 for most projections - especially since I'm using google's geocoder that spits it out by default (if we had to use ogr2ogr to transform the data we could , but for this project EPSG 4326 is just fine.  I also use WKT (well known text) for most of my mapping... again, this is handy with google, and generally a pretty usable format open layers vector overlay settings.  Once your view is built hit save - it's time to head over to the open layers side for a bit....

In the open layers interface /admin/structure/openlayers/maps/list/ add a new map - you'll need to center the map where you expect your data to be... in my case the US and then set your projections - EPSG 4326 (aka WGS84) is what I used here again - consistency is what matters....epsg 436 for data then scroll down a bit and you'll see your layer that you created from your view select the view with open layer data. After you're done here go on to the Behaviors layers behaviors part 1 there are a huge number of settings in here, but basically the defaults are going to be your friend....heatmap and tooltip settings Hit save now and go back to the view you just created... it's time to render this sucker.  Create a page view in your existing view - you could create a new view, but why bother... it's nice to keep it all in one place in my experience... that said don't forget to use the "override for this view" settings so that when you select openlayer map for your format you won't override any other views....  openlayer map page in viewUnder settings select your newly minted map and you're done!final map in drupal openlayers

We're almost done with the report - next we're going to look at how to preserve the data by passing it along to an international service aka open spending... again - thanks to all who have helped thus far from the charlottesville gop, @Buddy Weber, Barbara Null, Richard Statman, John Pfaltz et al.  As noted in our discussions what we find here is that Charlottesville is not really a big spender when it travels, and that in a given month we don't travel all that much.

May 20 2015
May 20

Mapping in drupal with open layers and views is hella awesome.  Add in the heatmaps and you've got some pretty sweet visualizations.  open layer heatmap exposed view filter using the content type with our geolocation field from our first exercise we first create a view - since we're using points we'll need a vector overlay to start with vector data overlay in views.  For those looking to test on their own site I've added an updated feature with the mapping in it.  The settings for the overlay are also pretty straightforward.  I use EPSG 4326 for most projections - especially since I'm using google's geocoder that spits it out by default (if we had to use ogr2ogr to transform the data we could , but for this project EPSG 4326 is just fine.  I also use WKT (well known text) for most of my mapping... again, this is handy with google, and generally a pretty usable format open layers vector overlay settings.  Once your view is built hit save - it's time to head over to the open layers side for a bit....

In the open layers interface /admin/structure/openlayers/maps/list/ add a new map - you'll need to center the map where you expect your data to be... in my case the US and then set your projections - EPSG 4326 (aka WGS84) is what I used here again - consistency is what matters....epsg 436 for data then scroll down a bit and you'll see your layer that you created from your view select the view with open layer data. After you're done here go on to the Behaviors layers behaviors part 1 there are a huge number of settings in here, but basically the defaults are going to be your friend....heatmap and tooltip settings Hit save now and go back to the view you just created... it's time to render this sucker.  Create a page view in your existing view - you could create a new view, but why bother... it's nice to keep it all in one place in my experience... that said don't forget to use the "override for this view" settings so that when you select openlayer map for your format you won't override any other views....  openlayer map page in viewUnder settings select your newly minted map and you're done!final map in drupal openlayers

We're almost done with the report - next we're going to look at how to preserve the data by passing it along to an international service aka open spending... again - thanks to all who have helped thus far from the charlottesville gop, @Buddy Weber, Barbara Null, Richard Statman, John Pfaltz et al.  As noted in our discussions what we find here is that Charlottesville is not really a big spender when it travels, and that in a given month we don't travel all that much.

May 20 2015
May 20

While developing a system to automate Drupal updates and using that technology to fulfill our Drupal support contracts, we ran into many issues and questions about the workflows that integrate the update process into our overall development and deployment cycles. In this blog post, I’ll outline the best practices for handling different update types with different deployment processes – as well as the results thereof.

The general deployment workflow

Most professional Drupal developers work in a dev-stage-live environment. Using feature branches has become a valuable best-practice for deploying new features and hotfixes separately from the other features developed in the dev branch. Feature branches foster continuous delivery, although it does require additional infrastructure to test feature branches in separate instances. Let me sum up the development activity of the different branches.


This is where the development of new features happens and where the development team commits their code (or in a derived feature branch). When using feature branches, the dev branch is considered stable; features can be deployed forward separately. Nevertheless, the dev branch is there to test the integration of your locally developed changes with the code contributions of other developers, even if the current code of the dev branch hasn’t passed quality assurance. Before going live, the dev branch will be merged into the stage branch to be ready for quality assurance.


The stage branch is where code that’s about to be release (merged to the master branch and deployed to the live site) is thoroughly tested; it’s where the quality assurance happens. If the stage branch is bug-free, it will be merged into the master branch, which is the code base for the live site. The stage branch is the branch where customer acceptance happens.


The master branch contains the code base that serves the live site. No active changes happen here except hotfixes.

Hotfix branches

Hotfixes are changes applied to different environments without passing through the whole dev-stage-live development cycle. Hotfixes are handled in the same way as feature branches but with one difference: whereas feature branches start from the HEAD of the dev branch, a hotfix branch starts from the branch of the environment that requires the hotfix. In terms of security, a highly critical security update simply comes too late if it needs to go through the complete development cycle from dev to live. The same applies if there’s a bug on the live server that needs to be fixed immediately. Hotfix branches need to be merged back to the branches from which they were derived and all previous branches (e.g. if the hotfix branch was created from the master branch, it needs to be merged back to the master to bring all commits to the live site, and then it needs to be merged back to the stage and dev branch as well, so that all code changes are available for the development team)

Where to commit Drupal updates in the development workflow?

To answer this question we need to consider different types of updates. Security updates (including their criticality) and non-security updates (bug fixes and new features).

If we group them by priority we can derive the branches to which they need to be committed and also the duration of a deployment cycle. If you work in an continuous delivery environment, where you ship code continuously,the best way is to use feature branches derived from the dev branch.

Low (<=1 month):
- Bug fix updates - Feature updates

These updates should be committed by the development team and analysed for side effects. It’s still important to process these low-prio updates, as high-prio updates assume all previous code changes from earlier updates. You might miss some important quality assurance during high-prio updates to a module that hasn’t been updated for a long time.

Medium (<5 days):
- Security updates that are no critical and not highly critical

These updates should be applied in due time, as they’re related to the site's security. Since they’re not highly critical, we might decide to commit them on the stage branch and send a notification to the project lead, the quality assurance team or directly to you customer (depending on your SLA). Then, as soon as they’ve confirmed that the site works correctly, these updates will be merged to the master branch and back to stage and dev.

High (<4 hours):
- Critical and highly critical security updates

For critical and highly critical security updates we follow a "security first" strategy, ensuring that all critical security updates are applied immediately and as quickly as possible to keep the site secure. If there are bugs, we’ll fix them later! This strategy instructs us to apply updates directly to the master branch. Once the live site has been updated with the code from the master branch, we merge the updates back to the stage and dev branch. This is how we protected all our sites from Drupalgeddon in less than two hours!

Requirements for automation

If you want to automate your Drupal security updates with the Drop Guard service, all you need is the following:

  • Code deployment with GIT
  • Trigger the update of an instance by URL using e.g., Jenkins CI, DeployHQ or other services to manage your deployment or alternatively execute SSH commands from the Drop Guard server.

Also to keep in mind:

  • Know what patches you’ve applied and don't forget to re-apply them during the update process (Drop Guard helps with its automated patch detection feature)
  • Automated tests reduce the time you spend on quality assurance


Where to commit an update depends on its priority and on the speed with which it needs to be deployed to the live site. Update continuously to ensure the ongoing quality and security of your project and to keep it future-proof. Feature and bug fix updates are less critical but also important to apply in due time.

For those of you interested in Drop Guard to automate the process as described in this blog post, please sign up for the free trial period so you can test all its features – for free – and get a personal on-boarding.

May 20 2015
May 20

There are days that I work on half a dozen different websites.  I'm sure some of you are in the same boat.  We make client edits and change requests with rapid effieciency.  We work locally, push to staging, test and review, then push to the live server and repeat.  I would be remiss in saying that I never made a change on the live or staging site accidentally.

The Drupal Environment Indicator module allows you to name, color, and configure a multitude of visual queues for each of your different servers, or other variables, like Git branch or path.  It is very easy to install, and can integrate with Toolbar, Admin Menu, and Mobile Friendly Navigation Toolbar for no additional screen space. 

Once installed, set the permissions of the roles you want to give permission to see the indicator.  You can adjust the general settings at /admin/config/development/environment-indicator/settings

Environment Indicator Settings

While you can create different indicators inside the admin UI, I prefer to set these in the settings.php files on the various servers so they are not overidden when we move databases back from Production back to Staging and Dev.

To do this, add the following lines into the settings.php files on each of your servers. Adjust the names and colors as you see fit:

// Local/Development Server
$conf['environment_indicator_overwrite'] = TRUE;
$conf['environment_indicator_overwritten_name'] = 'Local';
$conf['environment_indicator_overwritten_color'] = '#bb0000';

// Staging Server
$conf['environment_indicator_overwrite'] = TRUE;
$conf['environment_indicator_overwritten_name'] = 'Stage';
$conf['environment_indicator_overwritten_color'] = '#00bb00';

// Production Server
$conf['environment_indicator_overwrite'] = TRUE;
$conf['environment_indicator_overwritten_name'] = 'Production';
$conf['environment_indicator_overwritten_color'] = '#0000bb';

Environment Indicator on Admin Menu

In this day and age, we have a lot of clients that have their own staging servers to play around with layout, copy, and style.  Environment Indicator gives us, and them a sense of security that they are in the right place at the right time doing what we need to do.

May 20 2015
May 20
135 Writing the Book Drupal 8 Configuration Management with Anja Schirwinski and Stefan Borchert - Modules Unraveled Podcast | Modules Unraveled

Skip to main content

Writing a Book for D8

  • What’s it like writing a book for a piece of software that isn’t even officially released yet?
  • How long did the writing process take?
    • Packt publishing sent us a proposal to write this book in December of 2013. We got started quickly, sending them an outline of the chapters and an estimated page count in the same month. The original estimated page count was 150, it turned out to be around 120. We received a pretty strict time line, having to finish a chapter every two weeks, starting in December of 2013.
    • We managed to finish most chapters in two weeks, but some of the longer ones took a little longer since we also started one of our biggest projects we had had until then, also in January. That was pretty tough because that project took up way more than a regular full time job, so we ended up having to write all of the chapters late at night and on the weekends. In May, all of our chapters then went to the editors and we didn’t hear back from the publisher for a really long time.
    • We also told them that we will have to rewrite a lot of the chapters since there was so much work in progress with the Configuration Management Initiative and they were changing a lot about how it worked, like going from the file based default to the database default. I think it was in January of 2015 when chapters came back with some feedback and we started rewriting every chapter, which was pretty painful at the time. We were able to update some of the documentation at with the changes we found. It felt good to contribution at least a small part, when with our project and the book we had no time left to contribute code to Drupal 8 like we usually do.
    • We spent around 40 days on the book between the two of us.
    • In December, Packt asked the first publisher to review the book. We had recommended them one of our team members at undpaul, Tom, who has a similar amount of Drupal knowledge as Stefan. We really wanted to have someone from CMI to review the book, like Greg Dunlap. They had turned down reviewing the book after the first chapters were written, because too much would still change. Then after the changes went in we kept recommending Greg but I never heard anything back, maybe he was busy or they didn’t bother to ask. At the beginning of this year they told us the book was planned to be published by March. We recommended waiting because we didn’t expect a release candidate before the European Drupalcon and we would have rather had someone like Greg take the time to review, but Packt had another opinion :) Since most of CMI changes were finished, we didn’t feel too uncomfortable about the time of publishing, and it was also kind of nice to finally be done with this thing :) So it took a little over a year from start to finish. It was published on March 24th.
  • Do you expect to need to rewrite anything between now and when 8.0 is released?

The Book: Drupal 8 Configuration Management

  • What do you cover in the book?
    • We start of with a basic introduction to what Configuration Management in Drupal means, because it is a thing in Software development in general, that doesn’t usually refer to what it is in Drupal, where it basically just means that configuration is saved in files which makes deployment easier. In the first chapters, we make sure the reader understands what Configuration Management means and why version control is so important. We mention some best practices and then show how to use it for non-coders as well, since there’s a nice backend non-technical folks can use, even if you don’t use version control (which of course we don’t recommend). We also have a part that describes how managing configuration works in Drupal 7 (Features!) and then dive into code examples, explaining schema files, showing how to add configuration to a custom module, how to upgrade Drupal 7 variables to the new system and cover configuration management for multilingual sites.
  • Who is the target audience of the book?
  • Why did you decide to write about Configuration Management?
    • We have used Features to deploy configuration changes for a very long time, I don’t recall not using it since we started the company 5 years ago. We have talked about it at several DrupalCamps and Drupal User Groups and always tried to convince everyone to use it. We were really excited about the Configuration Management Initiative and thought it was a very good fit for us.
  • Before we started recording, you mentioned that there is a companion website to the book. Can you talk about what content we’ll find there, and what purpose that serves?
  • Are you building any sites in D8 at Undpaul?
May 19 2015
May 19

As we dive deeper into visual regression testing in our development workflow we realize a sad truth: on average, we break our own CSS every week and a half.

Don't feel bad for us, as in fact I'd argue that it's pretty common across all web projects - they just don't know it. It seems we all need a system that will tell us when we break our CSS.

While we don't know of a single (good) system that does this, we were able to connect together a few (good) systems to get just that, with the help of: Travis-CI, webdriverCSS,, BrowserStack/Sauce Labs, and ngrok. Oh my!

Don't be alarmed by the long list. Each one of these does one thing very well, and combining them together was proven to be not too complicated, nor too costly.

You can jump right into the .travis file of the Gizra repo to see its configuration, or check the webdriverCSS test. Here's the high level overview of what we're doing: is built on Jekyll but visual regression could be executed on every site, regardless of the underlying technology. Travis is there to help us build a local installation. Travis also allows adding encrypted keys, so even though the repo is public, we were able to add our and ngrok access tokens in a secure way.

We want to use services such as BrowserStack or Sauce-Labs to test our local installation on different browsers (e.g. latest chrome and IE11). For that we need to have an external URL accessible by the outside world, which is where ngrok comes in: ngrok http -log=stdout -subdomain=$TRAVIS_COMMIT 9000 from the .travis.yml file exposes our Jekyll site inside the Travis box to a unique temporary URL based on the Git commit (e.g.

WebdriverCSS tests are responsible for capturing the screenshots, and comparing them against the baseline images. If a regression is found, it will be automatically pushed to Shoov, and a link to the regression would be provided in the Travis log. This means that if a test was broken, we can immediately see where's the regression and figure out if it is indeed a bug - or, if not, replace the baseline image with the "regression" image.

Visual regression found and uploaded to


Some gotchas to be aware of:

Even though visual regression testing with BrowserStack or Sauce Labs takes more time than running it on PhantomJS, it's recommended to use such tools, since they test your site against real browsers.

Those tools cost money, but we find that it's well worth it. We are currently using BrowserStack (99$/month), though we're running into some issues with it not having an internal queue system - so if you reached your limit on virtual hosts concurrency, your tests will simply fail. For that reason we might switch to Sauce Labs (149$/month) which also provides more concurrent VMs.

Blog post page tested on IE11, Windows 7

Travis is limited to 50 minutes' execution time. Capturing each image might take about 30 - 90 sec, so when you reach lots of tests, you should probably split them.

The free plan of ngrok allows only a single concurrent tunnel to be opened. Even though BroswerStack and Sauce Labs provide their own tunneling solution, we decided to go with ngrok, in order to provide a more generic solution. We happily upgraded to the $25/month business account following our excellent experience with the free account.

May 19 2015
May 19

The fourth month of the year brought reminders that Winter can show up at unexpected times, with snow flurries during the early parts of the month. It also that we can only juggle so much. With many of us involved in organizing regional events and preparing for Drupalcon, our code contributions waned for a second month, down to a rather low 20 hours.

Drupal 8

Once again we've been fortunate to be able to put a good amount of effort into porting modules to Drupal 8, primarily for a client the will heavily benefit from some of D8's newest features.

  • Michelle Cox continued work on Metatag and Webform, the former of which will shortly be available as an alpha release.
  • Paul McKibben ported the er_viewmode module and wrote er_view_formatter, both of which will be made available shortly; Paul also joined as a co-maintainer of the XMLSitemap module and committed a number of RTBC patches, pushing the module closer to a stable state for D8.
  • After much help from Michelle I've been able to eek out some tentative entity handling for the D8 port of Metatag and will be making an alpha release soon. There's a lot to do before it reaches 1.0, but it's a step in the right direction.

Other work

Additionally, work has been progressing on some personal projects.


There were several successful events during April:

  • The month kicked off with the sixth annual Florida DrupalCamp. Once again the weekend was a huge success, the organizers showing again that they put on one of the country's best camps. Mediacurrent was a gold sponsor this year and a few staff members shared their knowledge & experience in presentations.
  • Matt Goodwin and I hosted the first of our “NHDevDays” code sprints in Keene, NH. Although we had a small turnout, it went well and the day ended with several new people successfully climbing the Drupal Ladder.

May-be More

With Drupalcon last week many of us spent much of May finalizing our presentations and attendance plans. At Mediacurrent we had a very busy week, and were glad so many of our readers and followers joined us at our booth, our evening party on Tuesday, and our many sessions. Now that we’re back home I expect our code contributions to pick up speed again.

Additional Resources

Introducing Mediacurrent's Contrib Committee | Mediacurrent Blog Post
Contrib Committee Status Report, March 2015 | Mediacurrent Blog Post