As a programmer, I spend almost all my time hanging out with code. This code may be my own, other co-workers’, or code from an open source project. And I may be contributing this code at different points in that project's lifecycle: starting out, initial development, maintenance, debugging, adding new features, etc. Given the amount of time I have been working on various projects as a programmer, I spend more time – and place more value on – considerations around the ability for anyone to step into this code and maintain it, debug it, or refactor it.
Posts in Drupal
Controllers in Drupal 8 are the equivalent of hook_menu in Drupal 7. A controller lets you define a URL and what content or data should appear at that URL. If you’re like me, limiting access to my controllers is sometimes an afterthought. Limiting access is important because it defines who can and can’t see a page.
Recently, I was creating a form that provided a list of options as checkboxes and needed to include helper text for each individual checkbox. While the Form API in Drupal 7 has a
#descriptionattribute, for checkboxes and radios it applies that as text for the entire group. After a lot of looking, there didn't seem to be a way that allowed for passing descriptions into each item in the
#optionsarray that is expected.
While recently working on Stanford Parking and Transportation Services new Drupal 8 site, I had the opportunity use Twig’s extends syntax. Leveraging this simple, yet powerful feature makes Drupal 8 themes easier to maintain and reveals some helpful tools to make our templates more related and powerful.
Creating comments programmatically in Drupal 8 is incredibly easy once you know just which fields are required and why. In Drupal 8, comments are now full-featured, fieldable entities — just like nodes or taxonomy terms. In addition to unifying the way we create content, comments, and other entities, this has made Drupal’s commenting system much more robust and flexible.
Sometimes you don’t want to show Drupal’s node creation message to your users. Or maybe you’d just like to customize a default message. You might be creating nodes for backend administrative tasks, or you might want your node creation messages to have a little more pizazz than the standard A new node of node type has been created.
About a year ago we helped Stanford University launch a handful of sites built on a common platform sharing a base theme and a collection of easily customizable static content. As those sites received more and more code updates, maintaining all of them became time consuming.
Drupal’s Feeds module is a great tool for importing content into a site. The Feeds UI is relatively simple, and it’s fairly full featured out of the box. One such feature is the ability to assign a unique ID to each item. This allows sequential imports to determine if an item of content has already been imported and how the site should handle that situation. The options here include:
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.
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.