Node view published override

New Drupal Modules - 10 January 2018 - 8:45am

This is a simple module that override View published content permission provided by core.

The following permissions will be added to each content type:
view any published content
view own published content

Please follow instructions in README file

Please report any issue to module issue queue

Categories: Drupal


New Drupal Modules - 10 January 2018 - 8:23am
Categories: Drupal

Easy Commerce

New Drupal Modules - 10 January 2018 - 8:22am
Categories: Drupal

Lullabot: Guidelines for Writing Proper Tickets and Commits

Planet Drupal - 10 January 2018 - 8:12am

Have you ever been assigned a ticket with a title like “Some Images Don’t Work,” or opened a monstrous pull request containing a single commit labeled “bug fixes” as your only clue to the changes made? This level of ambiguity is frustrating and can end up costing exorbitant time and money to research. The titles, descriptions, and messages we provide in our workflow should make the jobs of not only our peers easier but also future team members who will inherit the project.

By tweaking our process just a little to document while we work, we can alleviate stress and save time and money on the project. Now don’t go breaking out the wikis and word processors just yet. Much of the critical documentation can be done within the tools you are already using. Writing actionable ticket titles, informative descriptions, and properly referencing related issues and resources can remove mountains of ambiguity and save yourself loads of time filling in the blanks or worse, making assumptions.

Before we get into the details, we need to think about the motivations behind the madness. If we’re going to spend more time writing up descriptions and details, what do we get for it? Anytime you are writing words that another person will read, think about who that person is. It might be a new developer on the team who doesn't have your background knowledge or you in a few months. Maybe a project manager, maybe a stakeholder. Will a machine be able to read and interpret this? All of these factors should influence what you write, regardless of whether it is a description of a bug or a commit message. What information will the next person need so they can eliminate assumptions about the task? Keeping this concept in mind, consider the following benefits:

  • Hours of time spent onboarding a new developer could be reduced.
  • Determining who signed off on a ticket and the process they followed could be done by inspecting a commit’s notes.
  • Changelogs could be automatically generated in different formats for stakeholders and developers.
  • Stop cursing out the previous development team because you don’t understand why they chose a particular method.
  • Or worse, don’t waste your time refactoring that code, then reverting it because you finally did figure out why they chose a particular method.
  • Spend time developing instead of researching a ticket.

As you’re creating a ticket, a commit message, or a pull request; remove the space for assumption. Explain why you did what you did, and, if necessary, how. Let’s start at the beginning with the ticket queue.


In this section, we’ll focus on the most granular of issue types: tasks and bugs. Epics and user stories have their own sets of rules and fall outside the scope of this article.

Ticket titles are the first field that someone reads. As I’m looking at my queue, I should know specifically what the ticket is intended to resolve by its title. Consequently, the title should describe the action that the ticket is to fulfill. Here are a couple of examples of good and bad versions of a ticket titles.

Good: “Prevent Nav Bar From Bouncing on Scroll”

Bad: “Navigation is Wonky”

Good: “Implement Home Page Right Rail Promo Block”  

Bad: “Homepage updates”

A helpful hint to consider when writing a title is that it should complete the phrase “This ticket will….” If you’ve done this correctly, the title will always begin with a verb; a call to action. When I see a ticket with the title, “Some Links are Yellow,” I think to myself, “Yes, yes they are. I’m assuming they shouldn’t be since you created a ticket, but what do you want me to do?  Should all links be yellow?  Or none of them?  What color should they be?”  Now, imagine you are a stakeholder reading over a list of completed tickets.  What would you think as you read this title?

Sometimes you’re going to need more than just the title to convey the complete purpose of the ticket, so make sure your ticket descriptions eliminate any room for assumption as well. For bugs, include the steps it takes to reproduce the issue, the environment where you encountered it (OS, browser, device, etc), and what the desired result should be. For simple tasks, reference any comps that describe how it should be implemented and consider user interactions if there are any.  The description field should provide extra information about the goal of the ticket.

If you are having trouble coming up with a specific enough title, consider breaking the ticket down into smaller subtasks, or promoting the ticket to an epic.


When you start your work, the best practice is to keep your main line of code clear by creating feature branches in your VCS to work on new tickets.  Branches should be filterable, recognizable, and attributable. That is to say, I want to be able to locate a branch quickly by who created it, which issue it’s tied to, and what it’s about.

I prefer a format like this: "owner/issue-id/short-description"

Which could end up looking like: "keyboardcowboy/proj-1234/fix_jumping_nav"

Think about who will see the branch names: myself, other developers, maybe a project manager, the repo gatekeeper if you have one, and machines. Using this format, I can now easily find my branches to create a pull request; I can check if anyone else has a branch for this ticket number; and I can allow project software, such as Jira or GitHub, to reference this branch by searching for the issue number pattern.

undefined Commit Messages

Developers may recognize the commit message prompt as that annoying thing GIT makes you do before you can push your changes. While it may be annoying when you’re working on your own, I guarantee that coworkers and your future self will appreciate the detailed messages you provide.

The reason for the commit message is to describe the changes taking place in that commit. If you find you can’t describe everything in one sentence, try breaking the commit into smaller, atomic commits. This makes it easier to roll back isolated changes if necessary and allows you to describe each change more succinctly. Just as with the issue titles, describe what the commit does. Someone else should be able to read it and understand to a basic degree what this change encompasses.

It’s also extremely helpful to precede the commit message with the issue number. The software can recognize certain patterns in commit messages and generate links from them. Tools like PHPStorm can help automate this for your process by integrating with GIT.


Here’s an example of well formatted, atomic commits vs a lazy commit.

Good Commits:

[proj-1234] Refactor white space in CSS so it’s readable. [proj-1234] Remove deprecated classes and definitions from CSS and templates. [proj-1234] Increase transition timing on navigation dropdown. The nav seemed to be jumping when the user scrolled while it was open. Increasing the transition timing allows it to expand and contract more smoothly and alleviates the jumpiness. [proj-1234] Fix merge conflict in update hook number.

Bad Commits:

Nav stuff.

Notice how the third good commit has multiple lines. The other commits in this set were ancillary to the issue.  The third commit is where the critical changes were made, so I explained my reasoning and why it fixes the issue. Without that, it looks like I just changed the timing. You might be able to trace the PR back to the original issue and piece things together, but a brief explanation directly in the commit can save time and headaches.

It may seem like overkill, but commits become very handy for the next developer, especially if you are using an IDE that integrates with GIT.

undefined Pull Requests

Pull requests are a common method to contribute to a project without needing commit access to the repository or to the main code branch.  The title of your pull request should follow the same structure as issues, but with one caveat; like tickets, they should describe the action that will occur if the code is merged, but they should also be prefixed with the issue-id of the issue they resolve. In GitHub, for example, the pattern "#ID" creates a link to that issue number. Even if you are not using GitHub as your issue manager, this is still an important reference, especially if you are running on a standard sprint cycle and need to generate reports for what was completed in each release.  Humans can follow this pattern to reference tickets as well as machines.

When you merge a pull request, a commit is made against the base branch and the title of the pull request is used in the commit message. Wouldn't it be nice if you could search through all the commits between release tags, find any that are pull requests and print them with references to their original issue as a change report? It’s surprisingly simple to automate that process if you follow these guidelines. Here’s an example of a good and a bad pull request title.

Good: “[PROJ-1234] Prevent Nav Bar From Bouncing on Scroll”

Bad: “Navbar Issues”

Imagine reading this as a code reviewer or a stakeholder trying to gauge what was accomplished in the last release. Which is going to be more informative? The title text describes exactly what was addressed, and the prefixed issue number provides the information needed to create a link directly to the original issue.

Just as with the original issue, you have an area for a summary in the pull request. I’ve found the most success in separating business discussions and technical review discussions between the issue management software and the pull request tool respectively. If necessary, provide testing instructions in the proper place and that your team follows any documentation guidelines consistently.

Automated Changelogs

Stakeholders often ask us to provide a list of everything that changed in the last release. Long sprint cycles and large teams can make this a challenge, especially if your issues, commits, and pull requests are vague.  The aforementioned guidelines not only make the project more understandable for people, but also for robots. On a project where the stakeholder required that an email is sent out after every release containing all the changes in that release, we used a simple, custom node script to pull all the commits made between tags and format them into a human-readable list using markdown. That list could be copied and pasted into various places, such as email and GitHub releases.  I’ve found a growing number of utility programs that attempt to do this or something similar. In a single command, you have a perfectly formatted, readable changelog, complete with links to the original issues!

Here are a few helpful tools I’ve found so far:

Documentation doesn't have to be boring and time-consuming. You can clarify your project with just a few simple refinements in your existing process and drastically reduce time spent writing up wiki documentation. Writing more detailed and informative tickets, commits, and pull requests will reduce sunk developer time, provide clarity for your stakeholders, ease your onboarding process, and provide better accountability and understanding throughout the project.

Do you have any suggestions or tips for documenting as you work? I’d love to hear about them!

Categories: Drupal

River Horse Previews Juan Sánches Villa-Lobos Ramirez For Highlander Board Game

Tabletop Gaming News - 10 January 2018 - 8:00am
Some Immortals are older than others. They’ve lived several lifetimes before many of the others were even born. One of the oldest is Juan Sánches Villa-Lobos Ramirez, whose history stretches back as far as his name. He’ll also be one of the characters you’ll be able to control in the upcoming Highlander board game. That […]
Categories: Game Theory & Design

Fantasy Flight Games Announces Realms of Terrinoth Setting Book for Genesys RPG

Tabletop Gaming News - 10 January 2018 - 7:00am
The Genesys RPG system is built to handle any setting and style of game you want to run in. But that’s not to say that once you’ve got the base book, you’re fully done. Sure, if you want to make up all your different realms entirely from scratch, you can do that. But having setting […]
Categories: Game Theory & Design

Acquia Developer Center Blog: Working with BLT: An Automation Layer for Testing, Building, and Launching Drupal 8 Applications

Planet Drupal - 10 January 2018 - 6:57am

Mike Madison, a Technical Architect in Acquia Professional Services, recently completed a Drupal site build for a major public transit agency in the United States. We spoke with him about his experiences using BLT -- an open-source Acquia product that provides an automation layer for testing, building, and launching Drupal 8 applications -- on this project. Mike said that BLT has been a critical component of the project’s success, and has especially helped in three primary ways: by accelerating project spin-up, improving developer onboarding, and increasing development velocity and delivery consistency.

Tags: acquia drupal planet
Categories: Drupal

Being a Winner (In Game Development) - by Ramin Shokrizade Blogs - 10 January 2018 - 6:49am
Using lessons learned in athletics and science we can tame the "Wild Wild West" that is current game development to build cohesive and winning teams.
Categories: Game Theory & Design

Game Cities: Those Handy, Simplified Urban Structures - by Konstantinos Dimopoulos Blogs - 10 January 2018 - 6:49am
The basics of urban structure and the three classic city models; a fine way of getting started with imaginary urban planning for your video game cities.
Categories: Game Theory & Design

Mediacurrent: Do Drupal and Digital Right in 2018: Know Where and How to Start

Planet Drupal - 10 January 2018 - 6:30am

When you’re solely focused on Digital Strategy and Drupal as your open source website and web application development framework like Mediacurrent has been for the last 10 years, you’re deeply invested in all of the great challenges and rewards that come with delivering products and solutions that are essentially only limited to your creativity and what you can dream up.

Categories: Drupal

Privateer Press Previews April Releases

Tabletop Gaming News - 10 January 2018 - 6:00am
No foolin’, Privateer Press is showing off some of their upcoming releases for April. Apparently, April is Dragon Month, as Cryx is getting all the love. If you’re wanting to expand your Satyxis-themed army, you’ll want to check out what’s in store. Admiral Axiara Wraithblade is one of the most feared women on the Meredius […]
Categories: Game Theory & Design

Valuebound: My first impression of learning AngularJS

Planet Drupal - 10 January 2018 - 5:07am

Before we delve into the ocean of understanding and learning curves of AngularJS, let me share my insights and experience of working on web development. Later, I will tell you why experiences are worth sharing.

For the past four-and-a-half years, I have been working in an IT industry. Started my career as a Drupal developer, working on web building, site building, extending features, development as well as designing. During this journey, I came across many technologies which I was expected to learn from scratch to bind/ integrate one to another. 

Cutting a long story to short! So why did I started learning AngularJS? What is the scope of AngularJS? And why I am sharing my experiences with…

Categories: Drupal

Game Pieces from Garbage: Crafting Basics

Gnome Stew - 10 January 2018 - 2:55am

Crafting is one of the easiest and cheapest hobbies to get into. Most of the prolific youtubers who have way more talent than me make a point of using found materials and dollar store supplies. The most I’ve spent on crafting for anything was about $10. That was for a hair dryer. Because I actually like to watch paint dry, just very quickly. Everything else came either from a dollar store or Walmart. Here’s a very general price list:

Glue Gun: $3

Paint brushes, box cutter, scissors, white glue: $1 each

Paints: 50 cents each at Walmart

Materials: whatever you don’t feel like throwing out.

Almost everything on this table is a dollar or some kind of trash.

There are more things that you will probably end up getting along the way, but if this is all the stuff you have, you are more than ready to start.

Once you’ve got stuff with which to make stuff, all you need to do is decide what kind of stuff you want to make. For a first piece, my suggestion would be to start with either a basic scatter piece or a simple, multipurpose dungeon tile. This is an article about my very, very first dungeon tile. Looking back now, what’s interesting to me is that there are even easier ways to put that sort of thing together. Texture paint is literally a magic spray paint that makes your tile look like it’s made of stone. Or you can use a sponge to make convincing stone patters. But the other nice thing about this hobby is that you do what works for you. I felt comfortable mounting paper to cardboard, so that’s what I did. Just get the job done. No one cares if it’s not perfect.

Dungeon tiles in particular can be some of the easiest, best places to start. One of the more popular types (and the ones I use) are what’s called 2.5D. All that means is that, as opposed to dwarven forge stuff or some molded plaster pieces, your walls are only suggested. What that means to you as a crafter is that you take a piece of cardboard, cut it to a size you want, and then glue one centimeter strips along the sides to act as your walls. In other words, you’re gluing small bits of cardboard to other cardboard. You want a building? Make a square. A big building? Make a bigger square. A cave? Make your sides wiggly, and your wall strips wiggly.

Measurements are weird.

Make enough of these, and you’ll find your projects naturally grow in scope and complexity. I ended up giving the wizard tower tile set to a friend before running full tilt boogie into the worst year of my adult life. One frozen pizza later, and I already had most of what I needed to replace this lost piece of my broken existence. So I made another tower tile, this time using texture paint. Then I made two basic tiles for use as an Inn. Actual children have pointed and laughed at these. (Then their characters gleefully killed 4 people in a bar fight and set the place on fire, as tweener gamers are wont to do. So I don’t think they cared all that much.)

Have a drink at the inn `o the snarky child!

Those three tiles were all I needed to feel good enough to about my tile making skills to attempt a complete modular set.

Lovingly hand crafted to allow players to experience only the best pain and suffering.

Outdoor pieces are actually incredibly easy to make as well. A lot of crafters swear by pink insulation foam. I’ve never actually used it because I found my way into more polystyrene than I know what to do with. And the more of that I can get go through, the less likely my dumb ass cat will find it and eat it.

You think I’m joking. I am not joking.

So polystyrene is typically what I use. If you use it, keep a few things in mind:

  • Polystyrene chemically reacts to spray paints, many glues, and many types of sealants. Acrylic paint is OK. White glue is OK. Anything else you probably want to test first.
  • That said, I have found that a base coat of black acrylic paint allowed me to apply texture paint to a piece without damaging it.
  • Polystyrene is also very messy. It flakes easily, so any time you cut it or break it to shape it, you will create little ghost beany things. Keep a vacuum nearby.

One of the most important things you’re going to need when you start crafting terrain is good flocking. If you go online and look up flocking on amazon, or worse, a gaming store, you will get what amounts to a very expensive price to pay for green fuzzy bits. I’m sure that stuff works well, but as a gaming crafter, half the fun is making cool things out of literal garbage. So when I make flocking, I use old coffee grinds.

I’ve actually read whole discussions on the pros and cons of using your spice rack for various flocking needs. (Pro tip: garlic powder might look great for sand, but it will make your gaming space smell like it’s expecting a vampire attack.) The thing to remember is keep it dry, and whenever possible use a sealer. I’ve also seen old pencil shavings used in pretty cool ways.

That all said, this is how I make an outdoor piece: I cut or break a piece of polystyrene into shape. Do a coat of brown. Dry brush (super light brushing with barely any paint on an otherwise dry brush) the sides with light brown because it looks good and then it seems like I know what I’m doing. Spread white glue over the top like I’m Ralph Wiggum on a paste bender. Then bury it in my coffee flocking. Then I shake off the excess and leave it to dry somewhere overnight.

Lastly, there’s the subject of paints. You can use as many different kinds as you like, a lot of crafters like having hundreds of paints, but my preference is for a basic color wheel with just a few flourishes. My total collection of colors is red, blue, yellow, green, white, black, dark brown, light brown, dark grey, light grey, light blue, and something called gunmetal gray (aka kinda sparkly gray) for things I need to look metallic. My feeling is that if I need anything else, I’ll mix it from what I have. So far I’ve only needed to make orange when making a fireball template.

Colored pencil over a print out, mounted to card stock from a cereal box with rubber cement, then covered in strips of clear packing tape to laminate it. (The other sides were painted, I just don’t have any pictures of it.)

There is a lot more which can be said, but my main goal is to convey how easy this actually is to do. It took me the better part of a year to start tinkering, and even longer before it was a full fledged “thing I did”. And the only thing that stopped me was my own squirmyness that I might make something crappy. That’s just not a good enough reason not to do something. A lot of crafting is almost like a recipe. Most of us aren’t pastry chefs, but we still make good cakes all the time. And crappy cake is still pretty good.

So again, if you’re curious, watch a bunch of youtube, then just go. I’m happy to answer questions, but you’ll also get equally good or better answers from the various forums, online groups, and youtubers who also do this, and do it way better than me. Either way, I hope this has been a good read. Please tell us any thoughts you might have. And happy gaming.

Categories: Game Theory & Design

Select2 Boxes

New Drupal Modules - 10 January 2018 - 2:34am
Categories: Drupal

Adventures in engine development: a multi-core foundation. - by Brian Hapgood Blogs - 10 January 2018 - 1:04am
Adventures in writing an engine: a multi-core foundation.
Categories: Game Theory & Design

QA - Defect Count is Defunct - by Alex Dorans Blogs - 9 January 2018 - 10:54pm
When it comes to checking the performance of your QA team, or individuals within the team, how do you go about measuring that? Here is why you should stop monitoring your teams bug quota and using it as metric to justify the teams output.
Categories: Game Theory & Design

Ironwatch Magazine Issue 62 Now Available

Tabletop Gaming News - 9 January 2018 - 3:00pm
When you want to fill your whole day with gaming, there’s little better than a gaming magazine. You can go over the articles and learn all sorts of insights into games you love, as well as tutorials on all manner of things, like terrain or tactics or painting your figures. They’ve usually got a bit […]
Categories: Game Theory & Design

Glassdimly tech Blog: Overriding Drupal 8's .eslintrc.json File in Your Theme With Extends

Planet Drupal - 9 January 2018 - 2:44pm

I had to do a little RTFMing today, and so I thought I'd post about it.

First of all, this is how you set up PhpStorm to use ES6 eslint settings. You may find it useful

Is the linter getting in your way? The first way to override an eslint setting is inline, disabling it on a one-off basis.

Categories: Drupal

Skirmisher Publishing City Builder Supplement Sale

Tabletop Gaming News - 9 January 2018 - 2:00pm
Many of you have resolved to get more gaming in this new year. I’m guessing several of you also resolved to be more responsible with money. Well, Skirmisher Publishing is helping you stick to your goals in one swoop. They’re offering a special 50% off price on their popular City Builder supplement. If you’re leading […]
Categories: Game Theory & Design

HTTP Cache Control

New Drupal Modules - 9 January 2018 - 1:43pm

HTTP Cache Control module helps fine grain control of Drupal's Cache Control headers.

Categories: Drupal


Subscribe to As If Productions aggregator