Skip to Content


Drupalize.Me: New Tutorials: Manage Drupal Sites with Pantheon

Planet Drupal - 19 August 2015 - 6:30am

Today we are happy to present a new series teaching you how to Manage Drupal Sites with Pantheon, which is completely free thanks to the generous sponsorship of Pantheon. Pantheon is a great service for management your website development and launching your sites on an environment that has been optimized for Drupal.

Categories: Drupal

Zyxware Technologies: [Drupal] What is the usage of drupal_write_record function in Drupal 7?

Planet Drupal - 19 August 2015 - 4:39am

The drupal_write_record function is used to insert or update a record in the database based on the schema of the table. It helps in executing less database query. Let's take a look at the function given below.

DrupalDrupal 7Drupal Planet
Categories: Drupal

Realityloop: Testing, Testing, 1, 0, 1

Planet Drupal - 19 August 2015 - 1:04am
19 Aug Stuart Clark

At Realityloop I've been involved with some extremely complex site builds, varying from Commerce driven paywalls to fully fledged data reporting web applications. Yet, the hardest thing I've ever had to do is successfully sell automated testing to a client.

And the reason for that is relatively simple; Tests are hard to write, therefore time consuming and expensive.

However this is a misconception, while certain types of tests can be hard to write, any automated tests will recoup the costs in a short amount of time, and as such, you can’t afford not to have tests.

In part one of this post I will be explaining exactly why you need tests. In part two (due in three weeks) I will cover how to get started and implement your automated tests.


What are tests?

A test is exactly what it sounds like; a method to ensure that your project behaves as is expected.

Any steps taken by an individual to ensure the project is behaving correctly are considered to be manual tests, and while they are essential, they are time consuming.

For an example of what a test may be, let's look at the following scenario:

Fictitious Inc want a contact form on their website that will send emails to specific recipients based on the type of enquiry.

They need three enquiry types:

  1. Support to

  2. Sales to

  3. General enquiry to

Along with this requirement, they also wish to have a personalised auto-response per enquiry type.

Once this the above functionality has been created, all parties, at some point, will need to ensure that it does indeed work as expected.

This process is your manual test, which would look something like this:

Jarkko navigates to his Fictitious Inc. development site, clicks on the Contact menu item, selects the Support enquiry type, fills out some dummy data and submits the form.

He then ensures that the email was sent to the correct email address with the supplied data, and ensures that received the correct auto-response with the correct personalisations given the supplied data.

Lastly, he repeats the process with the other two enquiry types, ensuring that he supplies different data to his previous test(s).

That’s a test, and a relatively simple test, but already it's evident that it is time consuming. Throw in more complexity to the requirements and the time increases exponentially.

Any future work on this project, regardless of the area of work, should ensure that these same tests, as well as any other tests in the site, are run again. Otherwise you run the risk of accidentally breaking a core feature of the project.

As such, manual testing becomes excessively time consuming, and often a step that is skipped by all involved.

Automated testing is the answer.


What are automated tests?

There are various types of automated testing, but for the sake of this post I will be concentrating on "integration tests".

An automated test is, again, exactly what it sounds like; an automated method to ensure that your project behaves as is expected.

Take the previous scenario, currently each individual involved in the project (developer, tester, project manager, client, etc) could be spending anywhere between 2 and 10 minutes to manually test that small subset of the project functionality every time any changes are made to the project.

Automated, the same test should take no more than a 30 seconds in total, and can be run along with all other automated tests in one quick hit.


Manual testing vs Automated testing

In the above video you can see the Automated test running side-by-side with the Manual test.

The Automated tests are not only testing the same scenario as my Manual tests, but also installing a fresh copy of Drupal, enabling all required modules, flushing caches, reverting features and running a few additional checks that I didn't do in the Manual test.

For those of you who do not wish to watch the video, the results are as such:

Manual testing - 3 minutes 19 seconds

Automated testing - 27 seconds

However, there is still a time investment involved to create the tests. In this case it took me roughly 60 minutes to write the tests, in which time the manual tests could have been run about 18 times, assuming of course your manual tester doesn't decrease efficiency after running each test.



Continuous Integration

With the above simpletest, the responsibility of running the tests is still in the hands of a human, and as such you will only get your test results if someone bothers to run the tests.

Continuous integration relieves your human workers of that responsibility, instead automating the running of the automated tests.

Travis CI is one such service which is relatively well loved by the open source community due to the direct integration with Github.

Along with the benefit of running automated tests on every commit (or tag, if that is how you wish to configure it), Travis can run multiple testing jobs concurrently, allowing you to ensure you project works on a variety of different environments.

Travis CI jobs do take longer than running a Simpletest (based on my above video), which is due to Travis not only doing all the additional things that Simpletest is doing but also having to setup a complete environment prior to installing Drupal. However, as you can run potentially upwards of 10 concurrent jobs (on a Premium plan) this time loss is quickly negated.

Assuming you are on a free plan, and the current load on the server allows for 4 concurrent jobs taking a maximum of 1 minute and 20 seconds (the average from my own tests), you recoup the cost of the test development in only 4 commits.

Adding Travis integration to your Drupal project is relatively simple thanks to the Drupal Travis Integration project. It’s as simple as adding and configuring single file to your Github repository. However I’ll go into more detail on this in part 2 of this post.

drupaldrupal planet
Categories: Drupal

KnackForge: Drupal 6 Re-initializing Gmap in Jquery

Planet Drupal - 18 August 2015 - 11:15pm
Assume, I am able to print the gmap using Drupal code in a div. I would like this map to appear inside a fancybox and to be hidden on the website. I've managed to do it (fancybox works ok) however the map is not displayed correctly, I am getting "Javascript is required to view this map".   Here is an *experimental* method, that may allow you to successfully reboot a map.  
  1. // Init Fancybox
Categories: Drupal

KnackForge: How to deal with hover on touch screen devices

Planet Drupal - 18 August 2015 - 10:27pm
Links with hover styles on touch devices are a bit of a complication. In short, they don’t really exist on these devices. Creating fancy :hover styles can really add to the browser experience and help simplify your layout, but they simply will not work on a touch device. When a tablet or smartphone user taps your hover-styled link elements, the hover style shortly appears, and immediately the underlying link is followed/activated.   So how do we handle this problem? Do we sniff out touch devices and disable hover classes? Not at all: it can be fixed using jQuery, and with some minimal adjustments you can keep using your hover styles across all browsing devices   THE GOAL   When a touch user taps menu A, only the hover style for menu A is activated but the link does not open. After this, there are two possible options:   1. User taps menu A again -> menu A is opened. 2. User taps menu B -> mouseover for menu B is activated and the hover style for menu A is deactivated.   Another thing to keep in mind is that if a user taps menu A, then taps menu B and then taps menu A again, it should not consider menu A as being tapped for a second time (which would lead to the browser to open the link).   WHAT WE NEED TO ACCOMPLISH   To realize our goal, we need to accomplish the following using (jQuery)  
Categories: Drupal

KnackForge: Configure SOLR for Spatial Search Setup

Planet Drupal - 18 August 2015 - 10:18pm
Configure SOLR for Spatial Search Setup ----------------------------------------------------   One of our projects requires the spatial search to find the closest records for given address OR zipcodes. So we decided to use SOLR for performing spaital search based on latitude & longitude for getting the closest records.   This blog describes on SOLR configuration for location based spatial search and how to run queries on SOLR.   You can download latest SOLR from here :   Schema Changes :   To add location data (latitude, longitude) in documents, we need to update the schema.xml file. We need to add a new field type (specifically used for geospatial searching). In case it's not already present (depends on SOLR version), we have to add the below fieldType definition to the schema.xml file.   <fieldType name="location" class="solr.LatLonType" subFieldSuffix="_coordinate"/>   FieldType definition is done. Now we need to define the fields for location data.   <field name="latlon" type="location" indexed="true"  stored="true" />   indexed=true makes a field searchable (and sortable and facetable). For eg, if you have a field named test1 with indexed=true, then you can search it like q=test1:foo, where foo is the value you are searching for.   stored=true means you can retrieve the field when you search.   Indexing Location Data  
Categories: Drupal

Modules Unraveled: 145 Project Workflow and Drupal Issue Queues with Joshua Mitchell - Modules Unraveled Podcast

Planet Drupal - 18 August 2015 - 10:00pm
Published: Wed, 08/19/15Download this
  • Prioritizing work on Roadmap
    • Unblock Drupal 8
      • DrupalCI - testing infrastruture for Drupal code
      • upgrade to D7
    • Improve search
    • Implement new documentation section and tools
  • Two Factor Authentication
  • Issue Credits
  • Funding work
    • D8Accelerate
    • Ongoing Funding
Work that is coming later Questions from Twitter
  • hussainweb
    I think a hierarchical menu system has it's place - Gives a continuity and mark progress if you want to read a topic. #MUP145
  • hussainweb
    Can you attribute different patches in a single issue - some to the organization and some as a volunteer? #MUP145
  • hussainweb
    Some issues get abandoned after some work. Is that never counted? #MUP145
  • Paulius Pazdrazdys
    How much forums are being used? Maby you are thinking to more question -> answer model as stackoverflow has? #MUP145 (Issue about the subject - Petition to move forums to Stack Exchange)
Episode Links: Josh on drupal.orgJosh on TwitterTags: drupal.orgplanet-drupal
Categories: Drupal

Colan Schwartz: Get search results for compound words not in content with Drupal, Search API and Solr

Planet Drupal - 18 August 2015 - 4:01pm

It is possible to expand compound search terms to multi-term synonyms. That is, if your Drupal site content contains text such as "dark room" or "key note", and you don't want your users to get No results pages on searches for "darkroom" or "keynote" (respectively), you'll need to do a bit of extra work to make this happen.

Let's assume we've got a Drupal 7 site working alongside Solr to provide the advanced back-end search functionality, and the Search API plus Search API Solr Search modules to integrate the two systems. At the time of this writing, this is a widely used best-practice approach. However, it doesn't natively support the above use case.

Some potential options for setting this up include spellchecking and fuzzy searching. But Solr itself already supports the use of synonyms even though the Search API does not. So let's tweak Search API's set-up to work with it.

There are several steps required to make this happen.
  1. If you're got the tokenizer enabled on your search index, disable it by unchecking the box over at Administration » Configuration » Search and metadata » Search API » Your index name » Filters » Processors » Tokenizer, and then save the configuration. If the Tokenizer option is enabled, it will prevent the synonym functionality from kicking in.
  2. Modify the Solr configuration in your search collection over at /path/to/solr/collection-name/conf/schema.xml around line 162.
    • Before:         <!-- in this example, we will only use synonyms at query time
              <filter class="solr.SynonymFilterFactory" synonyms="index_synonyms.txt" ignoreCase="true" expand="false"/>
    • After:         <filter class="solr.SynonymFilterFactory" synonyms="synonyms.txt" ignoreCase="true" expand="true"/>
  3. Define multi-term synonyms in the synonyms.txt file that's in the same folder as the above schema.xml file. Follow the form here.
    • darkroom => dark room
    • keynote => key note
  4. Restart the search engine. This is system dependent, but if you're using the GlassFish application server for example, you may be able to restart Solr with a command like sudo service GlassFish_solr restart.
  5. Clear the search index and rebuild it.
    1. Surf to Administration » Configuration » Search and metadata » Search API » Your index name.
    2. Hit the "Queue all items for reindexing" button.
    3. Hit the "Index now" button.

That should do it. You're all set!

Background reading For more information on how all of this really works, here are some useful articles on the subject.

This article, Get search results for compound words not in content with Drupal, Search API and Solr, appeared first on the Colan Schwartz Consulting Services blog.

Categories: Drupal

Shitiz Gag's Blog: [GSoC 2015: Hawk Authentication] Week 13: Final weeks

Planet Drupal - 18 August 2015 - 11:21am

GSoC is coming to a close, so these few weeks have been mostly about wrapping things up. This is good for me as well because college has taken a toll so I have less and less time to spend, but I believe I have enough to have the module at a good position before GSoC closes.


WWW-Authenticate is a HTTP header which is used to identify which protocols the server supports. If a server supports multiple WWW-Authenticate headers, it can send it multiple times to identify different protocols. For example: Drupal can send WWW-Authenticate: Hawk and WWW-Authenticate: Basic for identifying that it supports Hawk and Basic Auth. However, Drupal at the moment doesn’t have support for gathering and sending multiple header values from different modules due to the way it handles 401 Authentication Required exception. I will be working on allowing multiple protocols to send WWW-Authenticate so that multiple auth protocols can be identified at the same time.

Testing Hawk and Basic Auth together

I also spent a considerable amount testing these two protocols together, here is a summary of my findings but in summary: Both protocols work well individually but if a client sends requests containing both protocol’s headers at the same time it would cause either to fail due to the way HTTP protocol dictates concatenation of header values. HTTP recommends allowing only a single protocol in one request in order to have fewer points of failure so for the moment I believe this behaviour is fine, however if it is deemed beneficial to allow multiple protocols within same request it is always a possibility.

For now that is all, I’ll be dealing with WWW-Authenticate issue and documentation during my last week of GSoC.

Thank you for reading!

Categories: Drupal

Drupal for Government: Virginia Physician API and Data Mining

Planet Drupal - 18 August 2015 - 9:54am

So recently we discovered and since we're looking to help people in Charlottesville I've added the data (thanks to feeds) and we added a couple of data mining points (using open layers)for the maps and h

Categories: Drupal

benamer: Check out the Chartbeat Most Popular module

Planet Drupal - 18 August 2015 - 9:30am

You know those lists on a web site that you see from time to time listing the currently Most Popular articles on the site? I have to admit that I click on them from time to time to understand what is popular and why. It's a clear case of herd reading. Well, Drupal has a new module to create a Most Popular list on your site based on the Chartbeat Analytics API and it's written by myself and Darryl Norris. It's available on 

Categories: Drupal

Can crunch ever be fixed in the game industry?

Social/Online Games - Gamasutra - 18 August 2015 - 9:01am

"One of the puzzling attitudes I've seen in the games industry is companies talking about focusing on long term success, yet not taking a firm position against crunch." ...

Categories: Game Theory & Design

Mediacurrent: Accessible Names - Label All the Things! (Part 1)

Planet Drupal - 18 August 2015 - 8:24am

The more we label things when building a website, the easier it is for a person who is blind and uses a screen reader to use our sites. These labels are known as the “accessible name properties” and they are baked into HTML.  

Categories: Drupal

Monster Strike making $4.2 million a day in sales

Social/Online Games - Gamasutra - 18 August 2015 - 7:46am

Japanese developer Mixi has revealed that its co-op action RPG, Monster Strike, brought in $378 million between April 1 and June 30 - that's $4.2 million a day. ...

Categories: Game Theory & Design

Chromatic: How To Write A Great Commit Message

Planet Drupal - 18 August 2015 - 7:02am
So annoying. Fixed a bug! Hope I never see this again.

These are not great commit messages; in fact, they are nearly worthless. A great commit message should tell the reader all they need to know about the what of the commit. They should only have to look at the actual diff of the commit to see how it was accomplished.

Anatomy of a Great Commit Message

Think of a commit message like an email:

  • It contains your contact information. You don't even have to do anything; you get this for free!
  • It should have a subject: the shorter, one-line summary.
  • A body: the detailed description.

All commit messages should abide by the following criteria:

  • Begin with a one line summary. It should be capitalized and succinct (50 chars or less).
  • This should be followed by a longer description, if necessary.
  • The first two items should be separated by an empty line.
  • All lines should be wrapped at approximately 72 characters.
  • Reference an issue in your commits whenever possible. If using Github issues, you can reference them by using 'gh-80' for issue '#80'. If your commit completes the issue, you can use a number of terms to close the issue, such as: .Closes gh-80'.
  • If you forget to reference the issue in your commit, and the commit has already been pushed, reference the commit's hash in a comment on the ticket.

Here is a model Git commit message:

Capitalized, short (50 chars or less) summary. More detailed explanatory text, if necessary. Wrap it to about 72 characters or so. In some contexts, the first line is treated as the subject of an email and the rest of the text as the body. The blank line separating the summary from the body is critical (unless you omit the body entirely); tools like rebase can get confused if you run the two together. Further paragraphs come after blank lines. * Bullet points are okay, too. * Typically a hyphen or asterisk is used for the bullet, preceded by a single space, with blank lines in between, but conventions vary here. * Use a hanging indent. Closes gh-80.

The majority of your commit messages may be much simpler than the example above, but pick and choose the appropriate elements. Here is an example more common to the real world:

Fix for editor dashboard showing incorrect date. * Fixed date calculation logic. * Added function docblock to comply with coding standards. * Refactored foreach loop, improving clarity. Closes gh-80.

With just a few small improvements to your commit messages, your fellow developers, and your future self will surely thank you!

Categories: Drupal Featured Case Studies: AL DÍA News

Planet Drupal - 18 August 2015 - 6:21am
Completed Drupal site or project URL:

ALDÍ is a national news outlet offering fully bilingual content, equally accessible in both English and Spanish at the click of a toggle. The new site - which publishes news related to politics, business, culture, opinion, media, and technology - allows readers to quickly and easily choose the language in which they want to view a comprehensive array of content and features optimized for various devices through responsive design.

After evaluating AL DÍA’s content and traffic, we uncovered the untapped potential for a larger audience and advertising stream by repositioning this local news site as a national news platform. The new site implements a number of innovative elements that benefit viewers and advertisers alike, including lightning-fast browsing using AngularJS, a fully bilingual interface, and advertising that can be served to specific sections, topics, or geographies.

Key modules/theme/distribution used: ServicesSimpleAdsTaxonomy menuViewsRadioactivityOrganizations involved: Eastern Standard
Categories: Drupal

Red Crackle: Object Oriented PHP

Planet Drupal - 18 August 2015 - 4:23am
I am sure that by now you must have heard that Drupal 8 is using Symfony components and is based on object-oriented programming in PHP. If you are a Drupal 7 developer, then you may not know what is object-oriented programming or fail to understand the benefits it offers. In this series of posts, you will learn the basics of object-oriented PHP programming so that you can start developing for Drupal 8.
Categories: Drupal

The Paranet Papers Review (Dresden Files RPG, book 3)

Gnome Stew - 18 August 2015 - 12:00am

The folks at Evil Hat Productions asked me if I’d like to review their newest Dresden Files RPG book, The Paranet Papers (TPP), and being a big Dresden fan I jumped at the chance. Evil Hat sent me a print copy of the book to review, and 2,000 words later, here we are! Let’s get started.

Pre-review notes

I like folks to have an idea of where I’m coming from before reading my reviews. In this case:

  • Like I said up top, I’m a Dresden Fan, though I’m pretty new to the series. I’m currently on the sixth book, Blood Rites — which, as it happens, means I haven’t encountered the Paranet in the books.
  • I’m also a fan of the Dresden Files RPG. My face-to-face group just wrapped up a Dresden campaign set in Boston, and I loved it. The RPG is a great implementation of the books.
  • This is a “reading review,” not a playtest review. Our campaign ended before I could circulate TPP, so we never got a chance to use it.
  • Apart from the very lightest of spoilers — “There’s a Paranet,” plus the stuff you might be able to read in the pictures below if you squint — this review won’t spoil the novels for readers or the secrets of TPP for players.

Note: Pasty white fingers pictured below not included with copies of The Paranet Papers.

What’s this book about?

In the Dresdenverse, the Paranet is a global organization of good-aligned folks that fights against all sorts of supernatural badness.

With respect to the RPG, TPP isn’t a straight-up sourcebook about the Paranet. Rather, it’s a grab-bag of resources for the game — think Unearthed Arcana for 1st edition AD&D, or 13 True Ways for 13th Age, although TPP is very much its own animal. It retails for $49.99 and runs 364 pages.

Roughly half of the book covers “flashpoints,” locations outside Chicago that have been impacted by Harry’s cases, while the other half covers the Nevernever and provides more stuff about spellcasting, more monsters, and updated as well as new characters based on the Dresden novels published since the two core books for the game came out. Here’s a quick overview of the different sections of TPP:

  • Las Vegas, Russia, the Neverglades, and Las Tierras Rojas: The first four chapters each cover a specific location: the city of Las Vegas, Nevada; the city of Novgorod, Russia; the city of Okeeokalee Bay, Florida; and South America, Central America, and Mexico.
  • The Ways Between: All sorts of stuff about the Nevernever.
  • Spellcasting: This chapter elaborates on the magic rules, delving into stuff the previous books didn’t cover as well as providing new goodies for spellcasters.
  • Goes Bump: Monsters! This chapter is full of critters from all the novels between Your Story/Our World and TPP.
  • Who’s Who: Updates to existing characters, plus loads of new ones.

Finally, it’s a supplement. It might be interesting to Dresden fans as a standalone book full of stuff about the Dresdenverse, but gamers will need Your Story and Our World to use TPP.

So, how is The Paranet Papers?

For starters, it’s gorgeous. The first two Dresden Files RPG books set a high bar in this department, and TPP lives up to that standard. Like its predecessors, it’s written as an in-world artifact, which by all rights should be incredibly annoying but isn’t — it’s brilliantly done, just like the first two books.

It’s full-color, and uses that color well. Most pages have artwork on them, and the book is full of notes, highlighting, conversations between characters on sticky notes, and the like. It looks like part of the Dresdenverse, which is great, but it’s also highly functional as a gaming book. The page background behind the text is minimal or nonexistent, and doesn’t impede reading in any way, and it’s well-organized throughout. There’s a useful table of contents, as well as an index.

It’s well-written and well-edited. TPP is a smooth, easy read — almost conversational — and the writing is excellent. Ditto the editing and proofreading. A lot of work clearly went into making TPP live up to its license, and it shows.

It’s a big book. At 364 pages, TPP is an appropriately meaty companion to the first two DFRPG books. I’m generally not a fan of big gaming books these days, but for a toolkit like TPP a high page count is a plus. You don’t need to read it cover to cover to make good use of it; you can skim it, slow down for the bits you need, and come back to it at any time.

The first half. Roughly the first half of the book covers real-world locations. These chapters are broadly similar in approach (though not identical, which I’ll get into further along), so let’s delve into the Vegas chapter as an example of what they’re like.

I’m a big fan of gameable content over fiction in gaming books — I want stuff I can use, right away, without wading through other stuff to get to it — and TPP delivers in this regard. These chapters are brilliant in their utility.

The Vegas chapter opens with a two-page intro to the city. This is followed by a two-page bird’s-eye view, a two-page street-level view of mortals and supernaturals in Vegas, two pages summarizing its recent history (from the novels), and finally a four-page section on the major players. In 12 pages, I’ve got a great picture of Vegas in the Dresdenverse, enough context to get me past not having read this far in the series, an idea of what makes the place interesting, and a good sense for whether it’ll have an entertaining place in my game.

The balance of the chapter addresses Vegas themes, major conflicts in the city, detailed faction write-ups (including statted-out characters, both mortal and supernatural), and closes with a look at some key locations. In other words, pretty much what you’d get if you used the fabulous city creation rules in DFRPG to create the Las Vegas of the novels, which means that it fits perfectly into how DFRPG handles places; that in turn makes this chapter insanely easy to use.

Want to run a game set in Vegas? Your work is done. Want to visit, whether for one session or five? There’s more useful, entertaining meat here than you could burn through in a single campaign — and it fits into less than 50 pages! This is a master class in gameable setting design.

Broadly similar, but not identical. The chapter on Novgorod is about that city in 1918, during the Russian Revolution. The intro explains that the situation then is pretty similar to the situation now, in the present-day Dresdenverse. The chapter is full of excerpts from journals and letters from 1918, and it presents information a bit differently than the Vegas chapter — though, in the end, it conveys pretty much the same kinds of things.

Connecting 1918 Russia to contemporary Russia is one way to make use of this “outdated” information. If your group has an investigative bent, digging into the history of Novgorod in-game would be a great device for learning about present-day Novgorod, or other factions within Russia. That’s a bit of a long walk for my preferred play style, but there’s nothing wrong with this approach; it’s just different.

The Neverglades. This chapter follows the “Vegas model” to a T, with the same results. Okeeokalee Bay comes to life, with all of its factions and major players and themes and troubles, and it would make a great place to visit — or, like Vegas, to set your whole campaign.

South America. The chapter covering Mexico, Central America, and South America also follows the excellent Vegas template, just writ large in order to encompass a much larger area. Which is neat in and of itself, because it’s a good example of how the DFRPG city creation system can be “blown out” to frame up an entire region. Like the preceding three chapters, there’s a ton of useful content here as well.

But I don’t care about Place X! This is why TPP’s grab-bag approach is so great: You don’t have to care about these places. If you do, awesome; use them to the fullest extent. But even if you don’t, the first four chapters are jam-packed with factions, NPCs, and places you can lift as-is and drop into your corner of the Dresdenverse, or re-skin to apply some local flavor.

As a GM, I rarely bother to build characters or creatures mechanically from the ground up. I’d rather spend my time developing them as characters and only address stats when they’re needed — and then, generally, I use a template or other character as my baseline. TPP is a fantastic toolkit to support that style of GMing. It vastly expands your pool of pre-generated characters, and that’s before even getting to the chapter on characters.

The Ways Between. The chapter on the Nevernever is a bit different. While the Nevernever could be treated as one location, it’d be tough to do it justice like that. So TPP doesn’t. Instead, this chapter looks at how the Nevernever works, how to traverse it, and how to convey what it’s like in the game, and then provides a ton of what it calls episodes.

Each episode centers around a place that intersects with the Nevernever, its inhabitants, their struggles, and what’s going on there — always interesting, and always gameable. It’s not just fluff you can’t use: You could pick up any one of these short write-ups and spin a session or two out of it, sandbox-style, with zero issues.

Spell-slingin’. In my group’s Dresden game, I deliberately didn’t play a spellcaster because of the mechanical complexity level. Folks who’ve played DFRPG might be thinking, “Really? It’s not complex at all!” But it looked complex to me, so I avoided it. I read the bare minimum necessary to not embarrass myself when it was my turn to GM (this was a round-robin campaign), and that’s it. So to be perfectly honest, I don’t know much about what this chapter expands. I mean, I can read the section titles and have a rough idea, but this is a big DFRPG blind spot for me.

What I do know is that if my group were still playing this campaign, the player who was playing a spellcaster would have read this chapter in one night, gleefully, and immediately put it into practice. And the player who wasn’t intimidated by DFRPG magic would likely have worked a couple of elements from this chapter — sponsors and cheer-saving thaumaturgy, maybe — into the game when it was his turn to GM.

Sweet, sweet monsters. I love monster books, creature chapters within larger books, weird blog posts about monsters — all things monster. I like how DFRPG presents supernatural critters and characters, and TPP is no exception. The stat block is intuitive, the write-ups are useful, the artwork is evocative, and little notes from Dresdenverse icons help bring them to life. It’s a solid chapter.

…and characters. My group deliberately avoided Chicago and the denizens of the Dresdenverse who had featured in the novels, but not all groups will take that approach. For me, this chapter would be a toolbox full of re-skinnable NPCs, packed with flavor and saving me the time of making NPCs myself. But for you, who perhaps loves to intertwine your group’s stories with the novels, the as-is utility of this chapter will really shine.

If a character has changed over the course of the books separating TPP from the original DFRPG release, they’ve been updated here. If someone important was introduced, they’re in here as well.

Should you buy The Paranet Papers?


The Paranet Papers is a fantastic supplement. Its toolkit approach makes it useful no matter where your DFRPG campaign is set, as well as supporting a variety of play styles and preferences — from re-skinning elements and moving them into your game, to “side quests” to colorful, far-off locales, to setting a campaign in one of TPP’s iconic locations.

Some grab-bag or toolkit supplements feel like cash-ins intended to profit from stuff that should have been left on the cutting room floor (and which was rightly cut from the core book or books). Not this one. While you may not find a use for 100% of its contents, there isn’t an ounce of fat on TPP’s bones. It’s a big, colorful book that takes full advantage of being big and colorful without ever straying into “bloated” territory.

TPP reads like it was written by huge Dresden Files fans who not only know the series, but know how to turn it into a brilliant game — and in this case, into a brilliant supplement. It’s hard to produce a book like this one without a few sour notes, or without presenting things that feel like they’re just there to fill pages, but there’s none of that in TPP. It’s a lean, evocative, useful, and above all gameable supplement — best-in-class in every way.


If you’ve got questions about the book or this review, I’ll be happy to answer them in the comments.

Categories: Game Theory & Design

The RPGnet Newsletter: RPGnet Newsletter #17

RPGNet - 18 August 2015 - 12:00am
GM advice and other news & views.
Categories: Game Theory & Design

The Keep Near the Gaming Hut: Introduction

RPGNet - 18 August 2015 - 12:00am
An intro to our new Pelgrane-focused column.
Categories: Game Theory & Design
Syndicate content

about seo