Drupal core announcements: 8.7.0-alpha1 deadline moved to March 11

Planet Drupal - 11 February 2019 - 9:42am

Last fall, we adjusted our minor release date for Drupal 8.7.0 from March 6 to May 1. This was done as part of moving Drupal's minor release schedule toward a consistent schedule that will have minor releases in the first weeks of June and December each year. (See Plan for Drupal 9 for more information on why we are making this change.)

However, the change to the 8.7.0 release date means that DrupalCon Seattle now falls in the middle of important preparation phases for the minor release. In order to ensure community members have adequate time to prepare and test the release without interfering with DrupalCon Seattle events, we've moved the alpha and beta phases for the release one week earlier:

  • 8.7.0-alpha1 will now be released the week of March 11. The alpha phase will last two weeks until the release window for beta1.
  • 8.7.0-beta1 will now be released the week of March 25. The beta phase will now last three weeks (including the week of DrupalCon) instead of two. The beta phase will still end when the release candidate window begins.
  • The release candidate (RC) and release dates are unchanged. The RC window still begins April 15 and the scheduled release date is still May 1.

(Read more about alpha, beta, and RC phases.)

Categories: Drupal

Thunderballs VR - #2 - Friends and Physics - by Daniel Yawitz Blogs - 11 February 2019 - 8:54am
The second post in a series that chronicles the development of Thunderballs VR by Megafauna
Categories: Game Theory & Design

Mesmer DevBlog: Swaying others - by Peter Wingaard Meldahl Blogs - 11 February 2019 - 8:52am
There are those in life who are just way better than others at making people do what they want. But how to express this in games? Resources and influence are the core of Mesmer. I will go into the process of swaying individuals today.
Categories: Game Theory & Design

Gay in the Game Industry: Research from the Field - by Alexander Ruiz Blogs - 11 February 2019 - 8:52am
In this blog post, I share my preliminary results regarding the experiences of LGBTQ employees working in the video game industry. I also share some potential solutions that companies could implement to be more supportive of their LGBTQ employees.
Categories: Game Theory & Design

Publishing 102 - How to Find the Best Game Publisher for You - by David Logan Blogs - 11 February 2019 - 8:49am
Join CEO of Akupara Games, David Logan, as he continues his Publishing series. Look into the topics you will want to think about when it comes to finding publishers to talk with.
Categories: Game Theory & Design

How Does the Future of the Streamer-Developer Relationship Look? - by Richard Atlas Blogs - 11 February 2019 - 8:48am
This blog post asks some questions about the relationship between developer and streamer, the cash flow between them, and the cash flow in the entire system including platforms like Twitch and YouTube, advertisers, and viewers.
Categories: Game Theory & Design

Video game music composer: Getting your big break - by Winifred Phillips Blogs - 11 February 2019 - 8:48am
Game composer Winifred Phillips discusses ways for new game composers to achieve their first professional gig. Article includes advice regarding the preparation of demo reels, strategies for effective networking, and a list of links and resources.
Categories: Game Theory & Design

Connection Plugins

New Drupal Modules - 11 February 2019 - 8:47am

The aim of this module is to provide a bridge so that users can more easily put together API connections when wiring together decoupled applications. The solution, in Drupal-speak, is to use some different plugin types.

Categories: Drupal

Know Thy Enemy: Designing for Yomi in Games - by Caleb Compton Blogs - 11 February 2019 - 8:46am
One of the most satisfying feelings in any competitive game is being able to perfectly predict and counter your opponent's moves. This feeling is called Yomi, and it doesn't come for free. This article looks at how to design your game to allow Yomi.
Categories: Game Theory & Design

Sonar Beat: Basics of a unique rhythm game - by Miguel Valles Susin Blogs - 11 February 2019 - 8:34am
How we merged musical and arcade mechanics into one solid, innovative experience
Categories: Game Theory & Design

Basic Data

New Drupal Modules - 11 February 2019 - 8:21am

Basic Data is a content entity that ships with an additional data property. The entity type is basic_data and you may add any fielded bundles you'd need.

The primary use case for a basic_data entity and NOT a node entity is not complicated. Nodes do not come with a data property that is required. If you have no data to store in a basic_data entity, consider using Migrate or some custom code to create nodes with fields that make up the appropriate structured content.

Categories: Drupal

Simple Slim API

New Drupal Modules - 11 February 2019 - 6:41am

This module creates an API for Drupal nodes and users using the Slim Framework.

Slim is a PHP micro framework that helps you quickly write simple yet powerful web applications and APIs.
At its core, Slim is a dispatcher that receives an HTTP request, invokes an appropriate callback routine, and returns an HTTP response.
That’s it.

Categories: Drupal

Acquia Developer Center Blog: Building Usable Conversations: Conversational Content Strategy

Planet Drupal - 11 February 2019 - 6:34am

In this fourth installment of our series on conversational usability, we're turning our attention to conversational content strategy, an underserved area of conversational interface design that is rapidly growing due to the number of enterprises eager to convert the text trapped in their websites into content that can be consumed through voice assistants and chatbots.

Tags: acquia drupal planet
Categories: Drupal

The Airy Peaks – Point Crawling (03)

Gnome Stew - 11 February 2019 - 6:00am

There are a lot of areas that are a part of the Airy Peaks, twenty-three last time I counted but I might have lost some and added some along the way that I’m forgetting about. These aren’t twenty-three rooms — they are twenty-four adventure locations. It’s intended to be a massive place and I wanted it to feel like that. In doing that I needed to solve a couple of problems when drawing it up. The first was how do I connect all the areas of the Peaks? The second was how can the characters travel the Peaks without it feeling like a slog? So let’s solve them.

The Point Crawl

The point crawl is an alternative to the hex crawl and mapping out every continuous connection in a dungeon. It looks a lot like a mind map and connects larger areas to each other by lines. That’s how I initially drew up the Airy Peaks. In doing this I created some distinct areas as parts of individual mountains, but I wanted a way for characters to really get around so I created the Fire Tube Tunnels. These round tunnels are beneath the Peaks and connect all the lower and some of the higher area caverns. Within the Fire Tube Tunnels are also some larger caverns that aren’t in a mountain. I also had some of the areas outside of the mountains such as the Ever Burning Forest, The Remnants of the Great Forest, and The Vale of Bones. With that done I had connected the Peaks and had given a way for the characters to travel them, but the Fire Tube Tunnels created a new problem. There was never going to be a way to map them out. They just connected things. That meant I needed to decide how the characters would find their way around the Fire Tube Tunnels. My answer was the Town of Foot and a custom move.


I talked a bit about Foot in the first article. It’s a home base that matters. One of the reasons it matters is because adventurers flock to the location, explore the Peaks, make maps, sell those maps, and learn rumors. One of the ways I evolved the story of the Peaks was letting the characters have maps that would lead them to new locations in the mountain range. These maps were described as hand written and were annotated by different adventurers depending on how old they were. The other side of the equation were rumors. The rumors were heard and shared over drinks at the Red Scales Inn. These rumors often prompted the characters to go on adventures to find whatever the rumors were pointing them to.

With maps, rumors and a move called Carouse, I had a lot of tools at my disposal to drop story seeds and adventure hooks to the characters. It made it really easy to prompt the characters into action, since most of them were looking go in after treasure. Even if they weren’t they’d just go look for adventure. With the maps and moves I had it let me improvise a night of adventure anyways.

Moving about the Peaks

Now that I had a way for the characters to move around the mountain range and several ways to hook them into adventures, I needed to mechanize moving around the mountain range. So there were a couple of ways. I created a custom move for Navigating the Fire Tube Tunnels and I would also just let them get where they were going if they had a map that led them there. So maps were more valuable than rumors, and any place that was connected by the Fire Tube Tunnels that needed to be navigated had a mechanism.

In Dungeon World I used the move but in other games a random encounter mechanism could be used, such as roll a d6 and on a 6 you encounter trouble of the GMs choosing. That could even be modified to be roll a d6 and on a 3+ you encounter trouble of the GMs choosing. I had a lot of things that could cause trouble in the Fire Tube Tunnels. It could also be roll on a random table instead of the trouble being of the GMs choosing. That’s completely up to how a GM would handle it.

Here’s the custom move I used:

When Navigating the Fire Tube Tunnels have one person designated as the scout and roll + WIS.

  • On a 10+ the party reaches the location without incident.
  • On a 7-9 the party encounters something interesting. It could be trouble but it might just be interesting.
  • On a 6- the party finds themselves in a difficult situation with the person who rolled choosing who gets the XP for the 6-. That member of the party is in a particularly difficult spot.
Categories: Game Theory & Design

Dries Buytaert: Headless CMS: REST vs JSON:API vs GraphQL

Planet Drupal - 11 February 2019 - 5:59am

The web used to be server-centric in that web content management systems managed data and turned it into HTML responses. With the rise of headless architectures a portion of the web is becoming server-centric for data but client-centric for its presentation; increasingly, data is rendered into HTML in the browser.

This shift of responsibility has given rise to JavaScript frameworks, while on the server side, it has resulted in the development of JSON:API and GraphQL to better serve these JavaScript applications with content and data.

In this blog post, we will compare REST, JSON:API and GraphQL. First, we'll look at an architectural, CMS-agnostic comparison, followed by evaluating some Drupal-specific implementation details.

It's worth noting that there are of course lots of intricacies and "it depends" when comparing these three approaches. When we discuss REST, we mean the "typical REST API" as opposed to one that is extremely well-designed or following a specification (not REST as a concept). When we discuss JSON:API, we're referring to implementations of the JSON:API specification. Finally, when we discuss GraphQL, we're referring to GraphQL as it used in practice. Formally, it is only a query language, not a standard for building APIs.

The architectural comparison should be useful for anyone building decoupled applications regardless of the foundation they use because the qualities we will evaluate apply to most web projects.

To frame our comparisons, let's establish that most developers working with web services care about the following qualities:

  1. Request efficiency: retrieving all necessary data in a single network round trip is essential for performance. The size of both requests and responses should make efficient use of the network.
  2. API exploration and schema documentation: the API should be quickly understandable and easily discoverable.
  3. Operational simplicity: the approach should be easy to install, configure, run, scale and secure.
  4. Writing data: not every application needs to store data in the content repository, but when it does, it should not be significantly more complex than reading.

We summarized our conclusions in the table below, but we discuss each of these four categories (or rows in the table) in more depth below. If you aggregate the colors in the table, you see that we rank JSON:API above GraphQL and GraphQL above REST.

REST JSON:API GraphQL Request efficiency Poor; multiple requests are needed to satisfy common needs. Responses are bloated. Excellent; a single request is usually sufficient for most needs. Responses can be tailored to return only what is required. Excellent; a single request is usually sufficient for most needs. Responses only include exactly what was requested. Documentation, API explorability and schema Poor; no schema, not explorable. Acceptable; generic schema only; links and error messages are self-documenting. Excellent; precise schema; excellent tooling for exploration and documentation. Operational simplicity Acceptable; works out of the box with CDNs and reverse proxies; few to no client-side libraries required. Excellent; works out of the box with CDNs and reverse proxies, no client-side libraries needed, but many are available and useful. Poor; extra infrastructure is often necessary client side libraries are a practical necessity, specific patterns required to benefit from CDNs and browser caches. Writing data Acceptable; HTTP semantics give some guidance but how specifics left to each implementation, one write per request. Excellent; how writes are handled is clearly defined by the spec, one write per request, but multiple writes is being added to the specification. Poor; how writes are handled is left to each implementation and there are competing best practices, it's possible to execute multiple writes in a single request.

If you're not familiar with JSON:API or GraphQL, I recommend you watch the following two short videos. They will provide valuable context for the remainder of this blog post:

Request efficiency

Most REST APIs tend toward the simplest implementation possible: a resource can only be retrieved from one URI. If you want to retrieve article 42, you have to retrieve it from If you want to retrieve article 42 and article 72, you have to perform two requests; one to and one to If the article's author information is stored in a different content type, you have to do two additional requests, say to and Furthermore, you can't send these requests until you've requested, retrieved and parsed the article requests (you wouldn't know the author IDs otherwise).

Consequently, client-side applications built on top of basic REST APIs tend to need many successive requests to fetch their data. Often, these requests can't be sent until earlier requests have been fulfilled, resulting in a sluggish experience for the website visitor.

GraphQL and JSON:API were developed to address the typical inefficiency of REST APIs. Using JSON:API or GraphQL, you can use a single request to retrieve both article 42 and article 72, along with the author information for each. It simplifies the developer experience, but more importantly, it speeds up the application.

Finally, both JSON:API and GraphQL have a solution to limit response sizes. A common complaint against typical REST APIs is that their responses can be incredibly verbose; they often respond with far more data than the client needs. This is both annoying and inefficient.

GraphQL eliminates this by requiring the developer to explicitly add each desired resource field to every query. This makes it difficult to over-fetch data but easily leads to very large GraphQL queries, making (cacheable) GET requests impossible.

JSON:API solves this with the concept of sparse fieldsets or lists of desired resource fields. These behave in much the same fashion as GraphQL does, however, when they're omitted JSON:API will typically return all fields. An advantage, though, is that when a JSON:API query gets too large, sparse fieldsets can be omitted so that the request remains cacheable.

REST JSON:API GraphQL Multiple data objects in a single response Usually; but every implementation is different (for Drupal: custom "REST Export" view or custom REST plugin needed). Yes Yes Embed related data (e.g. the author of each article) No Yes Yes Only needed fields of a data object No Yes; servers may choose sensible defaults, developers must be diligent to prevent over-fetching. Yes; strict, but eliminates over-fetching, at the extreme, it can lead to poor cacheability. Documentation, API explorability and schema

As a developer working with web services, you want to be able to discover and understand the API quickly and easily: what kinds of resources are available, what fields does each of them have, how are they related, etc. But also, if this field is a date or time, what machine-readable format is the date or time specified in? Good documentation and API exploration can make all the difference.

REST JSON:API GraphQL Auto-generated documentation Depends; if using the OpenAPI standard. Depends; if using the OpenAPI standard (formerly, Swagger). Yes; various tools available. Interactivity Poor; navigable links rarely available. Acceptable; observing available fields and links in its responses enable exploration of the API. Excellent; autocomplete feature, instant results or compilation errors, complete and contextual documentation. Validatable and programmable schema. Depends; if using the OpenAPI standard. Depends; the JSON:API specification defines a generic schema, but a reliable field-level schema is not yet available. Yes; a complete and reliable schema is provided (with very few exceptions).

GraphQL has superior API exploration thanks to GraphiQL (demonstrated in the video above), an in-browser IDE of sorts, which lets developers iteratively construct a query. As the developer types the query out, likely suggestions are offered and can be auto-completed. At any time, the query can be run and GraphiQL will display real results alongside the query. This provides immediate, actionable feedback to the query builder. Did they make a typo? Does the response look like what was desired? Additionally, documentation can be summoned into a flyout, when additional context is needed.

On the other hand, JSON:API is more self-explanatory: APIs can be explored with nothing more than a web browser. From within the browser, you can browse from one resource to another, discover its fields, and more. So, if you just want to debug or try something out, JSON:API is usable with nothing more than cURL or your browser. Or, you can use Postman (demonstrated in the video above) — a standalone environment for developing on top of an any HTTP-based API. Constructing complex queries requires some knowledge, however, and that is where GraphQL's GraphiQL shines compared to JSON:API.

Operational simplicity

We use the term operational simplicity to encompass how easy it is to install, configure, run, scale and secure each of the solutions.

The table should be self-explanatory, though it's important to make a remark about scalability. To scale a REST-based or JSON:API-based web service so that it can handle a large volume of traffic, you can use the same approach websites (and Drupal) already use, including reverse proxies like Varnish or a CDN. To scale GraphQL, you can't rely on HTTP caching as with REST or JSON:API without persisted queries. Persisted queries are not part of the official GraphQL specification but they are a widely-adopted convention amongst GraphQL users. They essentially store a query on the server, assign it an ID and permit the client to get the result of the query using a GET request with only the ID. Persisted queries add more operational complexity, and it also means the architecture is no longer fully decoupled — if a client wants to retrieve different data, server-side changes are required.

REST JSON:API GraphQL Scalability: additional infrastructure requirements Excellent; same as a regular website (Varnish, CDN, etc). Excellent; same as a regular website (Varnish, CDN, etc). Usually poor; only the simplest queries can use GET requests; to reap the full benefit of GraphQL, servers needs their own tooling. Tooling ecosystem Acceptable; lots of developer tools available, but for the best experience they need to be customized for the implementation. Excellent; lots of developer tools available; tools don't need to be implementation-specific. Excellent; lots of developer tools available; tools don't need to be implementation-specific. Typical points of failure Fewer; server, client. Fewer; server, client. Many; server, client, client-side caching, client and build tooling. Writing data

For most REST APIs and JSON:API, writing data is as easy as fetching it: if you can read information, you also know how to write it. Instead of using the GET HTTP request type you use POST and PATCH requests. JSON:API improves on typical REST APIs by eliminating differences between implementations. There is just one way to do things and that enabled better, generic tooling and less time spent on server-side details.

The nature of GraphQL's write operations (called mutations) means that you must write custom code for each write operation; unlike JSON:API the specification, GraphQL doesn't prescribe a single way of handling write operations to resources, so there are many competing best practices. In essence, the GraphQL specification is optimized for reads, not writes.

On the other hand, the GraphQL specification supports bulk/batch operations automatically for the mutations you've already implemented, whereas the JSON:API specification does not. The ability to perform batch write operations can be important. For example, in our running example, adding a new tag to an article would require two requests; one to create the tag and one to update the article. That said, support for bulk/batch writes in JSON:API is on the specification's roadmap.

REST JSON:API GraphQL Writing data Acceptable; every implementation is different. No bulk support. Excellent; JSON:API prescribes a complete solution for handling writes. Bulk operations are coming soon. Poor; GraphQL supports bulk/batch operations, but writes can be tricky to design and implement. There are competing conventions. Drupal-specific considerations

Up to this point we have provided an architectural and CMS-agnostic comparison; now we also want to highlight a few Drupal-specific implementation details. For this, we can look at the ease of installation, automatically generated documentation, integration with Drupal's entity and field-level access control systems and decoupled filtering.

Drupal 8's REST module is practically impossible to set up without the contributed REST UI module, and its configuration can be daunting. Drupal's JSON:API module is far superior to Drupal's REST module at this point. It is trivial to set up: install it and you're done; there's nothing to configure. The GraphQL module is also easy to install but does require some configuration.

Client-generated collection queries allow a consumer to filter an application's data down to just what they're interested in. This is a bit like a Drupal View except that the consumer can add, remove and control all the filters. This is almost always a requirement for public web services, but it can also make development more efficient because creating or changing a listing doesn't require server-side configuration changes.

Drupal's REST module does not support client-generated collection queries. It requires a "REST Views display" to be setup by a site administrator and since these need to be manually configured in Drupal; this means a client can't craft its own queries with the filters it needs.

JSON:API and GraphQL, clients are able to perform their own content queries without the need for server-side configuration. This means that they can be truly decoupled: changes to the front end don't always require a back-end configuration change.

These client-generated queries are a bit simpler to use with the JSON:API module than they are with the GraphQL module because of how each module handles Drupal's extensive access control mechanisms. By default JSON:API ensures that these are respected by altering the incoming query. GraphQL instead requires the consumer to have permission to simply bypass access restrictions.

Most projects using GraphQL that cannot grant this permission use persisted queries instead of client-generated queries. This means a return to a more traditional Views-like pattern because the consumer no longer has complete control of the query's filters. To regain some of the efficiencies of client-generated queries, the creation of these persisted queries can be automated using front-end build tooling.

REST JSON:API GraphQL Ease of installation and configuration Poor; requires contributed module REST UI, easy to break clients by changing configuration. Excellent; zero configuration! Poor; more complex to use, may require additional permissions, configuration or custom code. Automatically generated documentation Acceptable; requires contributed module OpenAPI. Acceptable; requires contributed module OpenAPI. Excellent; GraphQL Voyager included. Security: content-level access control (entity and field access) Excellent; content-level access control respected. Excellent; content-level access control respected, even in queries. Acceptable; some use cases require the consumer to have permission to bypass all entity and/or field access. Decoupled filtering (client can craft queries without server-side intervention) No Yes Depends; only in some setups and with additional tooling/infrastructure. What does this mean for Drupal's roadmap?

Drupal grew up as a traditional web content management system but has since evolved for this API-first world and industry analysts are praising us for it.

As Drupal's project lead, I've been talking about adding out-of-the-box support for both JSON:API and GraphQL for a while now. In fact, I've been very bullish about GraphQL since 2015. My optimism was warranted; GraphQL is undergoing a meteoric rise in interest across the web development industry.

Based on this analysis, we rank JSON:API above GraphQL and GraphQL above REST. As such, I want to change my recommendation for Drupal 8 core. Instead of adding both JSON:API and GraphQL to Drupal 8 core, I believe only JSON:API should be added. While Drupal's GraphQL implementation is fantastic, I no longer recommend that we add GraphQL to Drupal 8 core.

On the four qualities by which we evaluated the REST, JSON:API and GraphQL modules, JSON:API has outperformed its contemporaries. Its web standards-based approach, its ability to handle reads and writes out of the box, its security model and its ease of operation make it the best choice for Drupal core. Additionally, where JSON:API underperformed, I believe that we have a real opportunity to contribute back to the specification. In fact, one of the JSON:API module's maintainers and co-authors of this blog post, Gabe Sullice (Acquia), recently became a JSON:API specification editor himself.

This decision does not mean that you can't or shouldn't use GraphQL with Drupal. While I believe JSON:API covers the majority of use cases, there are valid use cases where GraphQL is a great fit. I'm happy that Drupal is endowed with such a vibrant contributed module ecosystem that provides so many options to Drupal's users.

I'm excited to see where both the JSON:API specification and Drupal's implementation of it goes in the coming months and years. As a first next step, we're preparing the JSON:API to be added to Drupal 8.7.

Special thanks to Wim Leers (Acquia) and Gabe Sullice (Acquia) for co-authoring this blog post and to Preston So (Acquia) and Alex Bronstein (Acquia) for their feedback during the writing process.

Categories: Drupal


New Drupal Modules - 11 February 2019 - 5:35am

The Delphi module provides an implementation of the
Delphi method for With some work it could be useful to other sites.

Categories: Drupal


New Drupal Modules - 11 February 2019 - 12:45am

About "Walkme"

WalkMe’s Digital Adoption Platform (DAP) makes it effortless to use any software,
website, or app. Combined with proactive, step-by-step guidance, our comprehensive
solution analyzes and automates processes so users can complete tasks easily in
the moment of need.


Before installing this module go to, generate the script and publish script.
After module is installed navigate to admin/config/system/walkme and place walkme script in Script field.

Categories: Drupal Blog: Our blog posts from January 2019

Planet Drupal - 11 February 2019 - 12:16am

We've prepared an overview of all our blog posts from January 2019; have a look!

Categories: Drupal

Fuzzy Thinking: Ready ...

RPGNet - 11 February 2019 - 12:00am
Fuzzy military exercises.
Categories: Game Theory & Design

Video Game Deep Cuts: The Apex Of Legends, Observing The Sunless Skies

Social/Online Games - Gamasutra - 10 February 2019 - 8:48pm

This week's highlights include interviews on the much-vaunted Apex Legends, info on AI thriller Observation & the loneliness of Sunless Skies, as well as Russian Doll, Art Sqool, and lots more. ...

Categories: Game Theory & Design


Subscribe to As If Productions aggregator