Thursday Terrain Corner

Tabletop Gaming News - 9 November 2017 - 11:00am
It’s Thursday, but it also kinda feels like a Friday. Reason being that tomorrow’s posts will be made from home in the morning before taking the rest of the day off. So I’ve got that going for me. Hopefully gonna help a friend put together some Guild Ball models and just hang out. Might even […]
Categories: Game Theory & Design

Stanford Web Services Blog: BADCamp 2017: Caryl’s Training Recap

Planet Drupal - 9 November 2017 - 10:14am

BADCamp is a delightful mix of networking and educational opportunities. Along with connecting with former acquaintances and meeting new people, I attended two really informative trainings. Here’s my recap:

Categories: Drupal

First Wave of November Releases Available From Privateer Press

Tabletop Gaming News - 9 November 2017 - 10:00am
The first set of releases for the month are available now from Privateer Press. And it’s kind of a nice transition between the two themes. You’ve got Cygnar on one side and Trollkin on the other. Meeting in the middle is the Trencher Express Team, which is a Trollkin and a Trencher working together. Too […]
Categories: Game Theory & Design

Acquia Lightning Blog: Optional config weirdness in Drupal 8

Planet Drupal - 9 November 2017 - 9:55am
Optional config weirdness in Drupal 8 phenaproxima Thu, 11/09/2017 - 12:55

This post was originally published on Medium.

Ah, the config system. Crown jewel of Drupal 8, amirite?

Well, yeah, it’s fantastic and flexible (as is most of Drupal). But if you have advanced use cases — such as building a system that alters config dynamically — there are traps you should know about.

Config is normally a fairly static thing. Your module/theme/profile (“extension” from here on out) has some configuration in its config/install sub-directory, and when the extension is installed, that config is imported. Once it’s imported, that config is owned by your site and you can change it in any way you see fit.

That’s the simplest, and most common, use case in a nutshell. Let’s talk about some other ones.

Optional config

In some extensions’ config directory, you will see an ‘optional’ directory alongside ‘install’. If you look in there, you see…some YAML files. What’s all this, then?

Optional config is normal config, but it’s treated differently. When an extension is installed, each piece of optional config it provides is analyzed, then imported only if all of its dependencies are fulfilled. A piece of config can declare, for example, that it depends on a view called ‘content’. That’d be expressed thusly in code:

dependencies: config: - views.view.content

If that piece of config is optional, then it will only be imported if, well, a view called ‘content’ exists in the system. That view might have been shipped with another extension, or maybe you created it manually. It makes no difference. As long as a view called ‘content’ is present, any optional config that depends on it will be imported as well.

Neat, yes? This comes in quite handy for something like Lightning, which allows you to create an install profile which “extends” Lightning, yet only installs some of Lightning’s components. Optional config allows us to ship config that might be imported, depending on what parts of Lightning you have chosen to install. Hooray for flexibility!

Optional config whilst installing Drupal

But wait, there’s more.

When you’re doing a full site installation (i.e., install.php or drush site-install), optional config is treated a little bit differently. In such a case, all extensions are installed as normal, but their optional config is ignored initially. Then, at the end of the installation process1, once all extensions are installed (and their default config has been imported), all2 the optional config is imported in a single batch.

I don’t think this is documented anywhere, but it can have major ramifications. Consider this piece of code — let’s say it’s part of a module called fubar, which provides some default config and some optional config. This hook will be invoked while fubar is being installed, but after its default config has been imported:

<?php /** * Implements hook_install(). */ function fubar_install() { $view = entity_load('view', 'fubar_view'); $view->setDescription('The force will be with you, always.'); $view->save(); }

fubar_view is optional config, so will entity_load() return a view entity, or will it return NULL? What do you think?

The maddening answer is it depends. It depends on when fubar is being installed. If Drupal is already installed, and you’re just adding fubar to your site, then $view will be a view entity, because the optional config will be imported before hook_install() is invoked. But if you’re installing fubar as part of a full site install — as part of an installation profile, say — $view is going to be NULL, because optional config is imported in a single batch at the end of the installation process, long after all hook_install() implementations have been invoked.

Yeah, it’s a WTF, but it’s a justifiable one: trying to resolve the dependencies of optional config during Drupal’s install process would probably have been a colossal, NP-complete nightmare.

Dynamically altering optional config

So let’s say you need to make dynamic alterations to optional config. You can’t do it in hook_install(), because you can’t be sure that the config will even exist in there. How can you do it?

The easiest thing is not to make assumptions about when the config will be available, but simply react when it is. If the optional config you’re trying to alter is an entity of some sort, then you can simply use entity hooks! Continuing our fubar example, you could add this to fubar.module:

<?php use Drupal\views\ViewEntityInterface; /** * Implements hook_ENTITY_TYPE_presave(). */ function fubar_view_presave(ViewEntityInterface $view) { if ($view->isNew() && $view->id() == 'fubar_view') { $view->setDescription('Do, or do not. There is no try.'); } }

This ensures that fubar_view will contain timeless Yoda wisdom, regardless of whether fubar_view was imported while installing Drupal. If fubar_view is created at the end of the installation process, no problem — the hook will catch it and set the description. On the other hand, if fubar_view is installed during drush pm-enable fubar, the hook will…catch it and set the description. It works either way. It’s fine to dynamically alter optional config, but don’t assume it will be available in hook_install(). Simply react to its life cycle as you would react to any other entity’s. Enjoy!

Moar things for your brain
  • hook_install() can never assume the presence of optional config…but it can assume the presence of default config (i.e., the stuff in the config/install directories). That is always imported before hook_install() is invoked.
  • In fact, you can never depend on the presence of optional config. That’s why it’s optional: it might exist, and it might not. That’s its nature! Remember this, and code defensively.
  • The config_rewrite module, though useful, can throw a monkey wrench into this. Due to the way it works, it might create config entities, even optional ones, before hook_install() is invoked. Even during the Drupal installation process. Beware! (They are, however, working to fix this.)
  • The config system is well-documented. Start here and here. This post is only one of tons of other blog posts about config in D8.
  • This blog post came about because of this Lightning issue. So hats off to Messrs. mortenson and balsama.
  • Thanks to dawehner for reviewing this post for technical accuracy.
  • “NP-complete”, as I understand it, is CompSci-ese for “unbelievably hard to solve”. Linking to the Wikipedia article makes me seem smarter than I really am.

1 The reason this happens at the end is because any number of things could be changing during installation (who knows what evil lurks in hook_install()? Not even the Shadow knows), and and trying to solve multiple dependency chains while everything is changing around you is like trying to build multiple castles on a swamp. (Only one person has ever accomplished it.) Don't think about this stuff too much, or it will melt your brain.

2 “All”, in this case, means “all the optional config with fulfilled dependencies,” not all-all.

Categories: Drupal

Project Management Part 2: Making Your Game With The ABC-Recipe - by Sara Casen Blogs - 9 November 2017 - 9:25am
This ABC-recipe for making games can help you and your team to understand what should be done and when. It offers a guideline for working iteratively on games, minimizing stress and optimizing testing your upcoming game!
Categories: Game Theory & Design

Come to GDC 2018 for real talk on staying creative in difficult times

Social/Online Games - Gamasutra - 9 November 2017 - 9:23am

Veteran game dev Laralyn McWilliams will explore the challenges of working in a creative field while dealing with stress, grief, & change, drawing on her own experiences dealing with cancer. ...

Categories: Game Theory & Design

Quick Start Edition of Infinity RPG Posted Free Online

Tabletop Gaming News - 9 November 2017 - 9:00am
Modiphius wants to give you a chance to check out their RPG system based on the incredibly popular Infinity miniaturs game from Corvus Belli. They’re even giving you the first hit free. They’ve posted up the Quick Start edition of the rules and aren’t charging a thing for it. So why not download yourself a […]
Categories: Game Theory & Design

Steamforged Games Previews Alternate Millstone

Tabletop Gaming News - 9 November 2017 - 8:30am
I am a huge fan of alternate-sculpt models. They’re a great way to get an exclusive figure out there to the players. Well, for those that are into the Farmer’s Guild and looking to get the new box that’s coming out in January, you can also pick up an alternate-sculpt Millstone. How? Just order from […]
Categories: Game Theory & Design

Amazee Labs: GraphQL for Drupalers - the basics

Planet Drupal - 9 November 2017 - 8:25am
GraphQL for Drupalers - the basics

GraphQL is becoming more and more popular every day. Now that we have a beta release of the GraphQL module (mainly sponsored and developed by Amazee Labs) it's easy to turn Drupal into a first-class GraphQL server. This is the new GraphQL series in which we'll describe the features that are new in beta and provide a detailed overview of the integration with Drupal's entity and field systems.

Blazej Owczarczyk Thu, 11/09/2017 - 17:25

This is the new GraphQL series about the new features that are in beta (published 2 weeks ago) and how they are connected with Drupal out of the box

The modules

Let's start with the modules we need. Recently there were quite a few changes in this field. In alpha we had:

  • graphql - The main module laying the foundations for exposing data using Drupal plugins.
  • graphql_core - which exposed Drupal core data - the info about entity types and bundles, but not fields
  • graphql_content - which handled field exposition with the view modes
  • other auxiliary modules (e.g., graphql_boolean graphql_entity_reference) that provided behaviours for specific field types

In beta, the structure has changed. Now the default schema exposes all the Drupal fields and (content) entities in raw form, using the typed data. Thanks to that GraphQL became a zero-configuration plug and play module. We just need to enable graphql and graphql_core (the only two modules that are shipped with the package now) and we're good to go.

NOTE: The other modules are still available in case you need them, they're just not part of the core package anymore. graphql_legacy is where most of the field modules went. Besides that, there are graphql_views  which lets us expose views, the promising graphql_twig that allows using GraphQL queries without a decoupled setup and a few more. All of the modules are listed in the drupal-graphql organization page on GitHub.

The Explorer

After enabling graphql and graphql_core we can go ahead and test it with GraphiQL; an interactive tool that lets you run queries, see results in real time and preview all the available fields along with arguments and return types. It also provides query validation, autocompletes suggestions and keyboard shortcuts. Thus, it's a kind of an IDE. The explorer is connected with the schema. We can find it next to the Default Schema under: Configuration -> Web services -> GraphQL -> Schemas or using the direct path - graphql/explorer.

This is how it looks. On the left, there is a query box with a comment describing the tool and listing the keyboard shortcuts. Results show up in the box on the right. To run the query we can use the «play» button at the top, or the keyboard shortcut (Ctrl-Enter). One more important piece is the < Docs button in the upper right corner. This is where we can see all the available elements. Let's go ahead and click it.

The only thing we can start with is the query field which is of type RootQuery. Clicking on the type shows a list of available sub-fields, including userById, which looks like this:

This field takes two arguments: an id (which is a string) and a language (which can be set to any language enabled on the site) and is of type User. Clicking on the type brings up a list of fields on a user. The name is a string:

Strings are scalars (which means they don't have subfields) so we can finish our simple query here. It will look like this:

and (after running it with Ctrl-enter) the response is what we'd expect

The GraphQL explorer (or GraphiQL) gives us the ability to easily write and debug every GraphQL query. That's a feature that's hard to overestimate so getting familiar with it is a good starting point to understanding how GraphQL works in general and how we can get our Drupal data out of it.

The Voyager

Voyager is another schema introspection tool, a visual one this time. It draws a chart of all the types and field in the system and presents it in a nice way. It can be found next to The Explorer under: Configuration -> Web services -> GraphQL -> Schemas or using the direct path - graphql/voyager.

That's it for this post. In the next one, we'll see some examples of retrieving data from Drupal fields.


Categories: Drupal

Texas Creative: Drupal 8 Custom Table of Contents Block for Book Content

Planet Drupal - 9 November 2017 - 8:15am

Want to customize the default block that comes with the book module?  Here’s a way to do it without writing custom code by using Views and the Views Tree module.

Read More
Categories: Drupal

CMON Hires Edouard Guiton as Senior Artist

Tabletop Gaming News - 9 November 2017 - 8:05am
If you’re a fan of the artwork of Zombicide and Massive Darkness these days, you’ll be happy about this announcement. CMON has hired artist Edouard Guiton as the senior artist for the company. So you can expect to see much more of his art style represented in games as the company moves forward, such as […]
Categories: Game Theory & Design

Plaid Hat Games Previews Villains from Stuffed Fables

Tabletop Gaming News - 9 November 2017 - 8:00am
The plushie characters in Stuffed Fables are protecting their sleeping girl from being harmed. But what are they protecting her from, exactly? What are these dangers out there? Well, they’re Crepitus (brother of The Man in the Moon) and his army of minions. In this preview from Plaid Hat, get a look at them, so […]
Categories: Game Theory & Design

Aten Design Group: Sunshine, Rainbows and Release Cycles: Drupal 9 and Beyond

Planet Drupal - 9 November 2017 - 7:57am
Planning for Drupal 9 and Beyond

Justin’s recent post about the product approach and Drupal's new release cycle got me thinking about what upgrading to Drupal 9 will really look like from a more technical standpoint. There's already lots of information out there explaining this new feature. I think there are some misconceptions about what it means for Drupal projects though, so let’s take a little look under the hood.


To understand what the process of updating to Drupal 9 might look like, you'll need to know a few background terms. If you already know what "semver" and "deprecation" mean for a software project, you can skip ahead to "Preparing for Drupal 9".

Drupal now follows semantic versioning. Semantic versioning—semver for short—is a format for assigning numbers to releases. This number signals a promise about the compatibility and/or stability of a release. A semver tag has three parts, a major version number, a minor version number and a patch version number, all separated by periods. For example, a recent version of Drupal was tagged 8.4.0. For this release, the major version number was 8; the minor version number is 4; the patch number is 0. A common misconception is to think that after 8.0.9, one must have 8.1.0, but it’s perfectly acceptable to have a release number like 8.0.107.

What do major, minor and patch mean? We'll look at each from least to most significant.

A patch release signifies a fix.

They are usually composed of small, isolated fixes. When Drupal is on version 8.4.0 and releases version 8.4.1, this indicates that it is a patch release. It means, "nothing in your code needs to change, we just fixed some bugs". These might be security fixes, so you should update to these releases as soon as possible.

A minor release signifies new features and deprecations.

These are my favorite. They're the ones filled with all the sunshine and rainbows. A minor release adds new features and code to Drupal. This might mean an experimental module becomes stable as the Workflow module did in 8.4.0 or—my personal favorite—a new experimental module, like JSON API, might be added to Core. A minor release is an opportunity for Drupal's maintainers to clean things up, to keep Drupal fresh and to ensure Drupal keeps up with the needs of modern applications. It's also an opportunity to deprecate parts of Drupal Core. A deprecation is when a part of Drupal Core gets moved to the graveyard. It will be maintained for security fixes and bugs, but you shouldn't use that part of Drupal any more. It's usually an indication that there are new, better APIs or best-practices you should follow. A minor release says, "we've made things better, we've cleaned stuff up, and we didn't break your stuff yet."

The graveyard of deprecated APIs

A major release signifies incompatible changes.

They can be a cause for celebration or an ominous cloud on the horizon. They're a critical event in Drupal's lifecycle. A major release is a signal that says "Warning: Your Stuff Might Break!" In some software, it might mean you need to rebuild your project. In Drupal 8 and beyond, thankfully, this shouldn't be the case. The maintainers have made a promise that says, "if you're not using deprecated code, you can update without rebuilding." In the past, like from Drupal 6 to Drupal 7, that wasn't the case and things definitely broke.

Preparing for Drupal 9

So, you know what a deprecation is, and what a major version release means. You know that the promise of Drupal's new release cycle is "if you're not using deprecated code, you can update without breaking things." But did you catch the caveat? If you're not using deprecated code. It's here that I believe the most misconceptions lie. I believe that many have confused this promise to mean that projects can be updated to Drupal 9 without a hitch. That the upgrade will be relatively routine.

The truth is that it's really up to you to make it routine and not something to fear.

How you approach your Drupal software project means that this major event in Drupal's lifecycle can be either a midlife crisis or a coming-of-age.

I said earlier that all the sunshine and rainbows are in the minor version releases. That's because you get all the goodies for free. Underneath the hood though, you need to be aware of what's being deprecated. Every time something is deprecated, a little technical debt is added to your project. You should pay that debt as soon as possible. A deprecation is a warning that the code underneath is going to disappear in Drupal 9. It's a warning to module maintainers and project developers that they need to update code that relies upon that newly deprecated API.

This reality is another point in the product approach's favor, as we alluded to in our earlier post. By making an ongoing investment in your project, you can address these deprecations as they happen so that when you're ready to upgrade to Drupal 9, it will be as painless as any other update.

The Prettiest Rainbows Come After a Little Rain

A select few sites will be able to proudly announce their upgrades to Drupal 9 the day it's released or soon after. Many won’t be able to move so quickly.

Knowing that Drupal 9 will break things relying on deprecated code and knowing that many modules won’t have been updated ahead of the release (such is life in open source), many sites will have to be patient. How patient depends on whether they’ve made an ongoing investment in their platform and kept up with deprecations in their custom code. They’ll be able to upgrade even faster if they have been model citizens in the Drupal community by reporting—and hopefully fixing—contrib dependencies on deprecated code too.

So, is this just like every other major Drupal release? Absolutely not! Gone forever are the days of completely rebuilding your site with every major update. Gone are the days of needing to migrate your own content to your own site. What this means is that you’ll just have to sit inside and wait or go play in the rain, fixing some bugs and updating some outdated dependencies, before you get to enjoy the Drupal 9 rainbow.

Here are some helpful links to stay up to date with deprecations:
Categories: Drupal

Simple Megamenu Bonus

New Drupal Modules - 9 November 2017 - 7:08am

Simple Megamenu Bonus extends the great Simple Megamenu Module by @flocondetoile

Special thanks to @flocondetoile!
If he likes the concept of these extensions we'd be happy to integrate this module into simple_megamenu one day. Otherwise this should be seen as a nice option for your special use-case. Simply read on...

Categories: Drupal

Empires Now Available From WizKids

Tabletop Gaming News - 9 November 2017 - 7:00am
It’s the 18th century and the time of conquest is upon us. Countries like Spain, Russia, France, and Great Britain are sending out explorers to far-flung reaches, claiming land in their name. The race is on to grow the most grand empire in all the world. And that’s what you’ll be doing as the head […]
Categories: Game Theory & Design

Orwell was released... and the world changed - by Melanie Taylor Blogs - 9 November 2017 - 6:53am
In the first of a series of blog posts on Orwell: Ignorance is Strength, we take a look at how things have changed since the release of Orwell: Keeping an Eye on You, and the substantial impact of those changes on the game, our studio, and the world.
Categories: Game Theory & Design

Level Design First Blocks: Part 2 – Level Design Theory - by Max Pears Blogs - 9 November 2017 - 6:50am
This is the second part of my three part series where I discuss some of the best practices to think about when making levels. These are guidelines which will help shape your levels and take them to the next "Level" ....aha puns
Categories: Game Theory & Design

25 Best Metrics to Help You Track User Loyalty - by Vasiliy Sabirov Blogs - 9 November 2017 - 6:50am
Measuring user loyalty remains one of the most important questions for product’s success. Let's see all the major metrics that you need to know to calculate your user loyalty.
Categories: Game Theory & Design

The “skip button” dilemma - by Sergio Rosa Blogs - 9 November 2017 - 6:50am
Why do some have problems with a "skip boss" button or "exploration mode" but, at the same time, consider unskippable cutscenes/dialogues a design flaw? Could it be that gameplay and story are not working together to deliver a cohesive experience?
Categories: Game Theory & Design

6 Reasons Improbable&#039;s SpatialOS isn&#039;t ready for Virtual Reality - by Carleton DiLeo Blogs - 9 November 2017 - 6:49am
VR development on SpatialOS isn't easy so I decided to create a short write up about the main problems I've faced.
Categories: Game Theory & Design


Subscribe to As If Productions aggregator