One of the things I love about Drupal is the entity reference field. In Drupal 8, entity reference fields are even better because they’re now included in Drupal Core. This makes building composed and well-structured data much easier. However, I think as Drupal developers and architects, we’re fundamentally misusing them in far too many cases. Over and over, we use entity references to denote a relationship between two entities instead of a simple reference or inclusion.
Posts in Drupal 8
Why would you need to render the content from Drupal’s block layout via a node template file? Normally, that is the territory of page templates. The use-case for me was a page where node-specific fields were mixed in with blocks to the extent that rendering region content in a page template file wasn't going to work.
I needed to be able to render my region content amidst field values in my node template files. Drupal doesn't let you do that out-of-the-box.
What we’re excited about in digital storytelling and engagement, user experience and design, development and open source.
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.