What we’re excited about in digital storytelling and engagement, user experience and design, development and open source.
Posts in Drupal 8
Drupal 8 made huge improvements to the theme developer experience. Wrapping your head around all the changes can be intimidating but it doesn’t have to be.
I have a confession to make: I don't like clicking through the Drupal admin. Over the course of a project, beit one with content migrations, configuration in code, or just general site building, the information I need the most is field and taxonomy configuration. Typically, this means bouncing betweens tabs for content types and taxonomies which consumes time and precious clicks. Add in custom entities in our new Drupal 8 projects and there's even more time spent in the admin.
Drupal 8 lays the foundation for building robust and flexible RESTful APIs quickly and efficiently. Combine this with Drupal’s best-in-class fieldable entity model and it becomes incredibly easy to construct systems that solve many different problems well.
Out of the box, Drupal 8 comes with core modules for all of the standard RESTful HTTP methods, GET, POST, PATCH, and DELETE. These endpoints are entity specific. Collection endpoints - endpoints that deal with entities in aggregate - are another story. The solution offered is the Views module.
This is an update to a previous post I wrote on adding classes to blocks in Drupal 7
You've been doing Drupal permissions wrong for years (probably). And the fix is pretty simple. The Problem: Drupal permissions are an administrator's nightmare. The settings page is a daunting wall of nondescript checkboxes with overlapping meaning and lots of duplication. This makes bugs hard to find and permissions hard to manage. Worst of all, this user experience poses a security risk. It's just too tempting to scroll and check box after box without thinking too deeply about the consequences.
Last week we launched Connect4Learning, the first component of a multi-staged rollout for a groundbreaking interdisciplinary prekindergarten curriculum by Kaplan Early Learning Company.
I recently needed to temporarily store information associated with a user's session in Drupal 8. In past versions of Drupal, I might have just thrown the data in
$_SESSION. In Drupal 8 there's a service for that; actually, two services: use
user.shared_tempstorefor temporarily storing user-specific and non-user-specific data, respectively.
Recently, I needed to add some dynamic content to a Views footer. Specifically, I needed to change a link in the Views footer based on the current path, which isn’t an option from the Views UI. I found some good documentation showing how this can be done in older versions of Drupal (https://www.drupal.org/node/749452), but nothing for Drupal 8. I figured the approach must be similar in Drupal 8 so I started searching and reverse engineering.
In case you've had trouble tracking it down (I did), the approach to caching custom blocks is different in Drupal 8 than in Drupal 7. In Drupal 8 all renderable arrays are cacheable – including, of course, those returned by custom blocks.