Newsfeeds

InternetDevels: Spam protection with Drupal 8 modules

Planet Drupal - 23 August 2017 - 5:14am

Spam causes huge inconvenience to Internet users and headaches for site owners. Spam is one of reasons why you don’t need a comment section on your web resource. However, allowing your site visitors to post comments and any other content means communication and feedback. Allowing them to express their opinions and share their ideas on your site has its good sides as well. So it would be not right to get rid of this option all together. Luckily, Drupal can offer you a solution — and not just one.

Read more
Categories: Drupal

Abhishek Lal | GSoC Blog: Examples for Developer #12 Week of Coding

Planet Drupal - 23 August 2017 - 2:17am
Examples for Developer #12 Week of Coding Abhishek Lal B Wed, 08/23/2017 - 14:47
Categories: Drupal

Starting at Higher Level

Gnome Stew - 23 August 2017 - 1:00am

Some of your stories may involve a higher power scale than starting off at “level one” or the equivalent in your game system. Perhaps the tale you want to tell with your players is on a greater epic scale. Perhaps you tire of struggling to keep those lower-level characters alive. Perhaps it’s just time to tell a story involving higher powers, increased competence, and more daring dangers. Regardless of your reasons for wanting to start at a higher level, there are some considerations to take into account with firing up a campaign with higher level characters.

Baked In Power Levels

Quite a few systems have higher power levels baked right in. I’m mainly thinking of point-buy systems, such as GURPS, Hero System, and similar games. These are the “easy route” for starting at higher power levels. Just provide more points or higher levels of points acquired via disadvantages. There are also character generation systems, such as Traveller, which can produce more potent characters. Another system is the Dresden Files RPG, which includes different power levels for the PCs to play with. The main thing to keep in mind here is that all players should start out at the same power base.

Non-Level Experience Point Systems

Some systems, such as Savage Worlds, MechWarrior, Top Secret S/I, Fate Core, and Paranoia increase the power of the character via gaining experience points that are then spent or applied toward increases in skills, abilities, special powers, equipment, and other items that make the character a more powerful force in the world. My advice here is to tell the players that they’ll be playing higher level characters, but to create a “baseline” character just like they normally would. Then provide them with the amount of experience or advancement points you want them to have. This will reduce the information overload which can lead to analysis paralysis.

 Reduce information overload which can lead to analysis paralysis. If they have their starting character to build on first, the players can then focus in on how to improve what they have. If they get their experience points up front, then they’ll start looking at the higher power stuff and trying to figure out how to get there. Since the combination of “starter” and higher level powers can be overwhelming, the players might spend longer than you want them to spend while deciding where to take their character. The baseline character will provide a creative compass to focus their efforts on advancement.

Another approach is to dole out the experience points in chunks. In Savage Worlds, it takes five points to advance something. Instead of giving the players 30 points to play with, it might be wise to not tell them the max amount they’ll get. Just give them five, wait for everyone to do their quick advancement decision, then give them another five, and repeat this process until you’ve reached your predetermined maximum. This may sound like a slow way of doing things, but it can actually speed up the character creation process.

Level-Gain Experience Point Systems

With games like Dungeons and Dragons, Pathfinder, Starfinder, and so many others, characters gain their new abilities, spells, powers, and such when they achieve a new level. My recommendation here is to strongly advise the GM to have the players make a first level character. Then dole out the levels one at a time until they’ve reached the level you want them to be. I’ve seen GMs arrive at the game and drop the bomb, “Make a 12th level character,” and then the players struggle for a full session (sometimes two!) to get things “just right.” Making the level advancement more organic will speed things up. The GM can inform the players that they’ll be making a character higher than first level, but don’t tell them the final target.

 Start at first level, then dole out the experience points or levels. If you’re setting up the game beforehand and allow the players to roll their stats and create the character prior to “session zero” where they all meet up and start adventuring, then the players will have more time to work on their characters. In this case, telling the players what their target level is and to show up with a “12th level character” is perfectly fine.

Money and Equipment

There are two approaches here.

The GM can assign gear (magical or otherwise) appropriate to each character. However, this takes quite a bit of time on the GM’s part, and the gear might not be exactly what the player wants for their character.

The other approach is to give out a certain amount of currency for the game, and tell the players to go hog wild spending on what they want. Just make sure the money is in alignment with the level of the characters. Dropping 30,0000 GP on a 4th level character is probably excessive in D&D. If this approach is used, I recommend setting limitations on the spending. Something like, “No more than half your money can go toward a single item.” This will prevent that special player from spending 100% of their money on a single, incredibly powerful item that can unbalance the game and ruin the story.

World Benefits

Separate from extra powers and equipment, work with the players to determine if their character has accolades, titles, land holdings, a headquarters, and other world benefits. Sometimes, this is built into the point buy systems, so encouraging (or requiring) a certain number of points be dedicated to “worldly goods” like a headquarters might be appropriate for the game. It all depends on the type of story you want to tell.

If you’re going with a system where level does not equate to titles and land holdings, you can give the players a separate pool of money that can be spent on things like this. Just be very clear that this monetary gain is not to be spent on equipment or items specific to their character. I’d also make this pool of money in the style of “use it or lose it.” No banking the money for later use. I like this approach because it gives more freedom to the players on getting what they want and encourages them to establish themselves in the world.

Allocate Time

Building higher level characters takes more time than building a base character. Most “session zero” events that I’ve held take about half the session to get the numbers down on the character sheets and the other half to get the characters together in the world and establish the where, when, what, and basics of the start of the campaign. Obviously, with more things to choose from and more items to purchase, extra time will be needed to get the first half of the session finished. Odds are that it will take the entire “session zero” to get the characters created, so don’t get frustrated at the extra time it will take for the players to make their decisions.

 Building higher level characters takes more time than building a base character. Don’t worry, you (the GM) won’t be sitting there bored while you watch people pick through core books and expansions. The players are going to have tons of questions about how certain powers work, what books they can use, where they can find certain information, and how certain things work in the world you’re going to be running the campaign in. If anything, you’ll be busier than the deli guy when the number machine is broken. You’ll be hit from different directions with wildly different questions. Take them one at a time and get back to the players as you can.

Leveraging Technology

As most folks know, the higher the level of the characters, the more crunchy the math gets with powers and abilities and stacked numbers and equipment and such. The rules get a bit more complex at higher levels because of the increased abilities of the powers. This is where software like PCGen and Hero Lab can come into play to help the players keep their characters straight. Yes, this means allowing laptops and tablets at the table, but so long as you are not incredibly opposed to this, it’s a good thing to let the players use. It might even speed things up if the players are comfortable with the software they’re using.

Adjusting the Encounters

Once the characters are made and it’s time to roll into the world with your story, the encounters will need to be adjusted to the power level of the characters. The only reason I mention this is that I’ve made the mistake of forgetting to do this. I took an intro adventure for first level characters and ran fourth level characters through it. It started as a cakewalk because it completely slipped my mind that, “first session does not equal first level.” I completely failed in my preparations. Fortunately, I recovered after the first two encounters (and a couple of questioning glances from my players) and managed to adjust on the fly to increase the challenge. Make sure you have in mind what the challenges, traps, monsters, riddles, and social encounters have to offer to put the PCs to the test are.

Adjusting the Storyline

Most stories start out with the PCs barely able to do small things to alter the world. That’s not the case with higher level characters, especially if you start at the extremes of height in the power structure. Who have the characters already met? What contacts/friends/enemies do they have in the world? Have the characters already “saved the day” in some smaller manner in the past? How does society view them? Are there members of organizations (church, guild, army, leadership, councils, etc.) that will want or need things from them? Can the characters lean on someone else for assistance, monetary or otherwise? Do they have henchmen? Do they have apprentices, squires, or assistants?

 Most stories start out with the PCs barely able to do small things to alter the world. These higher level characters didn’t leap from their players’ foreheads fully formed. There needs to be a backstory and history to them. Of course, if you’re doing an old school dungeon crawl, perhaps you can go lighter on the backstory. However, if you’re interested in telling a story that involves interaction with NPCs in the world, some of these details are going to need to be figured out. Probably not to the extent of a full world-building bible like what some authors do for their novels, but there need to be some hooks to grab onto here and there.

Underlings

If the characters are high enough level, they may have followers of some sort. This provides a wonderful opportunity for the players to create (usually after session zero) lower level characters for them to control in side quests or alternate story arcs. I’ve seen this done to good effect, but it can be overwhelming for the players if you show up and tell them something along the lines of, “You’ll be making a 12th level character, a 4th level character, and a 1st level character.” Dropping three characters on the table is rough. Start with the main character, and then slowly ease into the creation of the lower level underlings. Maybe allow the players to create those lower-level characters on their own time between sessions.

Conclusion

While starting at higher levels can be daunting for some players, especially those newer to the hobby, it can be quite fun to unleash the powers and abilities of the more potent characters without spending the weeks, months, and years of getting them to those levels. I don’t recommend this become your normal mode of starting games, but it is a refreshing change of pace.

Have you ever started a game at higher levels? How did that work out for you? Any words of warning or encouraging advice for your fellow Gnome Stew readers?

Categories: Game Theory & Design

Entity ORM

New Drupal Modules - 23 August 2017 - 12:29am
Categories: Drupal

Amazee Labs: Tour de DrupAlps - Cycling the Alps to DrupalCon Vienna

Planet Drupal - 23 August 2017 - 12:14am
Tour de DrupAlps - Cycling the Alps to DrupalCon Vienna

As per the extreme version of Tour de Drupal, my plan is to cycle from Switzerland to DrupalCon Vienna by crossing the Alps 6 times. The tour will take me over some of the most challenging Alp passes using my road cycle.

Josef Dabernig Wed, 08/23/2017 - 09:14

I’ll visit 5 different countries, including: Switzerland, Italy, Germany, Slovenia and Austria. Overcoming the Alps with the bicycle has been one of my long term dreams... Inspired by the sport achievements of my uncle, I am taking this challenge to see if I can make it from Switzerland to DrupalCon Vienna by taking some scenic and challenging detours over the Alps.

The final destination is DrupalCon Vienna which serves as the perfect goal because it’s my favorite conference and my hometown at the same time.

#DrupAlps in numbers

  • Days: 31
  • Distance: 2361 km
  • Total elevation gain: 57864 meters

Route

Here is how I planned out the route so far

Depending on weather and physical conditions, I will adapt the route along the way while riding.

Preparations

Over the last months, I have been riding various passes to get ready for the tour. Longer rides included St. Moritz - Splügenpass - Chur, Erstfeld - Oberalppass - Chur, and  Zurich - Vierwaldstättersee - Lucerne. In 2015, we cycled the Pyrenees as part of #TourDeDrupal Barcelona(1, 2, 3), early 2016 we cycled Sierra Nevada(1, 2) and later summer 2016 I cycled the biggest mountain of Austria on the Großglocknerstrasse.

Until now, I have no experience in cycling more than 3 consecutive days,  so I am really looking forward to seeing how it will go while being in the saddle for so many days in a row.

For DrupalCon Barcelona we cycled along the Pyrenees.

Amazee Extreme Challenge

“After three years of fulltime employment, our employees get one month off to free their mind and do something really extreme.”

I would like to thank Amazee for giving me this unique chance. Find out about what my colleagues are planning or have already accomplished at the Amazee Labs Extreme page.

DrupalCon Vienna

DrupalCon is the biggest Drupal conference, organized by the Drupal Association and will take place in Vienna from 26-29 September this year. I am especially looking forward to this one in my home town!

On Monday, there will be sprints, training sessions & summits organized by Drupal Austria.

Tuesday to Friday is packed with the official conference program and I am particularly excited about the site-building track, which I am a track chairing this year. Check out my blog post about what to expect from this week at DrupalCon.

Join Tour de Drupal

If you’d like to join my for the last few days of cycling, the last days are planned to be flat along the Danube river. For example, we plan to cycle from Linz to Krems on Saturday, 22nd of September. On Sunday, 23rd of September we go from Krems to Tulln where we will have a lunch break at the webshapers office. After that, we’ll cycle towards Vienna to arrive on Sunday afternoon.

Sign-up here and see my blog post for further details.

Follow me

Along the route, I will post regular updates about the ups and downs of the Tour de DrupAlps. To stay tuned, you can follow me here:

Categories: Drupal

Ben's SEO Blog: A Drupal SEO Expert and a Drupal Developer Hit the Mat

Planet Drupal - 23 August 2017 - 12:01am

[Photo credits: Ben Finklea, Jan 2017. Photos captured from iPhone video shot at Texas Grappling Challenge Brazilian Jiu-Jitsu tournament in Cedar Park, Texas.]

My Drupal developer friends and I (like any friendship) don’t always see eye-to-eye. While we have much in common—we both want stylish, high-performing websites—in some areas our goals are different. This can create the appearance of conflict. However, after working through the issues (or hitting the mats, as they say in Brazilian Jiu-Jitsu), we can find common ground and mutual respect.

In Drupal 8 SEO, I lay out a list of modules that should be installed on your Drupal website to enhance SEO. I wrote this book for marketers and provide the step-by-step details you need to increase Google ranking, website traffic... Read the full article: A Drupal SEO Expert and a Drupal Developer Hit the Mat

Categories: Drupal

Container

New Drupal Modules - 22 August 2017 - 5:51pm
Categories: Drupal

Reservoir, a simple way to decouple Drupal

Dries Buytaert - 22 August 2017 - 1:52pm

Headless Drupal seems to be taking the world by storm. I'm currently in Sydney, and everyone I talked to so far, including the attendees at the Sydney Drupal User Group, is looking into headless Drupal. Digital agencies are experimenting with it on more projects, and there is even a new Decoupled Dev Days conference dedicated to the topic.

Roughly eight months ago, we asked ourselves in Acquia's Office of the CTO whether we could create a "headless" version of Drupal, optimized for integration with a variety of applications, channels and touchpoints. Such a version could help us build bridges with other developer communities working with different frameworks and programming languages, and the JavaScript community in particular.

I've been too busy with the transition at Acquia to blog about it in real time, but a few months ago, we released Reservoir. It's a Drupal-based content repository with all the necessary web service APIs needed to build decoupled front-end applications, be it a React application, an Ember front end, a native application, an augmented reality application, a Java or .NET application, or something completely different. You can even front-end it with a PHP application, something I hope to experiment with on my blog.

API-first distributions for Drupal like Reservoir and Contenta are a relatively new phenomenon but seem to be taking off rapidly. It's no surprise because an API-first approach is critical in a world where you have to operate agnostically across any channel and any form factor. I'm convinced that an API-first approach will be a critical addition to Drupal's future and could see a distribution like Reservoir or Contenta evolve to become a third installation profile for Drupal core (not formally decided).

Headless Drupal for both editors and developers The welcome screen after installing Reservoir.

The reason headless Drupal is taking off is that organizations are now grappling with a multitude of channels, including mobile applications, single-page JavaScript applications, IoT applications, digital signage, and content driven by augmented and virtual reality. Increasingly, organizations need a single place to house content.

What you want is an easy but powerful way for your editorial team to create and manage content, including administering advanced content models, content versioning, integrating media assets, translations, and more. All of that should be made easy through a great UI without having to involve a developer. This, incidentally, is aligned with Drupal 8's roadmap, in which we are focused on media management, workflows, layouts, and usability improvements through our outside-in work.

At the same time, you want to enable your developers to easily deliver that content to different devices, channels, and platforms. This means that the content needs to be available through APIs. This, too, is aligned with Drupal 8's roadmap, where we are focused on web services capabilities. Through Drupal's web service APIs, developers can build freely in different front-end technologies, such as Angular, React, Ember, and Swift, as well as Java and .NET. For developers, accomplishing this without the maintenance burden of a full Drupal site or the complexity of configuring standard Drupal to be decoupled is key.

API-first distributions like Reservoir keep Drupal's workflows and editorial UI intact but emphasize Drupal's web service APIs to return control to your developers. But with flexible content modeling and custom fields added to the equation, they also give more control over how editors can curate, combine, and remix content for different channels.

Success is getting to developer productivity faster Reservoir includes side-by-side previews of content in HTML and JSON API output.

The goal of a content repository should be to make it simple for developers to consume your content, including digital assets and translations, through a set of web service APIs. Success means that a developer can programmatically access your content within minutes.

Reservoir tries to achieve this in four ways:

  1. Easy on-boarding. Reservoir provides a welcome tour with helpful guidance to create and edit content, map out new content models, manage access control, and most importantly, introspect the web service APIs you'll need to consume to serve your applications.
  2. JSON API standard. Reservoir makes use of JSON API, which is the specification used for many APIs in JSON and adopted by the Ember and Ruby on Rails communities. Using a common standard means you can on-board your developers faster.
  3. Great API documentation. Reservoir ships with great API documentation thanks to OpenAPI, formerly known as Swagger, which is a specification for describing an API. If you're not happy with the default documentation, you can bring your own approach by using Reservoir's OpenAPI export.
  4. Libraries, references, and SDKs. With the Waterwheel ecosystem, a series of libraries, references, and SDKs for popular languages like JavaScript and Swift, developers can skip learning the APIs and go straight to integrating Drupal content in their applications.
Next steps for Reservoir API documentation auto-generated based on the content model built in Reservoir.

We have a lot of great plans for Reservoir moving forward. Reservoir has several items on its short-term roadmap, including GraphQL support. As an emerging industry standard for data queries, GraphQL is a query language I first highlighted in my 2015 Barcelona keynote; see my blog post on the future of decoupled Drupal for a quick demo video.

We also plan to expand API coverage by adding the ability to programmatically manipulate users, tags, and other crucial content elements. This means that developers will be able to build richer integrations.

While content such as articles, pages, and other custom content types can be consumed and manipulated via web services today, upstream in Drupal core, API support for things like Drupal's blocks, menus, and layouts is in the works. The ability to influence more of Drupal's internals from external applications will open the door to better custom editorial interfaces.

Conclusion

I'm excited about Reservoir, not just because of the promise API-first distributions hold for the Drupal community, but because it helps us reach developers of different stripes who just need a simple content back end, all the while keeping all of the content editing functionality that editorial teams take for granted.

We've put the Reservoir codebase on GitHub, where you can open an issue, create a pull request, or contribute to documentation. Reservoir only advances when you give us feedback, so please let us know what you think!

Special thanks to Preston So for contributions to this blog post and to Ted Bowman, Wim Leers, and Matt Grill for feedback during the writing process.

Categories: Drupal

Reservoir, a simple way to decouple Drupal

Dries Buytaert - 22 August 2017 - 1:52pm

Decoupled Drupal seems to be taking the world by storm. I'm currently in Sydney, and everyone I talked to so far, including the attendees at the Sydney Drupal User Group, is looking into decoupled Drupal. Digital agencies are experimenting with it on more projects, and there is even a new Decoupled Dev Days conference dedicated to the topic.

Roughly eight months ago, we asked ourselves in Acquia's Office of the CTO whether we could create a "headless" version of Drupal, optimized for integration with a variety of applications, channels and touchpoints. Such a version could help us build bridges with other developer communities working with different frameworks and programming languages, and the JavaScript community in particular.

I've been too busy with the transition at Acquia to blog about it in real time, but a few months ago, we released Reservoir. It's a Drupal-based content repository with all the necessary web service APIs needed to build decoupled front-end applications, be it a React application, an Ember front end, a native application, an augmented reality application, a Java or .NET application, or something completely different. You can even front-end it with a PHP application, something I hope to experiment with on my blog.

API-first distributions for Drupal like Reservoir and Contenta are a relatively new phenomenon but seem to be taking off rapidly. It's no surprise because an API-first approach is critical in a world where you have to operate agnostically across any channel and any form factor. I'm convinced that an API-first approach will be a critical addition to Drupal's future and could see a distribution like Reservoir or Contenta evolve to become a third installation profile for Drupal core (not formally decided).

Decoupled Drupal for both editors and developers The welcome screen after installing Reservoir.

The reason decoupled Drupal is taking off is that organizations are now grappling with a multitude of channels, including mobile applications, single-page JavaScript applications, IoT applications, digital signage, and content driven by augmented and virtual reality. Increasingly, organizations need a single place to house content.

What you want is an easy but powerful way for your editorial team to create and manage content, including administering advanced content models, content versioning, integrating media assets, translations, and more. All of that should be made easy through a great UI without having to involve a developer. This, incidentally, is aligned with Drupal 8's roadmap, in which we are focused on media management, workflows, layouts, and usability improvements through our outside-in work.

At the same time, you want to enable your developers to easily deliver that content to different devices, channels, and platforms. This means that the content needs to be available through APIs. This, too, is aligned with Drupal 8's roadmap, where we are focused on web services capabilities. Through Drupal's web service APIs, developers can build freely in different front-end technologies, such as Angular, React, Ember, and Swift, as well as Java and .NET. For developers, accomplishing this without the maintenance burden of a full Drupal site or the complexity of configuring standard Drupal to be decoupled is key.

API-first distributions like Reservoir keep Drupal's workflows and editorial UI intact but emphasize Drupal's web service APIs to return control to your developers. But with flexible content modeling and custom fields added to the equation, they also give more control over how editors can curate, combine, and remix content for different channels.

Success is getting to developer productivity faster Reservoir includes side-by-side previews of content in HTML and JSON API output.

The goal of a content repository should be to make it simple for developers to consume your content, including digital assets and translations, through a set of web service APIs. Success means that a developer can programmatically access your content within minutes.

Reservoir tries to achieve this in four ways:

  1. Easy on-boarding. Reservoir provides a welcome tour with helpful guidance to create and edit content, map out new content models, manage access control, and most importantly, introspect the web service APIs you'll need to consume to serve your applications.
  2. JSON API standard. Reservoir makes use of JSON API, which is the specification used for many APIs in JSON and adopted by the Ember and Ruby on Rails communities. Using a common standard means you can on-board your developers faster.
  3. Great API documentation. Reservoir ships with great API documentation thanks to OpenAPI, formerly known as Swagger, which is a specification for describing an API. If you're not happy with the default documentation, you can bring your own approach by using Reservoir's OpenAPI export.
  4. Libraries, references, and SDKs. With the Waterwheel ecosystem, a series of libraries, references, and SDKs for popular languages like JavaScript and Swift, developers can skip learning the APIs and go straight to integrating Drupal content in their applications.
Next steps for Reservoir API documentation auto-generated based on the content model built in Reservoir.

We have a lot of great plans for Reservoir moving forward. Reservoir has several items on its short-term roadmap, including GraphQL support. As an emerging industry standard for data queries, GraphQL is a query language I first highlighted in my 2015 Barcelona keynote; see my blog post on the future of decoupled Drupal for a quick demo video.

We also plan to expand API coverage by adding the ability to programmatically manipulate users, tags, and other crucial content elements. This means that developers will be able to build richer integrations.

While content such as articles, pages, and other custom content types can be consumed and manipulated via web services today, upstream in Drupal core, API support for things like Drupal's blocks, menus, and layouts is in the works. The ability to influence more of Drupal's internals from external applications will open the door to better custom editorial interfaces.

Conclusion

I'm excited about Reservoir, not just because of the promise API-first distributions hold for the Drupal community, but because it helps us reach developers of different stripes who just need a simple content back end, all the while keeping all of the content editing functionality that editorial teams take for granted.

We've put the Reservoir codebase on GitHub, where you can open an issue, create a pull request, or contribute to documentation. Reservoir only advances when you give us feedback, so please let us know what you think!

Special thanks to Preston So for contributions to this blog post and to Ted Bowman, Wim Leers, and Matt Grill for feedback during the writing process.

Categories: Drupal

Reservoir, a simple way to decouple Drupal

Dries Buytaert - 22 August 2017 - 1:52pm

Decoupled Drupal seems to be taking the world by storm. I'm currently in Sydney, and everyone I talked to so far, including the attendees at the Sydney Drupal User Group, is looking into decoupled Drupal. Digital agencies are experimenting with it on more projects, and there is even a new Decoupled Dev Days conference dedicated to the topic.

Roughly eight months ago, we asked ourselves in Acquia's Office of the CTO whether we could create a "headless" version of Drupal, optimized for integration with a variety of applications, channels and touchpoints. Such a version could help us build bridges with other developer communities working with different frameworks and programming languages, and the JavaScript community in particular.

I've been too busy with the transition at Acquia to blog about it in real time, but a few months ago, we released Reservoir. It's a Drupal-based content repository with all the necessary web service APIs needed to build decoupled front-end applications, be it a React application, an Ember front end, a native application, an augmented reality application, a Java or .NET application, or something completely different. You can even front-end it with a PHP application, something I hope to experiment with on my blog.

API-first distributions for Drupal like Reservoir and Contenta are a relatively new phenomenon but seem to be taking off rapidly. It's no surprise because an API-first approach is critical in a world where you have to operate agnostically across any channel and any form factor. I'm convinced that an API-first approach will be a critical addition to Drupal's future and could see a distribution like Reservoir or Contenta evolve to become a third installation profile for Drupal core (not formally decided).

Decoupled Drupal for both editors and developers The welcome screen after installing Reservoir.

The reason decoupled Drupal is taking off is that organizations are now grappling with a multitude of channels, including mobile applications, single-page JavaScript applications, IoT applications, digital signage, and content driven by augmented and virtual reality. Increasingly, organizations need a single place to house content.

What you want is an easy but powerful way for your editorial team to create and manage content, including administering advanced content models, content versioning, integrating media assets, translations, and more. All of that should be made easy through a great UI without having to involve a developer. This, incidentally, is aligned with Drupal 8's roadmap, in which we are focused on media management, workflows, layouts, and usability improvements through our outside-in work.

At the same time, you want to enable your developers to easily deliver that content to different devices, channels, and platforms. This means that the content needs to be available through APIs. This, too, is aligned with Drupal 8's roadmap, where we are focused on web services capabilities. Through Drupal's web service APIs, developers can build freely in different front-end technologies, such as Angular, React, Ember, and Swift, as well as Java and .NET. For developers, accomplishing this without the maintenance burden of a full Drupal site or the complexity of configuring standard Drupal to be decoupled is key.

API-first distributions like Reservoir keep Drupal's workflows and editorial UI intact but emphasize Drupal's web service APIs to return control to your developers. But with flexible content modeling and custom fields added to the equation, they also give more control over how editors can curate, combine, and remix content for different channels.

Success is getting to developer productivity faster Reservoir includes side-by-side previews of content in HTML and JSON API output.

The goal of a content repository should be to make it simple for developers to consume your content, including digital assets and translations, through a set of web service APIs. Success means that a developer can programmatically access your content within minutes.

Reservoir tries to achieve this in four ways:

  1. Easy on-boarding. Reservoir provides a welcome tour with helpful guidance to create and edit content, map out new content models, manage access control, and most importantly, introspect the web service APIs you'll need to consume to serve your applications.
  2. JSON API standard. Reservoir makes use of JSON API, which is the specification used for many APIs in JSON and adopted by the Ember and Ruby on Rails communities. Using a common standard means you can on-board your developers faster.
  3. Great API documentation. Reservoir ships with great API documentation thanks to OpenAPI, formerly known as Swagger, which is a specification for describing an API. If you're not happy with the default documentation, you can bring your own approach by using Reservoir's OpenAPI export.
  4. Libraries, references, and SDKs. With the Waterwheel ecosystem, a series of libraries, references, and SDKs for popular languages like JavaScript and Swift, developers can skip learning the APIs and go straight to integrating Drupal content in their applications.
Next steps for Reservoir API documentation auto-generated based on the content model built in Reservoir.

We have a lot of great plans for Reservoir moving forward. Reservoir has several items on its short-term roadmap, including GraphQL support. As an emerging industry standard for data queries, GraphQL is a query language I first highlighted in my 2015 Barcelona keynote; see my blog post on the future of decoupled Drupal for a quick demo video.

We also plan to expand API coverage by adding the ability to programmatically manipulate users, tags, and other crucial content elements. This means that developers will be able to build richer integrations.

While content such as articles, pages, and other custom content types can be consumed and manipulated via web services today, upstream in Drupal core, API support for things like Drupal's blocks, menus, and layouts is in the works. The ability to influence more of Drupal's internals from external applications will open the door to better custom editorial interfaces.

Conclusion

I'm excited about Reservoir, not just because of the promise API-first distributions hold for the Drupal community, but because it helps us reach developers of different stripes who just need a simple content back end, all the while keeping all of the content editing functionality that editorial teams take for granted.

We've put the Reservoir codebase on GitHub, where you can open an issue, create a pull request, or contribute to documentation. Reservoir only advances when you give us feedback, so please let us know what you think!

Special thanks to Preston So for contributions to this blog post and to Ted Bowman, Wim Leers, and Matt Grill for feedback during the writing process.

Categories: Drupal

Type Style

New Drupal Modules - 22 August 2017 - 1:47pm
Summary

Type Style allows users to associate colors and icons with their types. This is an important feature for building rich user interfaces, as content editors can quickly associate iconography and colors with a type. Currently Content types, Custom block types, (core) Media types, Taxonomy vocabularies, and File types are supported, but any custom or contributed type can be supported.

Categories: Drupal

Web3

New Drupal Modules - 22 August 2017 - 1:09pm

This will be the place where we enable Drupal for the next web - web 3.0.

Categories: Drupal

Account Activation Reminder

New Drupal Modules - 22 August 2017 - 10:46am

A module allowing site administrators to resend activation emails from a selected user account page.

It also offers
- a custom email subject line
- a custom email body

This module is safe to use on a production site. Just be sure to only grant 'administer users' permission to developers.

Categories: Drupal

Group Role Delegation

New Drupal Modules - 22 August 2017 - 10:43am

This module allows group owner to grant specific roles to users.
User can set expiry date for selected roles, expiry dates are controlled by cron job, so it automatically removes any expired roles.

Categories: Drupal

Workflows Assignee

New Drupal Modules - 22 August 2017 - 10:38am
Categories: Drupal

An object at rest

Adventures in Interactive FIction - 17 May 2008 - 2:03pm

So obviously, the pendulum of progress stopped swinging on my game.  As much as I tried to prevent it, pressing obligations just wouldn’t take a back seat (nor would the burglars who, a few weeks ago, stole 90% of my wardrobe and who last week stole my monitor).  So after a string of hectic weekends and even crazier weeks, this weekend has been pretty wide open for doing whatever I want to do.  And not a moment too soon!

So after doing all the other things I try to do with my weekends, I finally loaded up the ol’ Inform 7 IDE and started working on my game.  To get me back in the swing of things, so to speak, I started reading through what I’d already written.  It was an interesting experience.

Strangely, what impressed me most was stuff I had done that I have since forgotten I learned how to do.  Silly little things, like actions I defined that actually worked, that had I tried to write them today, probably would have had me stumped for a while.  Go me!  Except, erm, I seem to have forgotten more than I’ve retained.

I also realized the importance of commenting my own code.  For instance, there’s this snippet:

A thing can be attached or unattached. A thing is usually unattached. A thing that is a part of something is attached.

The problem is, I have no idea why I put it in there – it doesn’t seem relevant to anything already in the game, so I can only imagine that I had some stroke of genius that told me I was going to need it “shortly” (I probably figured I’d be writing the code the next night).  So now, there’s that lonely little line, just waiting for its purpose.  I’m sure I’ll come across it some day; for now, I’ve stuck in a comment to remind myself to stick in a comment when I do remember.

It reminds me of all the writing I did when I was younger.  I was just bursting with creativity when I was a kid, constantly writing the first few pages of what I was sure was going to be a killer story.  And then I’d misplace the notebook or get sidetracked by something else, or do any of the million other things that my easily distracted self tends to do.  Some time later, I’d come across the notebook, read the stuff I’d written and think, “Wow, this is great stuff!  Now… where was I going with it?”  And I’d never remember, or I’d remember and re-forget.  Either way, in my mother’s attic there are piles and piles of notebooks with half-formed thoughts that teem with potential never to be fulfilled.

This situation – that of wanting to resume progress but fumbling to pick up the threads of where I left off –  has me scouring my memory for a term I read in Jack London’s Call of the Wild.  There was a part in the book where Buck’s owner (it’s late, his name has escaped me) has been challenged to some sort of competition to see if Buck can get the sled moving from a dead stop.  I seem to remember that the runners were frozen to the ground.  I thought the term was “fast break” or “break fast” or something to that effect, but diligent (does 45 seconds count as diligent?) searching has not confirmed this or provided me with the right term.  Anyway, that’s how it feels tonight – I feel as if I’m trying to heave a frozen sled free from its moorings.

The upside is, I am still pleased with what I have so far.  That’s good because it means I’m very likely to continue, rather than scrap it altogether and pretend that I’ll come up with a new idea tomorrow.  In the meantime, I’ll be looking for some SnoMelt and a trusty St. Bernard to get things moving again.


Categories:

Time enough (to write) at last…

Adventures in Interactive FIction - 14 April 2008 - 3:24pm

So I didn’t get as much coding done over the weekend as I had hoped, mainly because the telephone company *finally* installed my DSL line, which meant I was up til 5:30 Saturday am catching up on the new episodes of Lost.  That, in turn, meant that most of the weekend was spent wishing I hadn’t stayed up until such an ungodly hour, and concentration just wasn’t in the cards.

However, I did get some stuff done, which is good.  Even the tiniest bit of progress counts as momentum, which is crucial for me.  If the pendulum stops swinging, it will be very hard for me to get it moving again.

So the other day, as I was going over the blog (which really is as much a tool for me as it is a way for me to share my thoughts with others), I realized I had overlooked a very basic thing when coding the whole “automatically return the frog to the fuschia” bit…

As the code stood, if the player managed to carry the frog to another room before searching it, the frog would get magically returned to the fuschia.  This was fairly simple to resolve, in the end – I just coded it so that the game moves (and reports) the frog back to fuschia before leaving the room.  I also decided to add in a different way of getting the key out of the frog – in essence, rewarding different approaches to the same problem with success.

Which brings me to the main thrust of today’s post.  I have such exacting standards for the games I play.  I love thorough implementation.  My favorite games are those that build me a cool gameworld and let me tinker and explore, poking at the shadows and pulling on the edges to see how well it holds up.  A sign of a good game is one that I will reopen not to actually play through again, but to just wander around the world, taking in my surroundings.  I’ve long lamented the fact that relatively few games make this a rewarding experience – even in the best games, even slight digging tends to turn up empty, unimplemented spots.

What I am coming to appreciate is just how much work is involved in the kind of implementation I look for.  Every time I pass through a room’s description, or add in scenery objects, I realize just how easy it is to find things to drill down into.  Where there’s a hanging plant, there’s a pot, dirt, leaves, stems, wires to hang from, hooks to hang on, etc.  Obviously, unless I had all the time in the world, I couldn’t implement each of these separately, so I take what I believe to be the accepted approach and have all of the refer to the same thing.  Which, in my opinion, is fine.  I don’t mind if a game has the same responses for the stems as it does for the plant as a whole, as long as it has some sort of relevant response.  Even so, this takes a lot of work.  It might be the obsessive part of me, but I can’t help but think “What else would a person think of when looking at a hanging plant?”

Or, as I’ve come to think of it:  WWBTD?

What Would Beta Testers Do?

I’ve taken to looking at a “fully” implemented room and wondering what a player might reasonably (and in some cases unreasonably) be expected to do.  This is a bit of a challenging process for me – I already know how my mind works, so trying to step outside of my viewpoint and see it from a blind eye is hard.   I should stop for a second to note that I fully intend to have my game beta tested once it reaches that point, but the fewer obvious things there are for testers to trip over, the more time and energy they’ll have for really digging in and trying to expose the weaknesses I can’t think of.

I’ve found one resource that is both entertaining and highly informative to me:  ClubFloyd transcripts.  ClubFloyd, for the uninitiated (a group among which I count myself, of course) is a sort of cooperative gaming experience — if anyone who knows better reads this and cares to correct what may well be a horrible description, by all means!– where people get together on the IFMud and play through an IF title.  The transcripts are both amusing and revealing.  I recently read the Lost Pig transcript and it was quite interesting.  The things people will attempt to do are both astonishing and eye-opening.  In the case of Lost Pig (which, fortunately, I had already played before reading the transcript), what was even more amazing was the depth of the game itself.  I mean, people were doing some crazy ass stuff – eating the pole, lighting pants on fire, and so on.  And it *worked*.  Not only did it work, it was reversible.  You obviously need the pole, so there’s a way to get it back if, in a fit of orc-like passion, you decide to shove it in down Grunk’s throat.

Anyway, my point is, the transcripts gave me a unique perspective on the things people will try, whether in an effort to actually play the game, to amuse themselves, or to amuse others.  Definitely good stuff to keep in mind when trying to decide, say, the different ways people will try to interact with my little porcelain frog.

Other Stuff I Accomplished

So I coded in an alternate way to deal with the frog that didn’t conflict with the “standard” approach.  I also implemented a few more scenery objects.  Over the course of the next few days, I’m going to try to at least finish the descriptions of the remaining rooms so that I can wander around a bit and start really getting to the meat of it all.  I also want to work on revising the intro text a bit.  In an effort to avoid the infodumps that I so passionately hate, I think I went a little too far and came away with something a bit too terse and uninformative.  But that’s the really fun part of all of this – writing and re-writing, polishing the prose and making it all come together.

Whattaya know.  Midnight again.  I think I’m picking up on a trend here.


Categories:

Day Nothing – *shakes fist at real life*

Adventures in Interactive FIction - 8 April 2008 - 12:13pm

Grrr… I’ve been so bogged down in work and client emergencies that progress on the game is at a temporary (no, really!  Only temporary) standstill.  I’ve managed to flesh out a few more room and scenery descriptions, but have not accomplished anything noteworthy in a few days.  Hopefully after this week most of the fires on the work front will be extinguished, and I’ll have time to dive into the game this weekend.

(She says to no one, since there’s been one hit on this blog since… it started.)


Categories:

Pages

Subscribe to As If Productions aggregator