DrupalEasy: Learning Drupal: Time is On Your Side  

Planet Drupal - 25 January 2017 - 7:15am
Miriam Webster defines effort as conscious exertion of power: hard work

If you want to learn Drupal, you need to put forth some effort, and if you want to do it properly, get ready to exert some power for months, not days.  People ask us all the time if they can get a job right out of our Drupal Career Online program. The truth is, it depends on how much hard work you put in to get out ready enough for an internship or junior position. Whether it’s Drupal or anything else, learning something and being able to apply it well depends on how much you absorb and practice, both of which are best done over time.

Last summer, James Dennin wrote an insightful piece of advice for those seeking careers in coding for It touches on a lot of the same issues with bootcamps that we have heard about for years from students who come to DrupalEasy Academy after disappointing experiences. While we don’t like to throw barbs, we like less the sad stories of lost dollars and time in unguided crash courses where people are seated in a room, immersed in videos and teamed with other, non-skilled newbies on trying learn Drupal. A 5- or 10-day whirlwind of information overload is seldom a successful learning experience.

Becoming proficient in Drupal is no cakewalk; it includes amassing knowledge, learning best practices and developing skills as part of a challenging learning process, whatever your process may include. Education experts recognize as many as seven different styles of learning, including:  Visual, Aural, Verbal, Physical, LogicalSocial and Solitary. Most people find a combination works best. For anyone, regardless of the learning style; taking the time to really soak it in and get some hands on experience is key. The bottom line is that Drupal takes time and practice.

For those who do well on the solitary route, Build-a-Module, which routinely supports students and alumni of our career training program, has a solid, comprehensive library of instructional videos that you can take your time to work through with a modest monthly subscription.  You can also check out

For those who learn better with a formal course or need to train-up a team; our Drupal Career Online program uses live instruction; a stackable-skill designed curriculum; practical exercises; and group learning.  We also provide resources like lesson guides, screencasts for every lesson, and help when you need it. In addition to all the great feedback we get from our students and all the great graduate case studies, we ensure our program meets accepted educational standards as a career program, so we go through an annual review to ensure we remain a licensed, post-secondary institution through the Florida Department of Education, Commission for Independent Education (see page 21 of the linked PDF.)  

We are committed to Drupal and developing awesome Drupal talent, which is why we cringe when we hear about drinking-out-of-the-firehose learning scenarios. It is also why we have been perfecting our course (yes even making it longer) over the past 6 years. Best practices and allowing students the time to soak up what they’ve learned, along with hands-on projects and expert-developer instruction are fundamental elements of Drupal Career Online. It includes 84 hours of live, online instruction over 12 weeks as part of the learning community of current students and alumni. The course covers practical projects and assignments, and includes 12 co-working labs and instructor office hours, which are available to current students and alumni every week. The Spring 2017 session begins March 13, with the deadline to apply March 6.  

For most, learning anything, especially Drupal, is a process that takes an investment of time and effort, not just from the students, but from those who endeavor to help them learn.  Don’t cheat yourself and risk wasted time by trying to save time. Whatever learning styles work for you, make sure you take the time and put in the effort to follow a logical path that builds knowledge and helps you get comfortable with key skills in the way that ensures your hard work leads to your ultimate success.

For more resources about becoming a Drupal developer, take a look at our Career Resources.  To learn more about our upcoming Drupal Career Online Spring session, sign up for one of our free Taste of Drupal online information sessions in February.

take your time concept clock Photos by Pond5

Categories: Drupal

Convivio: Managing Microsites with Drupal 8

Planet Drupal - 25 January 2017 - 7:04am
There are lots of situations in which you need to run a series of microsites for your business or organisation — running a marketing campaign; launching a new product or service; promoting an event; and so on. When you’re with Drupal, though, what options do you have for running your microsites? In this article I review and evaluate the options in Drupal 8, make a recommendation and build a proof of concept.So, I want to run some microsites …

A client brought me an interesting problem recently, something they need to solve for their production Drupal site. They are an international humanitarian agency who, alongside their main production website, want to run some microsites for a number of their public campaigns. Although they could run them on the main site, they’ve found too many limitations in trying to do that. Campaign teams, frustrated with the lack of flexibility and slow protocols for getting changes made to support their bespoke needs, have often gone off with their small budget and dynamic team to create something quick that fits their campaign with Squarespace or Wordpress or something.

That made the campaigners really happy. But, when the campaign or event lapsed, the campaign site quickly got out of date and went unloved, the campaign team moved on and no-one could remember how to log into the system and it became abandoned.

Hearing this story was so familiar — the same thing often happened when I was a senior developer at Oxfam International.

So, they said, could something be done about it? What, if anything, could be done with Drupal to support campaigners get their microsites running? What would give them the fast, bespoke solution to their microsite problems, whilst still keeping all the content well-managed and being able to share that content with the main site or other microsites?

I scratched my chin and had a think.

How about Drupal multisites?

Since some of its earliest versions, Drupal has included a feature for multi-sites — running several sites from a single codebase installation, sharing the core system, contributed and custom modules and themes. Each multisite has its own database, its own settings and configuration, its own content, and so on. Ideally, it also means updates can be done once.

So, multisites could be an option. Many people find them to be a real workhorse for their context, and often they are right on the money.

Why use multisites

The documentation for multisites includes a simple rule-of-thumb for when to multisite:

As a general rule on whether to use multisite installs or not you can say:- If the sites are similar in functionality (use same modules or use the same drupal distribution) do it.- If the functionality is different don’t use multisite.

(DrupalCon Austin [June 2014] held a interesting debate on Drupal multi-sites, its pros and cons, gotchas and suggestions, which is available on YouTube.)

There’s several compelling reasons to use them.

First, having a single codebase to maintain is a huge plus. Forked codebases can soon become orphaned, and unloved codebases become fraught with problems too quickly.

Second, multisites often mean there is also a single hosting platform to maintain, which is also a major advantage.

That can often mean, thirdly, that multisite installations can make better use of resources, both the server resources and financial, personnel or other physical resources. For example, since multi-sites share the same core and modules, that code need only go into the opcode cache once, saving server resources.

Caveat: is the end of multisites support on the horizon?

It should be noted that a proposal has been made to deprecate support for multisites in Drupal, with a view to removing it in the future.

The basic argument for this is that it’s an ‘old skool’ way of thinking about handling multiple sites. Git and Composer create practices and codebase structures that point in other directions.

The modern approach to multi-site is: git — Same code, different sites. Under your control. And well-maintainable.

There are a number of positive reactions to that proposal, which are variations on a theme:

+1. Multisite is a historical oddity at this point and I’d never tell anyone to use it.

But there are many more negative reactions, which largely go along these sorts of lines:

-1. Multisite has been a workhorse for a ton of Drupal sites and is well established in our code.

In that light, Drupal’s multi-site feature is likely to stay around for a while.

Classic problems with Drupal multisites …

It’s not all a bed of roses, though. There are some classic sticking points when working with Drupal multisites.

First off, handling traffic. One site’s traffic spike can be another site’s nightmare when the hosting resources are all hogged by The New York Times tweeting a link to a page on a site of yours; one site’s ‘BEST DAY EVA!’ can be the worst of times for all the rest.

The load on your database server may also be an issue. Multisites often use a single database server, and heavy load or slow queries in one DB can impact the performance of others. This might even be caused in the normal running of your Drupal sites, such as when running cron.

Running updates often causes headaches. When you update code, you’re updating all your sites at once. That means the updates are deployed, well, instantly across all your sites, but if they need update processes to run, such as updating the database, that can throw unexpected problems or errors.

And the worst of the worst: a small piece of poorly written, inadequately reviewed or tested code mysteriously jumps itself onto production — that never happens, right? No one ever lets that happen, do they? *ahem* — and takes down all your sites at once! It’s just an urban myth, a story to scare the children with at night, right? Never happens.

… and how to mitigate them

There are of course a number of ways to foresee these things happening and be ready for them.

On the performance questions, with smaller demands you can just ride it out — sites on the same hosting platform are fairly tolerant of resources being shared around, and the spare capacity is there for times just like there.

For larger performance demands, handling the pressure is a challenge in any hosting set-up, dedicated hosting just as much as shared. With modern cloud infrastructure, the option of scaling up your infrastructure or spinning up a new cluster when you’re experiencing ongoing heavy demand is much easier than in the past, especially if you plan for it as a possibility.

The next set of mitigations are all about best practice.

For starters, test, test, test. Don’t let any code onto production that hasn’t been tested thoroughly.

Have a solid release process that you always follow. If possible, include dev, staging and quality assurance stages. This should give you lots of points to catch things before they’re released onto your production sites.

Automate all the things. There are lots of ways of automating things to ensure they run consistently and quickly too, from shell scripts up to continuous integration tools. Use them.

And finally, be intelligent. With code changes that need database updates, for example, design your code so that it can be deployed to handle an interval before the database is updated. Or, with important but more volatile updates, be smart about choosing the time of day and week that you deploy it. Don’t ever push something out at 5pm on a Friday afternoon if you want to stay friends with your colleagues, your customers and your family.

Well, yes, in short, kinda. You could run microsites using Drupal’s multi-site feature. Things would work fine, though of course you’d have all the problems described above and have to take the mitigating actions.

However, it wouldn’t solve all the needs described above without some smart thinking. Plus, I’d suggest that you would also have some other problems to solve.

First, multisites all use different databases (sharing databases and tables is possible with Drupal multisites, but really unadvisable!) so the need of a single place for managing all the site content wouldn’t really be satisfied. The way around that would involve using web services, posting and pulling content from one site to another.

Neither would we have a unified search. There are fairly straightforward ways around that, using a tool like Apache Solr. The sites would need to share an index, with each document in the index including a site field, and there’s a contrib module that does that already (although no Drupal 8 version yet).

Lastly, and maybe more pertinently, you would still have all the ‘Drupalisms’ to live with. First of those is the visual design layer, the public user’s interface for the sites, what gets called the ‘theme layer’ in Drupal lingo. Many designers really dislike Drupal’s theme layer, and would really prefer to work with the pure frontend tools they use in other contexts. Drupal 8 has made major strides forward with the theme layer so it’s not as tough for designers as it once was, it’s true, but many (most?) frontend specialists would still rather not work with it.

Some consider influential Drupal figures consider multisites as ‘not enterprise grade’ and opinions like that are worth considering if your situation is enterprise scale.

Other approaches with Drupal

There are a few other ways of supporting microsites with Drupal that might be worth considering.

Domain Access

The Domain Access project was created to support just this kind of functionality. The project overview says as much:

The Domain Access project is a suite of modules that provide tools for running a group of affiliated sites from one Drupal installation and a single shared database. The module allows you to share users, content, and configurations across a group of sites.

This might work. However, there are many of the same problems with core multisites described above with this approach, with one additional one: everything in one database.

Our experience of using it, and this is echoed by others too, is that with a small number of very similar sites Domain Access can work well. With a larger number of fairly different sites, it’s a right pain and actually makes things quite difficult, requiring lots of complicated custom code.

Organic Groups

The Organic Groups suite of modules could be a solution for building microsites. The project allows users to create a ‘group’ within a Drupal site. The group can have its own users, admins, content, menus, even its own visual design. However, it would need every microsite to sit internally, within the main site, so does not solve the need to supporting external sites on their own domain. So, not really the perfect fit.

Best practice: with Git

I quoted above from @sun in the discussion on deprecating multisite support about the modern best practice:

The modern approach to multi-site is: git — Same code, different sites. Under your control. And well-maintainable.

This is certainly my standard recommendation and will give you many advantages: independence of sites for performance, design, etc; single codebase to maintain (though you’ll have a challenge developing and maintaining the variations you’ll want or need for each microsite); better control over updates; and so on.

You might even look writing an install profile to make a full distribution, though with Drupal 8 there is less of a need to do this. With Drupal 8, I’d advocate that you use Drupal Composer to build your site and just export your full site config into your repo (being careful to remove any sensitive settings from the repo with your .gitignore file).

Or you might also consider using Aegir to manage your multiple sites — use Drupal to deploy Drupal, if that’s not too much Inception.

Microsites and Drupal

So if multisites could work but would be a bit of a pain, the other Drupal approaches are even less appealing, and you’d rather not keep multiplying Drupal installations, how else could we do microsites with Drupal?

Well, there are two major moves in modern web development that might help here: RESTful web services, and decoupled CMS architectures (a.k.a. ‘headless’ CMS). My proposal for managing microsites in Drupal 8 depends on both these ideas:

  • Treat your Drupal site as a pure content management system (CMS) — a content hub that allows authors, editors and administrators to create, update and manage the content for which they’re responsible, but doesn’t have any meaningful frontend presentation layer to it.
  • Present the data of the content in the hub CMS via a RESTful API.
  • Implement a separate frontend for the visual presentation layer that communicates with the content hub CMS via the API.

There need be no limit to the number of frontends that use the CMS’s API (though practically you may limit access with firewalls, CORS or some other means) so you could power a primary public site, other sub-sites, native mobile apps or even another CMS or two, each potentially with their own visual design. The limit is your own imagination and situation.

RESTful web services and Drupal 8

A new addition to Drupal 8 is the RESTful Web Services API. REST resources can be exposed to allow other things to talk to/consume/feed a Drupal site. Many core entities have REST resources, but it is also fairly easy to build custom REST resources. (There a number of interesting web services contrib projects that are worth considering, such as the GraphQL project that presents a GraphQL schema, and the RELAXed Web Services project that extends the core REST resources.)

Design your own web services API

The freedom to build custom REST resources in Drupal 8 allows a lot of freedom in designing a RESTful API.

In a forthcoming blog post I’ll write in more about designing an API. For now, all I need to say is you need to actually design your API. Don’t simply use the out-of-the-box Drupal core REST resources — think about the RESTful API that would best serve the frontend you want to have.

My heartfelt recommendation is you do this, designing your API, using the skills of those who’re best at designing things — your designers. They understand best what your users want to do on your sites, will be able to describe what data they want for the frontend (content with/without markup, etc.) and help you design the API that is most appropriate to your needs.

There are some API design golden rules and best practices that you should consider. Also I’d recommend using an API design tool like or They’re invaluable for many reasons, not least of which is the lovely documentation they generate and mock data servers they include that can help frontend devs get going quickly.

Decoupled frontend

With the content hub now presenting the managed content as RESTful data, we just need a standalone frontend system to present your website to your users: one for your primary site, and one for each of your microsites. Your frontend specialists can then work with the right tools for the task, then.

There are several advantages to consciously uncoupling the content management and the frontend.

Freedom: frontend specialists are free to the implement the user experience with native tools that are built for the job.

Performance: everything in this architecture can be streamlined. The CMS simply presents the content data. The frontend focuses on the display logic.

Experience: the website can respond to users in real time, communicating back and forth with the CMS to give real-time interactions in the browser.

Future proof: it becomes much easier to replace any part of the system as you require, such as redesigning the website without re-building the CMS.

Microsites in Drupal 8

So, how might we do this practically in Drupal 8? Here’s how I tackled it.

First, I thought about designing a quick prototype API that could be used to describe microsites and their content. I used to design it, and you can view the API at

API design at

Next, I installed a Drupal 8 instance with Drupal Composer to act as the editors’ content hub and created a ‘Campaign’ content type with some basic fields. This ‘Campaign’ content type is the core of the microsite support. Each Campaign creates a new microsite.

Since in this client’s conundrum the microsites can be internal (i.e. sit within the main public site) or external (i.e. on their own domain or sub-domain) I added two fields:

  • external site (true/false boolean)
  • external URL (URL)

These will allow requests for the microsite from within the main site to be redirected to the external URL, and will help in constructing the right data in the API resources.

‘Campaign’ content type in Drupal content hub

I also adapted the core Article content to include an entity reference to a ‘Campaign’ node, and included a taxonomy reference field to indicate the ‘type’ of article — news; FAQ; info; etc.

The next task was to create the REST resources that matched the APIs I’d designed. For this I created a custom module, campaign_api, and created four classes, one for each of the API resource collections I’d designed, in the `Drupal\campaign_api\Plugin\rest\resource` namespace.

Drupal custom module for the new REST resources

The quick and dirty code for the `get` method on the Campaigns resource looks like this:

* Responds to GET requests
* Returns an array of Campaign data.
@param null $unserialized
@param \Symfony\Component\HttpFoundation\Request $request
@return \Drupal\rest\ResourceResponse
public function get($unserialized = NULL, Request $request) {
$build = [];
// Default langcode
$langcode = $request->query->get('langcode', 'en');

// Load campaign nodes
$query = $this->entity_query->get('node')
->condition('type', 'campaign')
->condition('langcode', $langcode);

$nids = $query->execute();
$campaigns = \Drupal::entityTypeManager()->getStorage('node')->loadMultiple($nids);

// Array of image styles to support
$image_styles = [
'large' => 'full',
'medium' => 'medium',
'thumb' => 'thumbnail'

/** @var NodeInterface $campaign */
foreach ($campaigns as $campaign) {
$image_array = [];
$image_file = File::load($campaign->get('field_image')->target_id);

foreach ($image_styles as $name => $style_name) {
$style = ImageStyle::load($style_name);
$image_array[$name] = [
'url' => $style->buildUrl($image_file->getFileUri()),
'alt' => $campaign->get('field_image')->alt,
$external = (integer) $campaign->get('field_external')->getValue();
$build[] = [
'id' => $campaign->id(),
'uuid' => $campaign->uuid(),
'langcode' => $campaign->language()->getId(),
'languages' => [
$campaign->language()->getId() => $campaign->language()->getName(),
'default' => $campaign->language()->getId(),
'title' => $campaign->getTitle(),
'created' => $this->date_format->format($campaign->getCreatedTime(), NULL, 'c'),
'external' => !empty($external),
'external_url' => $campaign->get('field_external_site_url')->getValue(),
'description' => [
'formatted' => check_markup($campaign->get('body')->value, $campaign->get('body')->format),
'raw' => $campaign->get('body')->value,
'image' => $image_array

$response = new ResourceResponse($build);

return $response;

Enable those resources (by clicking stuff with REST UI module installed, if you like), of course, and then create some content to populate the responses — one campaign called ‘DIY succulents’ and the other ‘Slow-carb cred’ (yep, I used some Hipster Ipsum).

Enable the resource endpoints

Then you should be able to retrieve your data at the appropriate endpoints. A nice way of doing that is with the free Postman app (there’s a Chrome extension also). Postman makes a request to the endpoints you specify and pretty-prints the response. Marvellous!

The final part is the standalone frontend tool. For this I used React. I used React to build my frontend app, but there’s obviously plenty of other options depending on what the frontend needs to do. React worked for me because I just wanted the view layer, but Angular or Ember could be more appropriate if the frontend needed to be a more substantial app. You’d need to evaluate the frontend options carefully.

I’m not a frontend specialist, so my prototyping code is pretty fugly. Despite that, we’re able to serve two microsites simultaneously on different URLs, with a different theme, just by switching the campaign ID in the API request.


Deploying to production

There’s a few things I might do to deploy this to a production system.

Secure serving

As a good internet citizen, I’d want to put everything on SSL.

Frontend deployment

To deploy the frontend, I’d be looking at options to run the apps on a NodeJS server so that most of the scripts can run server side.

I’d probably want to put an Nginx instance in front of it, for SSL termination, caching static assets and reverse proxy.

Use Drupal multisites ;-P

I think there is actually a neat way of using Drupal’s multi-sites feature here: use a different domain for the RESTful API. For example:

Editorial interface:
API interface:

Both of these point to your Drupal codebase but you can then handle requests differently on each domain. For example, you might add an authentication provider that checks the domain to give you some access control, so there’s no access to the editorial interface on the API subdomain, and none to the API on the editorial domain.

Caching etc.

This would then allow you to do some smart things with caches and other parts of your hosting stack, offloading much of the pressure on the codebase to the caching architecture and removing the actions of editorial staff from affecting the RESTful API’s performance.


It might also be possible to configure GET requests to only use a slave database, which could be useful for performance — though may be more hassle than it’s worth. POST, PUT, PATCH and DELETE requests would still need to go to the master.

In summary

This prototype worked really well for me and I was very happy with the results, and it gave me something very interesting to discuss with the client.

The advances made in Drupal 8 to operate with current standard web practices are good news for developers and for web projects big and small. For this prototype, the particular improvements with providing RESTful resources means that I was able to create a decoupled Drupal system to support a main website and unlimited microsites in an amazingly short space of time.

… and something to take away

If you’re interested in following up this thought experiment with my Drupal 8 prototype, I’ve put the code into a repo in GitHub:


Just …

$ git clone {some_empty_directory}
$ cd {some_empty_directory}
$ composer install

… and you’re away.

(My React code is shamefully dirty, so I’m not prepared to share that at moment. ;-) I may tidy it up in the future and share it here.)

Main image: courtesy of Denys Nevozhai/Unsplash.

Convivio helps organisations to work better for people.

We do this mainly by helping them transform their services using digital tools, but also by spreading new ways of working.

Read our blog:
Follow us on twitter:
Get in touch:
Visit our website at

Managing Microsites with Drupal 8 was originally published in Convivio on Medium, where people are continuing the conversation by highlighting and responding to this story.

Categories: Drupal

Fantasy Flight Games Posts New Ghosts of Dathomir Preview

Tabletop Gaming News - 25 January 2017 - 7:00am
Ever since we all first saw Darth Maul light up the second half of his double-bladed lightsaber, we’ve all been enthralled with it. It has come to be known simply as a symbol for “badass.” Well, in Ghosts of Dathomir, a new adventure coming for the Star Wars RPG from Fantasy Flight Games, your group […]
Categories: Game Theory & Design

Evolving Web: SiteDiff - Compare multiple versions of a website

Planet Drupal - 25 January 2017 - 7:00am

Introduction and quick guide to using sitediff - a handy site version comparison tool which helps you detect changes between various versions of a website.

read more
Categories: Drupal

[DevLog] HÄŌS - Minimalist Psychedelic Meditative Action - by Eric Howard Blogs - 25 January 2017 - 6:55am
In 48 hours, my team of 3 members created what I consider a super balanced combination of trippy art game and mechanical action. This surprised us. Once we started adding SFX and "juice" it came together so well that we knew we'd hit something special.
Categories: Game Theory & Design

Community Can Help You Build a Killer App... But Don't Make This Mistake - by Felipe Lara Blogs - 25 January 2017 - 6:53am
The most successful games of the last few years have all helped us connect socially: “World of Warcraft,” “League of Legends,” “Pokémon Go”. But for social features to work, they need to happen at the right time and place in your experience.
Categories: Game Theory & Design

Does the story even matter? - by Sergio Ortiz Blogs - 25 January 2017 - 6:52am
Some people (including me) consider video games a form of art. It’s the next step in storytelling because the audience ceases to be a passive spectator and becomes and active player. The main character’s problems and fears become yours, whatever he suffer
Categories: Game Theory & Design

No name recognition? Here’s how to build loyalty with your players - by Mark Rosner Blogs - 25 January 2017 - 6:51am
if you’re an indie developer launching a game with no name or brand recognition, you do need to pull out all the stops when it comes to building a loyal user base. Here are some tactics that can keep players coming back to your game again and again.
Categories: Game Theory & Design

Augmented Reality through real time feature tracking on current generation mobiles. - by Bart de Bree Blogs - 25 January 2017 - 6:49am
This article is about a feature tracking plugin that I am developing.
Categories: Game Theory & Design

How to Create Viral Quiz Games Without Programming Experience - by Alex Moore Blogs - 25 January 2017 - 6:49am
Many of us have the desire to create something to share with the world. In the gaming industry, this often means that one must have the ability to program in order to develop a game.
Categories: Game Theory & Design

How to create and sell a game with a small team - by Guilliermo Ford Blogs - 25 January 2017 - 6:49am
Some tips and thoughts on how to develop and sell your first indie game from my hand-on experience.
Categories: Game Theory & Design

WizKids Previews Superman vs. Muhammad Ali Convention Exclusive For HeroClix

Tabletop Gaming News - 25 January 2017 - 6:00am
While comics take place in a world much like ours (except where you can have giant aliens and robots and such, of course), they’re usually a step apart and you don’t get too many real-world crossovers. Well, back in 1978, DC brought boxer Muhammad Ali to their pages where he sparred against none other than […]
Categories: Game Theory & Design

PoolParty Taxonomy Manager

New Drupal Modules - 25 January 2017 - 5:56am

The PoolParty Taxonomy Manager exports taxonomies to and imports vocabularies from a PoolParty Thesaurus and keep them in sync.

Categories: Drupal

DrupalEasy: DrupalEasy Podcast 190 - Ted Sings! (Dan Schiavone, Elizabeth Lipinski - DrupalCon Baltimore Sessions)

Planet Drupal - 25 January 2017 - 5:30am

Direct .mp3 file download.

Dan Schiavone (schiavone), President, Snake Hill Web Agency, and local lead front end track for DrupalCon Baltimore and Elizabeth Lipinski (lizardata), Technolgy Strategist (also from Snake Hill) and the local lead business track joins Ted and Mike to discuss session submission for DrupalCon Baltimore. We also discuss Media in Core and changes to Drupal marketplace rankings before making our picks of the week!

Interview DrupalEasy News Three Stories Sponsors Picks of the Week Upcoming Events Follow us on Twitter Five Questions (answers only)
  1. Turning conference t-shirts into other things.
  2. Avast (anti-virus software).
  3. Not afraid of anything.
  4. Storks.
  5. Dan was jazzed after DrupalCon DC.
Intro Music Subscribe

Subscribe to our podcast on iTunes, Google Play or Miro. Listen to our podcast on Stitcher.

If you'd like to leave us a voicemail, call 321-396-2340. Please keep in mind that we might play your voicemail during one of our future podcasts. Feel free to call in with suggestions, rants, questions, or corrections. If you'd rather just send us an email, please use our contact page.

Categories: Drupal

Extra Layouts

New Drupal Modules - 25 January 2017 - 5:22am

This module contains extra layouts for the Layouts module, ans usable e.g. for Display Suite and Panels.

Currently it contains

  • A 3-column 25-50-25 content-first layout
  • A 3-column flexible layout

The content-first layout has the following properties:

Categories: Drupal

Wayback Submit

New Drupal Modules - 25 January 2017 - 4:43am

You are, of course, publishing your new articles to your own website.
But you could, by checking a box, make sure that the scraper form came around and grabbed your new articles.

Categories: Drupal

The Steam Controller Configurator's Untapped Power - by Lars Doucet Blogs - 25 January 2017 - 1:01am
Did you know you that Playstation and XBox controllers are now also "Steam Controllers?" It's all thanks to the Steam Controller Configurator.
Categories: Game Theory & Design

Character Arcs

Gnome Stew - 25 January 2017 - 1:00am

Arc De Triomphe – Photo by J.T. Evans

In fiction writing, there are three generally accepted character arcs: change, growth, and failure. Of course, in writing novels, the author can plan and plot this all out for maximum effect. In the collaborative storytelling nature of role playing games, this is much more difficult. The player may want a growth arc, but is continually given choices that lead to either change or failure. Before I dive into the nuances, let me explain the different types of arcs a character can experience.

Change Arc

The series of events in the story leads to a change within the core of how the character acts within, reacts to, or views the world around herself. Something integral and incredibly different comes about in the very nature of the character. Sometimes, it’s something held deep within the character that finally surfaces, and other times this comes about through strong external forces being applied to the character to force the fundamental change.

These changes can include the coward becoming brave in the face of adversity, the introvert leading troops into battle after an inspiring speech, the “farm boy” stepping up when needed to be the hero to overthrow a despot. These changes don’t have to be world-shattering. Even the “class nerd” gaining the courage to ask a a pretty girl out to prom can be monumental to the character.

Keep in mind that this arc is how the character changes within their world, not how they change the world around them.

Growth Arc

This is the typical arc for most PCs. They grow in ability, power, prestige, and honor. However, I challenge players and GMs to find ways to evolve the characters’ internal traits to be stronger and better, not just the numbers on the page. This can be done by taking the noble squire and giving them greater responsibilities within his honor code, or putting more folks within the care of a friendly healer. These external changes to the world around the character can bring about strong, internal changes to the PC.

If a player wants a growth arc for their character, they need to plant seeds in their brief backstory. Then they need to make sure the GM is aware of the seeds and where the player wants them to grow. Then it’s up to the GM to weave in moments and NPCs from the backstory for the PC to take advantage of. This is a bit more work for the GM, and a careful balance must be put to use to ensure one PC is not always in the spotlight. However, the player will be more invested in the game through their growing character, and this leads to more fun for everyone at the table.

Failure Arc

This is another popular arc for PCs. When I talk about failure, I’m not talking about the “natural 1” on a d20 (though, that can be a catalyst for a shift in the character). The best example in fantasy role playing literature of a failure arc is that of Lord Soth from the Dragonlance realm. He was a powerful knight who fell from grace through a series of events and ended up becoming one of the most dreaded undead in all of D&D lore, the Death Knight.

Going through failure arcs for PCs is tricky in nature because it usually ends up with the player handing their character over to the GM for an extended period of time, if not permanently, while the former PC turns into an opposing force as an enemy NPC. This is not always the case, but it is a very distinct likelihood. It all depends on how things play out.

Failure arcs typically happen to those with some decent power or ability already in hand. It’s hard to start out as a dirt farmer and fall much lower than that. That means these types of arcs are a slow burn with a long build up. Anyone interested in a failure arc for their character must be prepared to wait for the payoff, but it can be very interesting when it happens.

As GM, I tend to use the failure arc on a PC-turned-NPC because of a player leaving the group. It’s interesting for everyone at the table to see a former ally show up at a pivotal moment (the group usually expects assistance) and then the ally turns out to be an enemy in disguise. I don’t always play the betrayal card this way, but the times I’ve done it in the past, it’s been incredibly rewarding for everyone at the table.


Find an arc for your character. It will make playing them quite a bit more fun as you see the core of the character’s traits evolve with the statistics on the sheet of paper. For GMs, find ways to allow characters to change over time. Perhaps the salty rogue has a heart of gold and will eventually evolve into a shining paladin. It sounds like a long stretch, but I’ve seen it happen.

How do you see your characters change and evolve over time? Let us know in the comments!

Categories: Game Theory & Design

Flocon de toile | Freelance Drupal: Set up a guided tour on Drupal 8

Planet Drupal - 25 January 2017 - 1:00am

Drupal 8 has a new core module, the Tour module, which allows us to set up a contextual help to guide users of a Drupal 8 site for their first steps on it, whether for the discovery of their user profile, the possibilities offered to them, how to create content or the overall management of the site's contents.

Categories: Drupal

The RPGnet Newsletter: RPGnet Newsletter #85

RPGNet - 25 January 2017 - 12:00am
Gangbusters, OSR, and more.
Categories: Game Theory & Design


Subscribe to As If Productions aggregator