Skip to Content


Taxonomy translation UUID

New Drupal Modules - 13 May 2015 - 7:58am

UUID support for i18n_taxonomy. With this module term-UUID is used instead of TID for translations.

On admin/config/regional/translate/translate
taxonomy:term:1234:name -> taxonomy:term:{tid}:[type]
taxonomy:term:6ab188de-c1fc-4d17-bf5b-3ab3a77e4ae9:name -> taxonomy:term:{uuid}:[type]

Categories: Drupal


New Drupal Modules - 13 May 2015 - 6:49am

This module provides a field to integrate with Skype buttons and Skype URI's. The module contains 2 formatters, both configurable.
When a stable drupal 8 version is released, this module will be ported

Categories: Drupal

Spare computing power: Secure, anonymous, easy way to pay for online content

Virtual Reality - Science Daily - 13 May 2015 - 5:32am
Page views and “likes” are great for journalists' and webmasters’ egos, but they don't pay the bills. Researchers may have found a solution. They have identified a secure, anonymous way for readers, viewers and gamers to pay for online content without them having to make a cash payment. “Any online website could participate, whether they are a news site, a blog, a video streaming service, a gaming site, or social media,” remarked one of the researchers.
Categories: Virtual Reality

Attend GDC Europe to learn the business of nurturing amateur eSports

Social/Online Games - Gamasutra - 13 May 2015 - 5:19am

GDC Europe 2015 is just a few months away, and today conference officials are proud to reveal talks focused on the business of nurturing your game's community of players. ...

Categories: Game Theory & Design

Vardot: The Drupal Ecosystem: How to Productize Your Drupal Services

Planet Drupal - 13 May 2015 - 4:40am

As a web development firm scales, it will inevitably run into a complicated dilemma: whether or not to productize its services. Particularly with a complex and labor intensive content management system like Drupal, turning away from a business model built around providing specialized service to each individual client becomes increasingly logical as a web development firm expands and builds a reputation.

But, as you may have already noted, this comes at a cost—productizing your Drupal services means that each client ostensibly receives less individual attention from its web vendor. However, if done correctly, productizing your Drupal services will not only improve a web development firm's services, but will streamline the design and development process and insure that clients consistently receive excellent customer service, support, and, ultimately, superior web products.

So contemplating productizing your Drupal services doesn't need to run hand in hand with your company having an existential crisis. Here's why:

Productizing your web services means that you'll only need to develop a platform once, instead of starting from scratch each time you take on a project. It also means that a development firm only needs to maintain one system instead of several, which allows software engineers and customer support managers to focus all their energy on that particular system, and thereby improving overall experience for all of a firm's clients collectively.

So in short, what does productizing your web development services achieve? It reduces the total cost of ownership; reduces operational costs for the vendor; makes higher quality standards easier to attain; and finally, delivers a dependably high-quality product to clients. 

Check out this presentation assembled by Vardot's CEO, Mohammed Razem, that outlines the product vs. service debate by breaking down the phases of developing a website using Drupal. It details how consolidating these practices into a streamlined product will provide a more refined development and implementation process and will allow a team to produce more consistent products by cutting down on the unnecessary and time-consuming aspects associated with a service-focused model, and how that will result in better overall results.

Dig in:


Tags:  Productize Drupal Drupal Services Drupal Planet Title:  The Drupal Ecosystem: How to Productize Your Drupal Services
Categories: Drupal

Forever Folio (May 2015)

New RPG Product Reviews - 13 May 2015 - 4:37am
Publisher: Forever People
Rating: 4
Originally published at:

Forever Folio is the new house engine magazine from UK RPG publisher Forever People. Now I’ve never played Wyrd nor EVP, which are the two games they produce, but you DO get a free version of the Wyrd Game Systems and Settings with this Magazine, so that’s a nice bonus. I love gaming magazine and since this is a “Pay What You Want” release, it means that anyone (or everyone) can get it for free if they are hard up for cash or skeptical about the contents and quality. Of course, if you like what you see, you can always go back and give Forever People a few bucks or, better yet, purchase some of their games.

Because this magazine is a house engine, you should expect Forever Folio to focus on Forever People’s games, not some other companies. This doesn’t mean that there won’t be articles about non FP products though. In this very issue, there is a piece on a film called “The Dwarves of Demrel that is trying to raise 40K via crowdfunding on Kickstarter. I was backer #64 and honestly, it was this piece that drew me to trying out the magazine (besides my love of RPG mags) and also got me to download an adventure for EVP, which I’ll review later this month as well. There’s only a week left to help crowdfund “The Dwarves of Demrel” and it’s three-fourths of the way home so, consider backing it.

Anyway, let’s talk magazine contents. First up, there is a transcribed interview with Wyrd author David Sharrock. This original was posted online at, but Forever Folio has cleaned it up, given the piece a nice layout and some pretty artwork and made it easier on the eyes all-around. There are still some errors though, like “rill” instead of “roll,” but the piece gives newcomers a good idea about what they can expect from Wyrd in terms of both setting and mechanics.

After that comes “The Unsung Weave,” which is the start a free short serialized campaign for Wyrd. Of course to run “The Unsung Weave,” you will three different books, so while the adventure is free, the experience is not. This adventure does feel like it can be ported over to other systems with a little work and it’s designed for new players/character so it’s a great way to get a feel for whether Wyrd is for you or not. Further issues of Forever Folio will continue the campaign so if you like what you see, keep getting the magazine.

The third article is the piece about “The Dwarves of Demrel.” Then you get a look at Forever People’s newest RPG, EVP. This interests me far more than Wyrd, and although this article is only a page long, it does a fine job of selling people on the concept of EVP. As I said, I do have an adventure for EVP that I’ll be reviewing and for now I’ll just say it comes with a LOT of .wav files.

The rest of the magazine consists of two articles on Mazes, Maps and Monsters which is designed to be a fantasy RPG for young children. The first article is a breakdown of the rules, along with an accompanying character sheet. The second is an adventure for the game entitled, “The Ruins of Peril,” complete with pictures of the ruins made in Legos. Adorable. Dung, the Philosophical Giant is the best NPC I’ve encountered all year.

All, in all, this is a fun first house engine magazine from Forever People. It did what it needed to and got me curious about the various products the company offers and as I said, I did download The Salem House Haunting for EVP, so that right there shows the magazine did its job. Forever Folio does feel like a bit of a soft sell from beginning to end, and it’s certainly geared towards people who are completely new to Wyrd and EVP, but it’s the first issue of a magazine – it SHOULD be an introductory piece. Anyway, Forever Folio was a fun read and I’d definitely recommend picking it up to see if any of the three games covered in this magazine are worth your time and money.
Categories: Game Theory & Design

Trello API

New Drupal Modules - 13 May 2015 - 2:02am

The idea behind this module is to create a simple set of tools to make it easy to do integrations with Trello. For now only reading is supported. The module does nothing in itself, but enables developers to more easily do various things like getting boards or cards without understanding the Trello API


The module is being developed, and breaking changes can occur.

Categories: Drupal

ApacheSolr Search Language Fallback

New Drupal Modules - 13 May 2015 - 1:29am

Simple Module. No configuration required. Reindex content after enabling the module.

On a multilingual site, Apachesolr by default shows search results from all languages. This module when enabled, displays search results from the current language of the site.

If a node is not available in the current language and if the search term matches the content of the node present in the default language of the site, then the default language node is shown in the search results, as a fallback.

Affects all ApacheSolr searches on the site.

Categories: Drupal

Troy’s Crock Pot: Distilling Published Adventures

Gnome Stew - 13 May 2015 - 12:01am

Published adventures are more abundant and accessible than ever before. The depth, range and quality of the material is as strong as ever, too.

Descriptive text from Hoard of the Dragon Queen, Wizards of the Coast, 2014

That increases the likelihood of GMs incorporating published adventures into their games.

Of late, I’ve tried to streamline my process for preparing published material, whether I’m porting in an encounter from an outside source to use in the next session, or outlining several sessions from a campaign guide.

These three things are what I consider my priorities when gleaning from published adventures for my table.

Information transmission

I really try to zero in on identifying key information points in an adventure.

What information must the players receive and how will I convey it to them?

A lot of this is stuff they need to know to move things along from point A to point B. But it is also material crucial to developing their character’s individual story and the party’s collective tale.

Once I’ve made bullet points of the information points that are absolutely key, I give thought to how it will be revealed: From an NPC with a telltale voice or manner. A dying character’s last will and testament. A newspaper clipping. Engraved on a rock.

If important information is provided in a distinctive fashion during the game, then the chances of the players recognizing it as such and being able to recall it later is increased.

Nothing’s foolproof, of course. And in the course of play, other information points arise organically to confound, confuse and misdirect. But having provided the means for getting the good stuff out there, the better the chance it won’t be skipped over and it will be retained when it’s needed.

Three “Must-Run” Encounters

There’s more distilling of the published material. But this one is trickier, because players take the game where they want.

Still, by identifying three “must-run” encounters, the GM has at hand three comprehensive components needed for the session.

I think of encounters as three-dimensional modules, little packages of fun, that can be inserted into the framework of the session (whether it is the layout of a dungeon, the flowchart of an investigation or if the game’s gone completely off the map). Each encounter should contain any of several goodies: monsters, treasure, NPCs, traps, plot twists, ability challenges or an exotic location.

Having “must-run” encounters boxed up and ready to drop in is about keeping it fun for everyone. As a GM, nothing beats the reveal of a fun encounter. And having three that are “ready-to-go” sidesteps the little problem of the party getting sidetracked. No matter how far off the beaten track of the adventure they go, there’s an encounter directly ahead that will engage with them and keep the adventure flowing.

Identifying handouts

Broadly speaking, I think of handouts as ANYTHING that is tangible, including miniatures, combat terrain and maps, and other playing aids such as background music or sound effects.

You can always overdo this sort of thing. And it falls into “the right tool for the right job” category of adventure planning.

I mean, you don’t need stacks of Monopoly money on hand every time the PCs find a suitcase full of cash. But a couple of bills with a serial code clue written on them or having a few to dole out when an informant wants to be paid, can add to the atmosphere of the roleplay.

In theater terms, this is “staging.” Having properties on hand for presentation. Sometimes these are right-sized items, sometimes they are scale miniatures.

I always look through the text for opportunities to craft something new, given time. But over the years, if you keep stuff, you’ll have a wealth of trinkets and terrain to display or use as needed.

Those are my three priorities for preparing published adventures for the game table. But I’d like to hear yours. Share them in the comments below.

Categories: Game Theory & Design

Learn to make a game with no or less coding knowledge. - by Roger Gabriel Blogs - 12 May 2015 - 10:39pm
The article contains a quick overview of how to start with making games without no or very less coding knowledge.
Categories: Game Theory & Design

Kids Design Levels in Ultimate Chicken Horse! - by Richard Atlas Blogs - 12 May 2015 - 10:39pm
Last week, Clever Endeavour had some very special guests. We had three kids come in to help us design levels for our game, as one of the rewards for a Kickstarter tier.
Categories: Game Theory & Design

Everything you need to know about interpreting KPIs - by Nathan Lovato Blogs - 12 May 2015 - 10:39pm
As independent game designers, we want to focus on game creation. Sales and marketing related domains often feel foreign to us. Yet, to make a living, we do have to think as a company sometimes. That is when Key Performance Indicators come in.
Categories: Game Theory & Design

Down to the Letter: The Importance of Typography in Video Games - by Carol Mertz Blogs - 12 May 2015 - 10:39pm
Typography can make or break the aesthetic of a game. As game designers, we use type to communicate with our players, not only in the words we use, but also in the way we present those words.
Categories: Game Theory & Design

Game Dev Contracting - How much to ask - by Ben Chong Blogs - 12 May 2015 - 10:39pm
The all important money question
Categories: Game Theory & Design

“Game Over, Man” – Aliens: Colonial Marines class action over? - by Zachary Strebeck Blogs - 12 May 2015 - 10:39pm
Game lawyer Zachary Strebeck looks at the Aliens: Colonial Marines class action lawsuit and explains how and why the legal action against Gearbox may not be going forward.
Categories: Game Theory & Design

BizDev Diaries: Managing 150+ Meetings for Twelve Companies Without Losing My Mind (Part 3 of 3) - by Jay Powell Blogs - 12 May 2015 - 10:39pm
The final post in our series looking back at GDC and how we arranged and managed meetings for a set of clients with a wide variety of needs and services.
Categories: Game Theory & Design

How To Create Mobile Optimised Outlines in Unity - by Greg Kyth Blogs - 12 May 2015 - 10:39pm
This post looks at one method to create a mobile friendly outline for your 3D unity game without high performance costs that Unity's built in tools can cause.
Categories: Game Theory & Design

Midwestern Mac, LLC: Thoughts on the Acquia Certified Drupal Site Builder Exam

Planet Drupal - 12 May 2015 - 10:16pm

After taking the trifecta of Acquia Developer Certification (General, Back-end, Front-end) exams and earned a new black 'Grand Master' sticker, I decided to complete the gauntlet and take the Acquia Certified Drupal Site Builder Exam at DrupalCon LA.

Categories: Drupal

ThinkDrop Consulting: Continuous Deployment, Integration, Testing & Delivery with Open DevShop

Planet Drupal - 12 May 2015 - 4:34pm

Well before "DevOps" was a thing, and long before DevShop existed, was "CI". Continuous Integration is a critical part of successful software development.  As a web CMS, Drupal has lagged a bit behind in joining up with this world of CI.

One of the reasons that we don't see CI being used as much as we'd like is that it is hard to setup, and even harder to maintain long term.  Wiring up your version control systems to your servers and running tests on a continual basis takes some serious knowledge and experience. There are a lot of tools to try and make it easier, like Jenkins, but there is still a lot of setup and jerry-rigging needed to make everything flow smoothly from git push to test runs to QA analysis and acceptance.

Setup is one thing, keeping things running smoothly is another entirely. With a home-spun continuous integration system, the system operators are usually the only ones who know how it works. This can become a real challenge as people move to new jobs or have other responsibilities.

This is one of the reasons why we created DevShop: to make it ridiculously easy to setup and keep up a CI environment. DevShop's mission is to have everything you need out of the box, with as little setup, or at least as simple a setup process as possible.

Continuous Deployment

DevShop has always had Continuous Deployment: When a developer pushes code to the version control repository, it is deployed to any environment configured to follow that branch.  This is usually done on the main development branch, typically called master, and the environment is typically been called dev.

However for the last few years, DevShop has had the ability to host unlimited "branch environments".  This means that individual developers can work on their code on separate branches, and each one can get it's own copy of the site up and running on that branch.  This reduces the chances for conflicts between multiple developers and helps reduce the time needed to debug problems in the code because if you find a problem, you know what branch it came from.  

We've found that having branch environments is a much more productive way to code than a shared dev environment on the master branch.

Pull Request Environments

DevShop has been able to react to GitHub Pull Requests by creating a new environment since last year.  Each project can be configured to either clone an environment or run a fresh install every time a Pull Request is created. It will even tear down the environment when the Pull Request is closed.

Developers have less management to do using Pull Request environments: They don't need access to DevShop at all.  Everything is fully automated.

This method is even better than setting up branch environments, since Pull Requests are more than just code: anyone on the team can comment on every Pull Request, offering advice or asking questions about the proposed code.  Users can even comment on individual lines of code, making the peer review process smoother than ever by letting teams communicate directly on the code..

Continuous Testing

Recently we've added built-in behat testing to DevShop: When a "Test" task is triggered, the logs are saved to the server and displayed to users through the web interface in real time.   The pass or fail result is then displayed in the environment user interface as green or red, respectively, along with the full test results with each step highlighted with Pass, Fail, or Skipped.

This gives developers instant feedback on the state of their code, and, because it is running in an online environment, others can review the site and the test results along with them.  

The future of DevShop testing is to incorporate even more tests, like PHPUnit, CodeSniffer, and PHP Mess Detectors.  Having a common interface for all of these tests will help teams detect problems early and efficiently.

Continuous Integration

Continuous Integration can mean different things to different people.  In this context I am referring to the full integration of version control, environments, tests, and notifications to users.  By tying all of these things together, you can close the feedback look and accelerate software development dramatically.

GitHub, the most popular git host in the world, got to be that way in part by providing an extremely robust API that can be used to setup continuous integration systems. Each repository can have "Post commit receive" webhooks setup that will notify various systems that new code is available.

The "Deployments" API" allows your systems to notify github (and other systems) that code was deployed to certain environments.  The "Commit Status" API can be used to flag individual commits with a Pass, Fail, or Pending status.  This shows up in the web interface as a a green check, a red X, or an orange circle both on the commit and on each open Pull Request in the repository.  A failing commit will notify developers that they should "Merge with Caution", making it much less likely that code reviewers will merge bad code.

DevShop now leverages both the Deployments and the Commit status APIs for Pull Request environments.

Deployments are listed right in line with the commit logs of a pull request, and give the team direct links to the environments created by devshop.

Commit Statuses display not only a pass or fail status, but also link directy to test results, giving developers the instant feedback needed to respond quickly to issues.

Continuous Notification

An important part of any CI system is the notifications.  Without them, developers and their teams don't know that there is anything for them to do. GitHub has great integration with just about any chat service, and now so does DevShop.  

When your CI system is integrated with a chat service, the entire team gets visibility into the progress and status of the project.  New commits pushed notify others that there is new work to pull, and test notifications alert everyone to the passing or failing of those code pushes. Having immediate feedback on these types of things in crucial for maintaining a speedy development pace.

Continuous Delivery

With all of the pieces in place, you can start to think about Continuous Delivery.  Continuous Delivery is the act of "going live" with your code on a continuous basis, or at least very often.

DevShop allows your live environment to track a branch or a tag.  If tracking a tag, you must manually go in and deploy a new tag when you are ready to release your code.

If tracking a branch, however, your code will deploy as soon as it is pushed to that branch.  Deploy hooks ensure all of the appropriate things run after the code drop, such as update.php and cache clearing.  This is what makes continuous delivery possible.

If using Pull Requests for development, you can use GitHub's Merge button to deploy to live if you setup your production environment to track your main branch.  With the Commit Status and Deployment APIs, you can be sure that not only did the tests pass but the site looks good with the new code.

Merging to deploy to live is a great way to work.  You no longer need to access devshop to deploy a new tagged release, and you no longer need to manually merge code, hoping that everything works.

If it's green, it's working.  If your tests are robust enough, you can guarantee that the new code works.

If your tests are so complete that you start to reach 100% code coverage, you can start thinking about true continuous delivery: Tests Pass? Automatically merge to live and deploy.  This requires that your tests are amazing and reliable, but it is possible.

DevShop doesn't have the ability out of the box to setup true continuous delivery, but it would not take too much work.  You could use the hosting task status hook to fire off a merge using GitHub's API.

As more people start to use Continuous Delivery, we can work on incorporating that into the devshop process.

All wrapped up in a Bow

With DevShop, you will spend (much) less time on your support systems so you can focus on your websites.  We hope to continue to find ways to improve the development process and incorporate them directly into the platform.

We encourage everyone to embrace continuous integration principles on their projects, whether it is using DevShop or not.  Not only does efficiency go up, but code quality and morale does too.  

If you are a software developer, having tests in place will change your life. Everyone involved in the project, from clients to quality assurance folks to the dev team, will sleep better at night.

Tags: devshopcontinuous integrationPlanet Drupal
Categories: Drupal

Drupal core announcements: Drupal 8 beta 11 on Wednesday, May 27, 2015

Planet Drupal - 12 May 2015 - 3:56pm

The next beta release for Drupal 8 will be beta 11! (Read more about beta releases.) The beta is scheduled for Wednesday, May 27, 2015.

To ensure a reliable release window for the beta, there will be a Drupal 8 commit freeze from 00:00 to 23:30 UTC on May 27.

Categories: Drupal
Syndicate content

about seo