Skip to Content


Promet Source: A Break from the Ordinary at DrupalCon Los Angeles

Planet Drupal - 20 May 2015 - 10:04am

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.

Categories: Drupal

Drupal for Government: Part 3 - adding heatmaps with open layers and views

Planet Drupal - 20 May 2015 - 9:51am

Mapping in drupal with open layers and views is hella awesome.

Categories: Drupal

PSA: European Innovative Games Showcase submissions close this Friday

Social/Online Games - Gamasutra - 20 May 2015 - 9:07am

GDC Europe 2015 officials are still seeking submissions to the 2nd annual European Innovative Games Showcase at the Cologne, Germany show this August. You still have time! ...

Categories: Game Theory & Design

ERPAL: Drupal security: How to deliver Drupal updates continuously

Planet Drupal - 20 May 2015 - 3:30am

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.

Categories: Drupal

A Home Base for the Ethereal Plane

Gnome Stew - 20 May 2015 - 2:21am

I was doing some prep recently (gasp no!) so I figured I’d share. Here is a base located on the ethereal plane for your high magic adventures.

Reasonably close to the center of the bizarre geometry of the planes, the city of Media is a large trading center and rest stop for dimensional travelers of all sorts.

1. The Rock: A huge rock floating in the gray fog of the ethereal plane. It’s surface is rough and blasted and full of all sorts of pockmarks, caves and hidey-holes. While smuggler’s caches, monster lairs, and the like almost certainly contain riches, few venture out of the safety of the city.

2. Tear of Yggdrasil: A massive teardrop shaped piece of amber, embedded into the floating rock. It is assumed that it must have fallen off of a world tree somewhere. How it ended up embedded in a rock floating through the ethereal plane is anyone’s guess. In ages past, a palace was carved into the giant piece of amber. Even older is the spiraling pathway cut into its side leading to the tip which has been carved into a flat plane with upthrust spires of amber like some sort of primitive temple.

3. Media: A large hex shaped city surrounded by a thick stone wall. In the center of the city stands The Anchor, a huge pylon carved with glyphs and runes that helps keep the rock from wandering too far or from rolling to either side. Six main roads radiate from The Anchor to the corners of the wall. The wealthy of the city mostly dwell near the palace, with tradesmen and the middle class centrally located. The areas nearest the wall mostly house farmers and shops that cater to their needs.

4. Temple of the Rejoining: A few decades ago, a group of priests arrived in Media. Claiming the Tear of Yggdrasil was a sign from their god that their pilgrimage was over, they petitioned the noble houses of Media for a wing of the palace to set up their temple, but were rebuffed. Undaunted, they gathered enough money to erect a second wall outside Media proper and built a temple there. While they wait for their god to rejoin them at their temple, they minister to the people of Media.

5. Mushroom Plantations: Beyond each of the gates in the city wall is a raised road leading to a small hilltop fort. Below the roads and forts are a sticky morass of imported earth and garbage and waste collected from the city. Great forests of mushrooms grow in these mires tended by the poorest residents of Media. Mostly housed in the forts, a few of these farmers and loggers reside in the outskirts of the city proper. The forts also hold a small number of soldiers who protect the workers and ostensibly serve as a defense force for the city.

Categories: Game Theory & Design

Jim Birch: Using Drupal&#039;s Environment Indicator to help visually manage Dev, Stage, and Production Servers

Planet Drupal - 20 May 2015 - 2:00am

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

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.

Read more

Categories: Drupal

The &quot;Strange Attractor&quot; in Video Game Design - by Joseph Kim Blogs - 19 May 2015 - 11:13pm
Even a good game design may be doomed from the start: anyone launching in a competitive game category requires a strange attractor for user attention. Learn how to develop a good game concept using the principle of a strange attractor.
Categories: Game Theory & Design

Armor for Dummies and/or Game Developers - by Anna Jenelius Blogs - 19 May 2015 - 11:13pm
This crash course aims to provide a simple toolkit for anyone interested in introducing more realism to the armors of their game, and making them functional rather than just decorative.
Categories: Game Theory & Design

Kickstarter in France and Germany - by Thomas Bidaux Blogs - 19 May 2015 - 11:13pm
With Kickstarter opening in both Germany and France during the month of May, I am doing an analysis of the projects from those countries to date.
Categories: Game Theory & Design

Why don't developers buy/sell intellectual property much like other assets? - by Jorge Munoz Blogs - 19 May 2015 - 11:13pm
Are you stuck in Early Access? Has your game been a success and you're ready to move on? What ever the reason, why don't development companies trade ip much like other assets?
Categories: Game Theory & Design

Modules Unraveled: 135 Writing the Book Drupal 8 Configuration Management with Anja Schirwinski and Stefan Borchert - Modules Unraveled Podcast

Planet Drupal - 19 May 2015 - 9:40pm
Published: Tue, 05/19/15Download this episodeWriting 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?
Episode Links: Anja on drupal.orgAnja on TwitterStefan on drupal.orgStefan on TwitterWhere to buy the bookThe website for the bookundpaul on Twitterundpaul Instagramundpaul websiteTags: Drupal 8Bookplanet-drupal
Categories: Drupal

Flysystem S3

New Drupal Modules - 19 May 2015 - 5:13pm

Provides an Amazon S3 plugin for Flysystem.

See README.txt for configuration information.

Categories: Drupal

Flysystem Rackspace

New Drupal Modules - 19 May 2015 - 5:02pm

Provides a Rackspace plugin for Flysystem.

See README.txt for configuration information.

Categories: Drupal

Flysystem ZIP

New Drupal Modules - 19 May 2015 - 4:48pm

Provides a ZIP file plugin for Flysystem.

See README.txt for configuration information.


There is currently a bug in the Flysystem adapter that stops it from working with Druapl.

Categories: Drupal

Flysystem SFTP

New Drupal Modules - 19 May 2015 - 4:41pm

Provides an SFTP plugin for Flysystem.

See README.txt for configuration information.

Categories: Drupal

Flysystem Dropbox

New Drupal Modules - 19 May 2015 - 4:31pm

Provides a Dropbox plugin for Flysystem.

See README.txt for configuration information.

Categories: Drupal Visual regression tests on every commit

Planet Drupal - 19 May 2015 - 2:00pm

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

Continue reading…

Categories: Drupal

Mediacurrent: Contrib Committee Status Review for April, 2015

Planet Drupal - 19 May 2015 - 1:47pm

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.

Categories: Drupal

Drupalpress, Drupal in the Health Sciences Library at UVA: executing an r script with bash

Planet Drupal - 19 May 2015 - 1:43pm

Here’s a tangent:

Let’s say you need to randomly generate a series of practice exam questions. You have a bunch of homework assignments, lab questions and midterms, all of which are numbered in a standard way so that you can sample from them.

Here’s a simple R script to run those samples and generate a practice exam that consists of references to the assignments and their original numbers.

## exam prep script ## build hw data j <- 1 hw <- data.frame(hw_set = NA, problm = seq(1:17)) for (i in seq(1:12)) { hw[j,1] <- paste0("hw",j) j <- j+1 } library(tidyr) hw <- expand(hw) names(hw) <- c("problm_set", "problm") ## build exam data j <- 1 exam <- data.frame(exam_num = NA, problm = seq(1:22)) for (i in seq(1:8)) { exam[j,1] <- paste0("exam",j) j <- j+1 } library(tidyr) exam <- expand(exam) names(exam) <- c("problm_set", "problm") ## create practice exam prctce <- rbind(exam,hw) prctce_test <- prctce[sample(1:nrow(prctce), size=22),] row.names(prctce_test) <- 1:nrow(prctce_test) print(prctce_test)

As the last line indicates, the final step of the script is to output a prctce_test … that will be randomly generated each time the script is run, but may include duplicates over time.

Sure. Fine. Whatever.

Probably a way to do this with Drupal … or with Excel … or with a pencil and paper … why use R?

Two reasons: 1) using R to learn R and 2) scripting this simulation let’s you automate things a little bit easier.

In particular, you can use something like BASH to execute the script n number of times.

for n in {1..10}; do Rscript examprep.R > "YOUR_PATH_HERE/practice${n}.txt"; done

That will give you 10 practice test txt files that are all named with a tokenized number, with just one command. And of course that could be written into a shell script that’s automated or processed on a scheduler.

Sure. Fine. Whatever.

OK. While this is indeed a fairly underwhelming example, the potential here is kind of interesting. Our next step is to investigate using Drupal Rules to initiate a BASH script that in turn executes an algorithm written in R. The plan is to also use Drupal as the UI for entering the data to be processed in the R script.

Will document that here if/when that project comes together.

Categories: Drupal

A virtual twin: Can virtual drivers resembling the user increase trust in smart cars?

Virtual Reality - Science Daily - 19 May 2015 - 10:27am
Can the use of a virtual drivers programmed to resemble humans increase the level of trust and acceptance in smart cars?
Categories: Virtual Reality
Syndicate content

about seo