Janez Urevc: Drupal 8.2.0 and composer wonderland

Planet Drupal - 17 October 2016 - 1:22am
Drupal 8.2.0 and composer wonderland

Over the weekend I took some time to update this site to the latest and greatest Drupal. Update itself was pretty straightforward and it went without any problems (great work Drupal community!).

More interesting part was something that I wanted to do for a while. Until now I was using old-school approach repo with all modules and other dependencies committed in it. Most of you probably already heard about the Composer. Thanks to Florian Weber (@webflo) and other contributors it is now fairly easy to manage your Drupal projects with it. There is a Composer template for Drupal projects available which will give you everything you need to get started. It took me just a good hour to fully convert my project (I am no Composer expert). I found this approach very nice and convenient and will be using it for all my future projects.

As part of this I also worked on a pull request for Drupal docker project that makes docroot location configurable, which is a requirement for Composer driven projects.

slashrsm Mon, 17.10.2016 - 10:22 Tags Drupal Docker Composer Enjoyed this post? There is more! Drupal dev environment on Docker runs on Drupal 8! Call for Drupal 8 media ecosystem co-maintainers
Categories: Drupal

Vardot: DrupalCon Dublin 2016 - What Drupal means to us?

Planet Drupal - 17 October 2016 - 1:09am
Events Read time: 1 minute

The DrupalCon in Dublin is over – and now it’s officially. We all had fun, enjoyed sessions, sprints, visited all the booths, collected prizes, and had a lot of great talks with drupalists from all over the globe. All the expectations we had before this event came true, and now it’s time to make some conclusions.

But instead of writing a long recap, we at Vardot decided to remind you about the coolest moments of the conference in one short video. It's  better to see once than hear a hundred times – so enjoy!



Did you find yourself in a video? If not, how would you describe Drupal with one word? Your opinion counts. What were the most exciting moments of the conference for you? Share your emotions in a comments section below and see you next year in Vienna!


Tags:  DrupalCon Drupal Planet Title:  DrupalCon Dublin 2016 - What Drupal means to us?
Categories: Drupal


Gnome Stew - 17 October 2016 - 1:00am

I’m a planner. It drives me crazy when I don’t know what is happening next (or for the next few months, for that matter). As a gamemaster (GM), you’ll have to decide how far ahead to plan your sessions. Roleplaying games (RPG’s) present a special challenge to your planning: players and the dice have an effect on what happens next.

In this article, we’ll look at three time frames from planning your sessions, their advantages and disadvantages. As always, there is no “One True Way”, and you may use all three time frames under different circumstances.


In some cases, GM’s will only plan for one session. For example, there’s no point in planning more than one session for a convention game. If you are starting with a new group, you may want your first session to be self-contained. This gives them the opportunity for a complete adventure right off the bat. Also, some GM’s only plan for one session to better respond to their players goals and interests. Sometimes something a player says or does provides clear direction for planning the next session.

Single session planning does have some drawbacks. If players burn through your adventure faster than you planned, you’ll have to scramble for “what comes next.” You may not be able to foreshadow the next session, It’s difficult to provide hooks for a future story if you don’t have one in mind.

Planning a couple of sessions (or so) ahead has a lot of advantages. You’ll always have extra material if your players complete a major task early. You’ll be able to foreshadow the next session and provide story hooks early. Three sessions or so can form a nice mini-campaign. Planning a few sessions ahead still allows you to respond to player interest. While you may not address the very next session, your players still won’t have to wait long.

To avoid railroading when planning several sessions, you may want to consider Island Design Theory. This allows you to plan ahead (good for your own sanity), while still allowing the sessions to move around (good for player empowerment). If you don’t want to change the order of your sessions, you can also just change the goal. Instead of entering the Tomb of Possible Dismemberment to find the Sword of Eld, they can go in to capture the scoundrel Mr. Raeus instead. A final issue is that you may plan sessions and then not use them. Sometimes player actions take the campaign in a different direction. Be sure to save these unused gems for another time.

In this time-frame, you map out the campaign from beginning to end. The goal is to hit the major plot points and reach the finale. You may have side adventures along the way, but they are not the main focus. This allows you to use foreshadowing and recurring villains to craft a true epic. This sense of an over-arching story can help motivate players to return session after session.

This time-frame can be especially susceptible to railroading. Again, Island Design Theory can help keep the campaign more fluid and responsive to the player characters actions. It also requires a lot of foresight and planning on the GM’s part. Some GM’s may not want to feel so constrained. If you decide that you’d like to change the flavor of a campaign in midstream, players may still want a resolution to the main storyline. Lastly, you may plot out an epic campaign, only to have real life cut it short in the middle. Sadly, it happens.

Of course there are many other options. Some games support developing sessions collaboratively on the fly. No (or minimal) planning needed. Another option is to have a general campaign goal in mind, but to prepare sessions as you get to them. Ultimately, you’ll have to see what works best for you and your group.

How far ahead to you prepare? What other benefits and concerns can you suggest? Let us know below.

Categories: Game Theory & Design

Character Design for Games - by Alice Winter Blogs - 17 October 2016 - 12:27am
Since characters are not just pulled out of nowhere by a magic wand, character designers are tasked with creating the visual concept of a new character, its traits and its background.
Categories: Game Theory & Design

Drupalize.Me: Load Testing Our Site on Pantheon

Planet Drupal - 17 October 2016 - 12:07am

I did some load testing to try and answer the question; How did moving our site from Linode to Pantheon affect the performance-measured in response time-of our site for both members and non-members?

Categories: Drupal

Fuzzy Thinking: Roll Them Dice!

RPGNet - 17 October 2016 - 12:00am
Fuzzy botch!
Categories: Game Theory & Design

Aurelien Navarre: From $conf to $config and $settings in Drupal 8

Planet Drupal - 16 October 2016 - 11:37pm

With Drupal 7 we were used to leverage $conf to set variable overrides. Unfortunately this was sub-optimal. The Configuration override system documentation page says it best:

A big drawback of that system was that the overrides crept into actual configuration. When a configuration form that contained overridden values was saved, the conditional override got into the actual configuration storage.

Using $conf on Drupal 7

Let's say you wish to query the {variable} table for the site name.

mysql> SELECT name,value FROM variable WHERE name = 'site_name'; +-----------+----------------------+ | name | value | +-----------+----------------------+ | site_name | s:12:"My site name"; | +-----------+----------------------+ 1 row in set (0.00 sec)

You can quickly get the information you want and confirm this is indeed the value your site returns at /admin/config/system/site-information. Now, if you want to override the entry in code, you can put the below variable override in settings.php.

// Override the site name. $conf['site_name'] = 'My new site name';

When bootstrapping, Drupal would return the overridden site name with the original value left untouched in the database. Easy. Doing so also means the value provided in code wouldn't be modifiable from the Drupal administration interface any longer. Well, you could modify it, but it'd be overridden no matter what.

In Drupal 8 the variable subsystem is gone and we now need to leverage either $config or $settings depending upon what we wish to achieve. Both are being set via Settings::Initialize - Let's explore each to understand the differences.

When to use $config in Drupal 8?

$config is brought to you by the Configuration Management system. To keep it really simple, think about variable overrides and call them configuration overrides instead. And as you can see below, there are indeed similarities:

  • You can globally override specific configuration values for the site.
  • Any values you provide in these variable overrides will not be viewable from the Drupal administration interface. (Don't think that makes sense? There's an issue for that.)

But there are also notable differences. One I think worth mentioning is related to modules. In Drupal 7, it was easy to disable a module via $conf, by setting the below variable override.

$conf['page_load_progress'] = 0;

This was useful when - for instance - willing to have certain modules disabled in non-prod environments.

In Drupal 8 though, overriding the list of installed modules in core.extension is not supported as module install or uninstall has not occurred and modules cannot be disabled anymore. There is a contrib module to try and bring back this functionality to Drupal 8, but be careful of unintended consequences on a production site.

There are other particular configuration values that are risky to override, like field storage configuration which could lead to data loss. So, really, you have to make sure what is going to be overridden wouldn't have a negative impact on your site.

In any case, the administration interface displays the values stored in configuration so that you can stage changes to other environments that don't have the overrides. If you do want to see the overrides, then there's the Drush --include-overridden argument to do just that.

Let's say we wish to override the site name via settings.php.

$config['']['name'] = 'My new site name';

To see the default and overridden values with Drush, just type the following.

// Default value $ drush @site.env config-get name '': 'My site name' // Overridden value $ drush @drucker.local config-get name --include-overridden '': 'My new site name'

Or you can use the Drupal API directly.

// Default value >>> $site_name = \Drupal::config('')->getOriginal('name', FALSE); => "My site name" // Overridden value >>> $site_name = \Drupal::config('')->get('name', FALSE); => "My new site name" When to use $settings in Drupal 8?

Let's try to understand the difference with $config. It's clearly explained in \Drupal\Core\Site\Settings

Settings should be used over configuration for read-only, possibly low bootstrap configuration that is environment specific.

settings.php tries to clarify that even more.

$settings contains environment-specific configuration, such as the files directory and reverse proxy address, and temporary configuration, such as security overrides.

In other words, this refers to settings that wouldn't exist in the Configuration Management system. Here's an example. When defining the private path, you don't have a choice but to define it via settings.php.

$settings['file_private_path'] = '/mnt/private/files';

Another example is API keys. You certainly don't want those or other sensitive information to be stored in the configuration and exported in YAML files and/or tracked under version control.

Hopefully that clarifies the difference between $config and $settings. Let me know how you work with them and if I missed anything.

Categories: Drupal

Dynamic Tag Clouds

New Drupal Modules - 16 October 2016 - 11:25pm

This module provides a Tag Cloud based searching of content.

Categories: Drupal

Null auth

New Drupal Modules - 16 October 2016 - 9:46pm
Drupal Null Authentication Provider module

This module is a null authentication provider. Enabling anonymous user access to Drupal 8 REST Resources, using an auto-login method.

WARNING: This module does not control any flood and give auto-login for all requests. Use only in environments with controlled access.

Configuration and usage instructions

There is no specific configuration for this module, it enables automatically a null authentication method. You need to add a _null_auth query parameter to all your requests.

Categories: Drupal

Video Game Deep Cuts: Emotional AI Self-Destructs

Social/Online Games - Gamasutra - 16 October 2016 - 9:00pm

The latest Video Game Deep Cuts, picking the smartest longform video game articles and videos of the week, looks at the 'strange future of emotional AI', a mysterious self-destructing game, & more. ...

Categories: Game Theory & Design

Slushi cache

New Drupal Modules - 16 October 2016 - 3:43pm

A Drupal database cache backend where permanent is really only semi-permanent.

If you're using a database based cache backend and seeing tables like {cache_render} and {cache_dynamic_page_cache} grow over time, then this might be the module for you.


Download and enable the module.


In your settings.php customise the lifetime like so:

Categories: Drupal

Quickbooks Webconnector

New Drupal Modules - 16 October 2016 - 1:49pm

Manage Quickbooks Webconnector endpoints / username / password combinations, generate QWC configuration files, appropriate WSDL file for the QBWC SOAP protocol, implement the QBWC SOAP server protocol, and provide Drupal hooks to send and receive Quickbooks XML (QBXML) queries and responses.

Categories: Drupal

Video Game Deep Cuts: Emotional AI Self-Destructs  - by Simon Carless Blogs - 16 October 2016 - 8:49am
The latest Video Game Deep Cuts, picking the smartest longform video game articles and videos of the week, looks at the 'strange future of emotional AI', a mysterious self-destructing game, & more.
Categories: Game Theory & Design

Get Them To Say Yes! – How To Close Deals In Game Development - by John Velgus Blogs - 16 October 2016 - 4:38am
Knowing how to make and close deals is vital in game development, from the smallest informal favor to big funding opportunities. Use of proper preparation, effective communication, and timely closing will give you the best chances to successfully do so.
Categories: Game Theory & Design

A Dev From The Plains: Upgrading Drupal’s Viewport module to Drupal 8 (Part 3 – Final)

Planet Drupal - 16 October 2016 - 2:44am

Image taken from

With parts one and two of the series covered, this 3rd (and final!) part will cover some other important aspects of Drupal development that I wanted to pay attention to while working on the Drupal 8 version of the viewport module.

Essentially, the kind of aspects that are easy to forget (or ignore on purpose) when a developer comes up with a working version or something “good enough” to be released, and thinks there’s no need to write tests for the existing codebase (we’ve all done it at some point).

This post will be a mix of links to documentation and resources that were either useful or new to me, and tips about some of the utilities and classes available when writing unit or functoinal tests.


Since I wrote both functional tests and unit tests for the viewport module, this section is split in two parts, for the sake of clarity and structure.

- Functional tests

Before getting into the bits and blobs of functional test classes, I decided read a couple articles on the matter, just to see how much testing had changed in the last year(s) in Drupal 8. This article on the existing types of Drupal 8 tests was a good overview, as well as Acquia’s lesson on unit and functional tests.

Other than that, there were also a few change notices I went through in order to understand what was being done with the testing framework and why. TL;DR: Drupal runs away from simpletest and moves to PHPUnit to modernise the test infrastructure. That started by adding the PHPUnit test framework to Drupal core. Also, new classes were added that leveraged PHPUnit instead of the existing Simpletest-based classes. Specifically, a new KernelTestBase was added, and also a BrowserTestBase class, replacing the well-known WebTestBase.

I decided to base all my tests in the PHPUnit classes exclusively, knowing that Simpletest will just die at some point. One of the key requirements for this was to put all test classes in a different path: {module-folder}/tests/src/{test-type}/{test-classes}. Also, the @group annotation was still required, as with Simpletest, so that tests of specific groups or modules can be executed alone, without all the test suite running.

The first thing I noticed when I started to write the first Functional test class, ViewportPermissionsTest, was that the getInfo() method was no longer needed, since it’s been removed in favor of PHPDoc, which means all the info there is retrieved from the documentation block of the test class.

With PHPUnit introduced in Drupal 8, a lot of new features have been added to test classes through PHP Annotations. Without getting into much details, two of them that called my attention when trying to debug a test, were the @runTestsInSeparateProcesses and @preserveGlobalState  annotations. Most of the time the defaults will work for you, although there might be cases where you may want to change them. Note that running tests in separate processes is enabled by default, but some performance issues have been reported on this feature for PHPUnit.

I also came across some issues about the lack of a configuration schema defined for my module, when trying to execute tests in the ViewportTagPrintedOnSelectedPagesTest class, which led me to find another change notice (yeah… too many!) about tests enforcing strict configuration schema adherence by default. The change notice explains how to avoid that (if really necessary), but given that’s not a good practice, you should just add a configuration schema to all your modules, if applicable.

Some other scattered notes of things I noticed when writing functional tests:

  • drupalPostForm() $edit keys need to be the HTML name of the form field being tested, not the field name as defined in the Form API $form array. Same happens with drupalPost().
  • When working on a test class, $this->assertSession()->responseContains() should be used to check HTML contents returned on a page. The change notice about BrowserTestBase class, points to $this->assertSession()->pageTextContains(), but that one is useful only for actual contents displayed on a page, and not the complete HTML returned to the browser.
- Unit Tests

The main difference between unit tests and functional tests (speaking only of structure in the codebase), is that unit tests need to be placed under {module-name}/tests/src/Unit, and they need to extend the UnitTestCase class.

Running PHPUnit tests just requires executing a simple command from the core directory of a Drupal project, specifying the testsuite or the group of tests to be executed, as shown below:

php ../vendor/bin/phpunit –group=viewport

php ../vendor/bin/phpunit –group=viewport –testsuite=unit

As mentioned in the link above, there has to be a properly configured phpunit.xml file within the core folder. Also, note that’s testbot runs tests in a different way. As detailed in the link above, tests can be executed locally in the same way the bot does, to ensure that the setup will allow a given module to receive automated testing support once contributed to

PHPUnit matchers: In PHPUnit parlance, a matcher is ultimately an instance of an object that implements the PHPUnit_Framework_MockObject_Matcher_Invocation interface. In summary, it helps to define the result that would be expected of a method call in an object mock, depending on the arguments passed to the method and the number of times it’s been called. For example:

$this->pathMatcher->expects($this->any()) ->method('getFrontPagePath') ->will($this->returnValue('/frontpage-path'));

That’s telling the pathMatcher mock (don’t confuse with a PHPUnit matcher), to return the value “/frontpage-path” whenever the method getFrontPagePath() is called. However, this other snippet:

$this->pathMatcher->expects($this->exactly(3)) ->method('getFrontPagePath') ->will($this->returnValue('/third-time'));

It’s telling the mock to return the value “/third-time”, only when the getFrontPagePath() method is executed exactly 3 times.

will(): As seen in the examples above, the will() method can be used to tell the object mock to return different values on consecutive calls, or to get the return value processed by a callback, or fetch it from a values map.

These concepts are explained in more detail in the Chapter 9 of the PHPUnit manual.

Coding Standards and Code Sniffer

With the module fully working, and tests written for it, the final stage was to run some checks on the coding standards, and ensure everything is according to Drupal style guides. Code Sniffer makes this incredibly easy, and there’s an entire section dedicated to it in the Site Building Guide at, which details how to install it and run it from the command line.

Finally, and even though I didn’t bother changing the README.txt contents, I also noticed the existence of a README Template file available in the online documentation, handy when contributing new modules. With all the codebase tidied up and proper tests in place, the module was finally good to go.

That’s it! This ends the series of dev diaries about porting the Viewport module to D8. I hope you enjoyed it! There might be a similar blog post about the port process of the User Homepage module, so stay tuned if you’re interested in it.

Links and (re)sources

As usual, I’ll leave a list of the articles and other resources I read while working on the module upgrade.

  • Which D8 test is right for me?: link.
  • Acquia’s lesson on Unit and Functional tests: link.
  • Simpletest Class, File and Namespace structure (D8): link (note Simpletest wasn’t used in the end in the module port).
  • Converting D7 SimpleTests to D8: link.
  • Configuration Schema and Metadata: link.
  • Drupal SimpleTest coding standards: link
  • PHPUnit in Drupal 8: link.
  • Agile Unit Testing: link.
  • Test Doubles in PHPUnit: link.
  • Drupal coding standards: link.
  • README Template file: link.
Change Records and topic discussions
Categories: Drupal

Thumbor Image Formatter

New Drupal Modules - 16 October 2016 - 12:09am
Categories: Drupal

Commerce Jivosite

New Drupal Modules - 15 October 2016 - 12:03pm

Module provides integration with online chat service Jivosite's javascript API.
It exposes basic customer information to your agent's app:

  • User's name (for logged in customers)
  • Cart order total amount
  • Cart order ID and admin area order edit link

You can expose more info by implementing specific -alter hook in your custom module.

You should have Jivosite script already added to you site for this module to work properly.

Categories: Drupal

Review Roundup

Tabletop Gaming News - 15 October 2016 - 11:00am
*puts on Elton John garb* Saturday! Saturday! Saturday! Saturday! Saturday! Saturday! Saturday! Saturday! Saturday night’s alright! Ok, so it’s not actually Saturday night yet, but it will be soon (well, for me. Some of you are already well into Saturday night. Bloody time zones). Anyway, I know what you want. You want some reviews. So […]
Categories: Game Theory & Design

Pirates of Drinax: Theev

New RPG Product Reviews - 15 October 2016 - 10:58am
Publisher: Mongoose
Rating: 5
In the middle of the Sindal Subsector you'll find the three systems that make up the Theev Cluster. Strategically important, it has a bad reputation as a pirate hotspot that encourages many merchants to go the long way around to wherever they are going. They are also remarkably hostile towards the Imperium. For most Traveller players I've met, it's their kind of town!

The Introduction gives the history and background of the cluster along with a map of part of the Sindal Subsector to help you get located. It winds up with a discussion of the Imperial Navy's dealings with the locals.

We then move on to the first of the systems, Vume. It's probably the least hostile system, but that doesn't mean it's a very welcoming place - and that's not just because the main planet is an airless, waterless rockball of a world! Most life is found on the orbital highport, although people venture to the surface to explore some ancient ruins... billed as an Ancients site although nobody is really sure if it was them or some other long-lost race who built the ruins. They are now inhabited by some quite peculiar folks.

Next we read about the Theev system. Now a bit of a backwater if not pretty much abandoned altogether, it used to be part of a major trade route. Their highport was bored out of a moonlet artificially placed in a geostationary orbit around the main world. It is not recommended to break the law here, as they don't go in for the nicities of law courts and endless appeals - perpetrators are merely shown out of an airlock... and that's the official law enforcement by a black-robed bunch called the Widows. Travel to the downport is discouraged, and as the world is arid and very dusty, people generally only go there on business - or hunting for rumoured treasures outside of the controlled environment that protects the one inhabited city that has grown up around it. The place is ruled by the Pirate Lords, and the Widows enforce their rule at least in the Upper City. The Lower City is darker and meaner...

Finally comes Palindrome, the third system in the cluster. It's a run-down backwater, even the highport is scruffy and half-abandoned, even though it still claims to be Class B. The planet below is uninviting, with a thin atmosphere and little surface water and a single domed settlement called Astrogo which is run as the personal property of a retired pirate, the Lady Yemar. Here, the standard of living is high, supported by a TL of 12, and the community is quite insular and inward-looking. It is a good place to find those 'special' items not on sale elsewhere, and a haven for fugitives. The place is quite welcoming to outsiders provided they don't strut around in Imperial uniforms.

This is an intriguing group of worlds likely to prove popular with the ethically-challenged. Each is brought to life in the concise notes provided, although you will have to provide even the notable inhabitants and any maps you might need, even the rest of the systems are not well-developed. When your party decides to go 'shopping', send them here.
Categories: Game Theory & Design


New Drupal Modules - 15 October 2016 - 6:18am

The GreatSchools API is a REST-based web service.

You need this module if you need simple and "Drupal way" access to GreatSchools.

Right now module allows you to do requests for these endopoints:

Categories: Drupal


Subscribe to As If Productions aggregator