Newsfeeds

Wet Hot American Summer : Fantasy Camp RPG Up On Kickstarter

Tabletop Gaming News - 20 April 2017 - 10:00am
Who here remembers MTv’s The State? I certainly do. It’s one of my favorite sketch comedy shows (probably because it was one of the first I ever had seen, though I do think it holds up over the years). Well, many of the people involved with that went on to other projects. One such was […]
Categories: Game Theory & Design

Mediacurrent: Dropcast: Episode 31 - DRUPALCON

Planet Drupal - 20 April 2017 - 9:58am
Dropcast: Episode 31 - DRUPALCON

Recorded April 12th, 2017

Categories: Drupal

Gale Force Nine Looking For Help at Summer Conventions

Tabletop Gaming News - 20 April 2017 - 9:00am
I have never been to a convention where I wasn’t working for some gaming company. Back in the day, it was Privateer Press, doing things like running Tour of Duty for 40 hours, or Iron Arena (where, among other shifts, I once did a 24 hour shift). Then, of course, once I took over this […]
Categories: Game Theory & Design

The Accidental Coder: The State-of-Drupal Poll

Planet Drupal - 20 April 2017 - 8:25am

Speak out about your feelings on several topics that are swirling in the Drupalsphere. The results of the poll will be published here during Drupalcon Baltimore. 

Take the Poll!

Tags: Drupal Planet
Categories: Drupal

React VR

New Drupal Modules - 20 April 2017 - 8:10am
What is React VR ?

React VR is a framework for the creation of VR applications that run in your web browser.
It pairs modern APIs like WebGL and WebVR with the declarative power of React, producing experiences that can be consumed through a variety of devices.
Leveraging web technologies and the existing React ecosystem, React VR aims to simplify the construction of 360 experiences and democratize the creation of VR content. I
f you're familiar with React, you can now build in VR – learn once, write anywhere.

Categories: Drupal

Hannibal & Hamilcar Board Game Up On Kickstarter

Tabletop Gaming News - 20 April 2017 - 8:00am
Most of us know about Hannibal and his elephants. But what about Hamilcar, his father? He, too, was a great military leader and led battles for Carthage against Rome. Those two cities fought it out quite a lot over the years (and we know that Rome eventually prevailed). Soon, you’ll be able to bring those […]
Categories: Game Theory & Design

Post mortem for Meganoid 2017 - by Pascal Bestebroer

Gamasutra.com Blogs - 20 April 2017 - 7:13am
Post mortem for Meganoid(2017). A roguelike - platformer released on iOS,Android and Steam three weeks ago, some insights on the launch-period stats and results so far.
Categories: Game Theory & Design

Built for Sin: Guilt as Gameplay - by Ian McCamant

Gamasutra.com Blogs - 20 April 2017 - 7:13am
A look at the philosophical basis for morality as a mechanic in choice-driven games.
Categories: Game Theory & Design

Yonder: The Cloud Catcher Chronicles An Episodic Audio Journal, Episode Two: 40 Species of Noise - by Stephan Schutze

Gamasutra.com Blogs - 20 April 2017 - 7:12am
A multi part development journal that will discuss the dynamic music and SFX for the open world of Yonder: The Cloud Catcher Chronicles and examine the risks and challenges encountered. Part II
Categories: Game Theory & Design

Ostfront Publishing Releases Westfront WWI Miniatures Game

Tabletop Gaming News - 20 April 2017 - 7:00am
In my opinion, WWI is really what set the foundation for the rest of the 20th century. I wish it was as prevalent in popular culture as WWII is. So every time I see a new game come out based on WWI, it makes me happy, as it brings the conflict back into mind. So […]
Categories: Game Theory & Design

Important Notification

New Drupal Modules - 20 April 2017 - 6:34am

Provide Global Notification for Admin Section.

The concept is to provide a tool that serves two notifications to Drupal users when they log into the site:

1. When the admin user first logs into Drupal.
2. As a notification on all Drupal admin pages.

Categories: Drupal

Chromatic: Replacing hook_boot and hook_init Functionality in Drupal 8

Planet Drupal - 20 April 2017 - 6:15am

Adam uncovers methods of firing code on every page in Drupal 8, the right way.

Categories: Drupal

IDW Games Launches Rayguns & Rocketships Kickstarter

Tabletop Gaming News - 20 April 2017 - 6:00am
10… 9… 8… 7… 6… 5… 4… 3… 2… 1… Blast off! And that’s just what IDW Games has done with their new retro-sci-fi board game, Rayguns & Rocketships. They’ve taken to the Kickstarter launchpad and are go. Grab your fishbowl helmet, ringed space suit, and head out for adventure. From the campaign: Designed by […]
Categories: Game Theory & Design

Zivtech: Empowering Drupal 8 Content Editors with EVA: Attach All the Displays!

Planet Drupal - 20 April 2017 - 6:00am

Entity Views Attachment, or EVA, is a Drupal module that allows you to attach view displays to entities of your choosing. We used it recently on a project and loved it. You know it’s good because it has a no-nonsense name and an even better acronym. (Plus, the maintainers have taken full advantage of the acronym and placed a spaceman on the project page. Nice!)

Since the now-ubiquitous Paragraphs module provides the “paragraph” entity type, I figured these two will make good dancing partners.

Getting them to tango is simple enough. You create a paragraph bundle, target that bundle in the settings on an EVA view display, then arrange the view in the paragraph’s display settings. Voila – your view display shows up wherever you add this paragraph!

By attaching a view display to a paragraph entity and enabling that paragraph on a node’s paragraph reference field, you give your content editors the ability to place a view wherever they want within their page content. Better still, they can contextualize what they are doing since this all happens in the edit form where the rest of the node content lives. As far as I can tell, no other approach in the Drupal ecosystem (I’m looking at you Blocks and Panels) makes adding views to content this easy for your editors.

Case Study

The concept is pretty straightforward, but with a little cleverness it allows you to build some complex page elements. Let’s walk through an example. Consider the following design:

This mockup represents Section nodes and lists of Subpage nodes that reference them. In addition, the buttons links should point to the parent Section node. With a little elbow grease, we can build a system to output this with our friends EVA and Paragraphs.

Here’s how I’m breaking this down conceptually:

We have three things to build:

  1. A create a container paragraph bundle

  2. A child paragraph bundle with a Section entity reference field

  3. An EVA of subpages to attach to the child paragraph bundle

Building the Subpage EVA

As I mentioned before, Subpage nodes will reference Section nodes. With this in mind, we can build the EVA that lists subpages and expects a section node ID to contextually filter to subpages that reference that node.

Building the Section paragraph type

Next, we’ll create the Section paragraph type that will handle each grouping of a section node with its related subpages. The Section paragraph will have one field, an entity reference field limited to Section nodes, that gives us all the data we need from our section.

We’ll attach our EVA to this paragraph type and configure it to pass the referenced node’s ID as the contextual filter using tokens in the EVA settings. You will need to install the Token module to do this. Go to /admin/help/token to see all available tokens once installed. You need to grab the node ID through your entity reference field, so your token argument should look something like this:

[paragraph:field_node_reference:entity:nid]

We pass that token to our contextual filter, and we can tell our view to use that argument to create a link to the section node for our “View All Subpages” link. To do this, we’ll add a global text area to the view footer and check the “Use replacement tokens from the first row” checkbox. Then we’ll write some HTML to create a link. It’ll look something like this:

<a href="/node/{{ raw_arguments.nid }}">View all Subpages</a> Building the Section List paragraph type

Lastly, we’ll create the Section List paragraph type. This only really needs a paragraph reference field that only allows the user to add Section paragraphs, but I also added a title field that will act as a header for the whole list.

Tip: Install Fences module to control your field’s wrapper markup. I used this here to wrap the title in <h2> tags.

We’re finished!

Now that everything is built, we can allow users to select the Section List paragraph type in a paragraph reference field of our choosing. A user adds a Section List, then adds Sections via the entity reference. It looks like this in the node edit form:

Do you have any cool ways you use the EVA module in your builds? Let us know in the comments section below.

Categories: Drupal

Evolving Web: Migrate translations from CSV, JSON or XML to Drupal 8

Planet Drupal - 20 April 2017 - 5:38am

In my last post, I showed you how to migrate translated content from Drupal 6 to Drupal 8. But clients often don't start with their data in Drupal 6. Instead there's some other source of data that may include translations, like a CSV spreadsheet. In this article, I'll show you how to migrate multilingual content from such sources to Drupal 8.

This article would not have been possible without the help of my colleague Dave. Gracias Dave!

The problem

We have two CSV files containing some data about chemical elements in two languages. One file contains data in English and the other file, in Spanish. Our goal is to migrate these records into a Drupal 8 website, preserving the translations.

Before we start
  • Since this is an advanced migration topic, it is assumed you already know the basics of migration.
  • To execute the migrations in this example, you can download the migrate example i18n. The module should work without any trouble for a standard Drupal 8 install. See quick-start for more information.
Migrating JSON, XML and other formats

Though this example shows how to work with a CSV data source, one can easily work with other data sources. Here are some quick pointers:

  • Find and install the relevant migrate source module. If you do not have a standard source module available, you can:
    • try converting your data to a supported format first.
    • write your own migration source plugin, if you're feeling adventurous.
  • Modify the migration definitions to include custom parameters for the data source.
  • Some useful source formats are supported by these projects:
The module

To write the migrations, we create a module—in our case, it is named migrate_example_i18n. There's nothing special about the module declaration except for the dependencies:

How to migrate translations

    Before we start writing migrations, it is important to mention how Drupal 8 translations work. In a nutshell:

    • First, we create content in its base language, say in English. For example, we could create a brand new node for the element Hydrogen, which might have a unique node ID 4.
    • Now that the base node is in place, we can translate the node, say to Spanish. Unlike some previous versions of Drupal, this won't become a new node with its own node ID. Instead, the translation is saved against the same node generated above, and so will have the same node ID—just a different language setting.

    Hence, the migration definition for this example includes the following:

    • We migrate the base data in English using in example_element_en migration.
    • We migrate the Spanish translations using the example_element_es migration, and link each translation to the original English version.
    • We group the two migrations in the example_element migration group to keep things clean and organized.

    Thus, we can execute the migrations of this example with the command drush migrate-import --group=example_element.

    Warning

    Note that this plan only works because every single node we are importing has at least an English translation! If some nodes only existed in Spanish, we would not be able to link them to the (non-existent) original English version. If you encounter data like this, you'll need to handle it in a different way.

    Step 1: Element base migration (English)

    To migrate the English translations, we define the example_element_en migration. Here is a quick look at some important parameters used in the migration definition.

    Source source: plugin: csv path: 'element.data.en.csv' header_row_count: 1 keys: - Symbol fields: Name: 'Name' Symbol: 'Symbol' 'Atomic Number': 'Atomic number' 'Discovered By': 'Name of people who discovered the element' constants: lang_en: en node_element: 'element'
    • plugin: Since we want to import data from a CSV file, we need to use the csv plugin provided by the migrate_source_csv module.
    • path: Path to the CSV data source so that the source plugin can read the file. Our source files for this example actually live within our module, so we modify this path at runtime using hook_migration_plugins_alter() in migrate_example_i18n.module.
    • header_row_count: Number of initial rows in the CSV file which do not contain actual data. This helps ignore column headings.
    • keys: The column(s) in the CSV file which uniquely identify each record. In our example, the chemical symbol in the column Symbol is unique to each row, so we can use that as the key.
    • fields: A description for every column present in the CSV file. This is used for displaying source details in the UI.
    • constants: Some static values for use during the migration.
    Destination destination: plugin: 'entity:node'
    • plugin: Nothing fancy here. We aim to create node entities, so we set the plugin as entity:node.
    • translations: Since we are importing the content in base language, we do not specify the translations parameter. This will make Drupal create new nodes for every record.
    Process process: type: constants/node_element title: Name langcode: constants/lang_en field_element_symbol: Symbol field_element_discoverer: plugin: explode delimiter: ', ' source: Discovered By

    This is where we map the columns of the CSV file to properties of our target nodes. Here are some mappings which require a special mention and explication:

    • type: We hard-code the content type for the nodes we wish to create, to type element.
    • langcode: Since all source records are in English, we tell Drupal to save the destination nodes in English as well. We do this by explicitly specifying langcode as en.
    • field_element_discoverer: This field is a bit tricky. Looking at the source data, we realize that every element has one or more discoverers. Multiple discoverer names are separated by commas. Thus, we use plugin: explode and delimiter: ', ' to split multiple records into arrays. With the values split into arrays, Drupal understands and saves the data in this column as multiple values.

    When we run this migration like drush migrate-import example_element_en, we import all the nodes in the base language (English).

    Step 2: Element translation migration (Spanish)

    With the base nodes in place, we define a migration similar to the previous one with the ID example_element_es.

    source: plugin: csv path: 'element.data.es.csv' header_row_count: 1 keys: - 'Simbolo' constants: lang_en: en # ... destination: plugin: 'entity:node' translations: true process: nid: plugin: migration source: Simbolo migration: example_element_en langcode: constants/lang_es content_translation_source: constants/lang_en # ... migration_dependencies: required: - example_element_en

    Let us look at some major differences between the example_element_es migration and the example_element_en migration:

    • source:
      • path: Since the Spanish node data is in another file, we change the path accordingly.
      • keys: The Spanish word for Symbol is Símbolo, and it is the column containing the unique ID of each record. Hence, we define it as the source data key. Unfortunately, Drupal migrate support keys with non-ASCII characters such as í (with its accent). So, as a workaround, I had to remove all such accented characters from the column headings and write the key parameter as Simbolo, without the special í.
      • fields: The field definitions had to be changed to match the Spanish column names used in the CSV.
    • destination:
      • translations: Since we want Drupal to create translations for English language nodes created during the example_element_en migration, we specify translations: true.
    • process:
      • nid: We use the plugin: migration to make Drupal lookup nodes which were created during the English element migration and use their ID as the nid. This results in the Spanish translations being attached to the original nodes created in English.
      • langcode: Since all records in element.data.es.csv are in Spanish, we hard-code the langcode to es for each record of this migration. This tells Drupal that these are Spanish translations.
      • content_translation_source: Each translation of a Drupal node comes from a previous translation—for example, you might take the Spanish translation, and translate it into French. In this case, we'd say that Spanish was the source language of the French translation. By adding this process step, we tell Drupal that all our Spanish translations are coming from English.
    • migration_dependencies: This ensures that the base data is migrated before the translations. So to run this migration, one must run the example_element_en migration first.

    Voilà! Run the Spanish migration (drush migrate-import example_element_es) and you have the Spanish translations for the elements! We can run both the English and Spanish migration at once using the migration group we created. Here's how the output should look in the command-line:

    $ drush migrate-import --group=example_element Processed 111 items (111 created, 0 updated, 0 failed, 0 ignored) - done with 'example_element_en' Processed 105 items (105 created, 0 updated, 0 failed, 0 ignored) - done with 'example_element_es'

    If we had another file containing French translations, we would create another migration like we did for Spanish, and import the French data in a similar way. I couldn't find a CSV file with element data in French, so I didn't include it in this example—but go try it out on your own, and leave a comment to tell me how it went!

    Next steps + more awesome articles by Evolving Web
    Categories: Drupal

    Dropsolid: Making a difference, One Drupal security patch at a time

    Planet Drupal - 20 April 2017 - 4:52am
    20 Apr Making a difference, one Drupal security patch at a time Nick Advisory by the Drupal security team

    Recently, the References module started receiving some attention (read here, here and here). The reason for this is that the Drupal security team posted an advisory to migrate away from the References module for Drupal 7 and move to the entity_reference module. At the time of writing (20 April), 121.091 sites are actively reporting to Drupal.org that they are using this module. That makes for a lot of unhappy developers.

    Things kicked off after a security vulnerability was discovered in the References module. The security team tried to contact the existing maintainers of that module, but there was no response. The security team had no choice but to mark the module as abandoned and send out the following advisory explaining that the details would be made public in a month and that everyone should upgrade, as there was no fix available.

    Migrate efficiently

    At Dropsolid, we noticed that for many of our older Drupal 7 installs we were still using this module extensively. Migrating all of the affected sites would have meant a very lengthy undertaking, so I was curious to find a way to spend less time and effort while still fixing the problem. We immediately contacted one of the people who reported the security issue and tried to get more information other than what was publicly available. That person stayed true to the rules and did not disclose any information about the issue.

    We didn’t give up, but made an official request to the security team offering to help and requesting access to the security vulnerability issue. The Drupal security team reviewed the request and granted me access. In the Drupal Security issue queue there was some historical information about this vulnerability, some answers and a proposed patch. The patch had not been tested, but this is where Dropsolid chimed in. After extensively testing the patch on all the different scenarios on an actual site that was vulnerable, we marked the issue as Reviewed and Tested by the Community (RTBC) and stepped up maintain the References module for future security issues.

    It pays off to step in

    I’d like to thank Niels Aers, one of my colleagues, as his involvement was critical in this journey and he is now the current maintainer of this module. He jumped straight in without hesitation. In the end, we spent less time fixing the actual issue compared to the potential effort for changing all our sites to use a different module. So remember: you can also make a similar impact to the Drupal community by stepping up when something like this happens. Do not freak out, but think how you can help your clients, company and career by fixing something for more than just you or your company.

    Categories: Drupal

    Virtual Entities

    New Drupal Modules - 20 April 2017 - 3:27am
    Categories: Drupal

    Obfuscate

    New Drupal Modules - 20 April 2017 - 2:32am

    Obfuscates email addresses as a Field Formatter of the core Email field.

    Provides a simple and flexible way to prevent spam by using the core default Email field.
    For some reasons, you should prefer to leave the field formatter of some view modes to Plain text or Email.
    All the view modes (default / full, teaser, search index, ...) that exposes publicly email addresses should define the fields to Obfuscate.

    Credits to Alexei Tenitski for the obfuscation solution on the first release.

    Categories: Drupal

    Pronovix: Documenting web APIs with the Swagger / OpenAPI specification in Drupal

    Planet Drupal - 20 April 2017 - 1:19am

    As part of our work to make Drupal 8 the leading CMS for developer portals, we are implementing a mechanism to import the OpenAPI (formerly known as Swagger) specification format. This is a crucial feature not only for dedicated developer portals, but also for all Drupal sites that are exposing an API. Now that it has become much easier to create a RESTful API service in Drupal 8, the next step is to make it more straightforward to create its API reference documentation. That is why we think our work will be useful for site builders, and not just for technical writers and API product owners.

    Categories: Drupal

    Lawful GM: Auctions

    RPGNet - 20 April 2017 - 12:00am
    Lessons learned from an auction LARP.
    Categories: Game Theory & Design

    Pages

    Subscribe to As If Productions aggregator