Working with Drupal entities

Sometimes it can be handy to have extra pages for a node (or any entity). For example:

• To show different sets of information on separate pages for a single product, page, or thing.
• So you can set different access requirements on each page for a node.
• You want to block access to the ordinary route (e.g. node/123 and its aliased equivalent) for some reason, but you still want some other page to represent that node.

I've found a few people with that need on Drupal slack before, so I thought I'd write a guide because it's surprisingly...

Many of us at ComputerMinds have always taken pride on doing Drupally things the right way whenever possible, and then helping the community do so too. One of these things is displaying values from fields on content entities. We wrote before about how to do this in Drupal 7 and Drupal 8. It's now the turn of Drupal 9! Thankfully, this updated version is basically the same as the last one, as D9 is very similar to D8 on the surface, but with old cruft ripped out to allow it to continue improving. So the short answer to "How...

Once upon a time, we wrote an article about how to render fields on their own in Drupal 7, which was really handy because Drupal 7 wasn't always intuitive. It's common to want to display a field outside of the context of its main entity page, like showing author information in a sidebar block or in a panel, but you had to just know which functions to use. Drupal 8 came along since then using 'grown up' things like objects and methods, which actually makes the job a little easier. So now in Drupal 9 we have this:

The...

In Drupal 7, we had menu_get_object() to get the object in code for whichever node, term, or whatever entity makes up the current page. But in Drupal 8, that has been replaced, and entities can usually be operated on in a generic way. If you know the type of entity you want, it's pretty simple. But I keep running into different suggestions of how to get the entity object when you don't know its type. Given that D8 allows us to deal with entities in a unified way, I thought there must be a good way! The code of core itself is usually the best place to look for examples of how to do common things.

In Drupal 8, there are many ways to interact with configuration from PHP. Most will allow you to write the config values, but some are read-only. Some will include 'overrides' from settings.php, or translations. There are many layers of abstraction, that each have different purposes, so it can be easy to run into subtle unintended problems (or more obvious errors!) if you pick a method that doesn't quite suit what you actually need to do. Here I'm going to outline some of them and when you might pick each one.

Content (node-level) translation or entity (field-level) translation?

It seems an obvious question to ask, but what are you translating?

The tools exist to translate just about anything in Drupal 7*, but in many different ways, so you need to know exactly what you're translating. Language is 'a first-class citizen', in the sense that any piece of text is inherently written by someone on some language, which Drupal 7 is built to recognise. Sometimes you want to translate each & every individual piece of text (e.g. at the sentence or paragraph level). Other times you want to translate a whole page or section that is made up of multiple pieces of text.

Previously on this website I have written about rendering blocks programmatically and adding things to content to be managed alongside fields. It's time to combine the two! On many projects, we find ourselves needing to render a block consistently across all content of a certain type. For example:

• Are you trying to place advertising blocks or fixed javascript code between the fields in the content of a page, not just shoved into regions around the content?
• Do you want to show a standard piece of content (we use the bean module for enhanced content in blocks) to be placed...

If you have a Drupal 7 site, then you should be using the [Entity cache][ec] module, here's why:

Lots and lots of things in Drupal are 'entities', such as the content, the users, the taxonomy terms and if you're using contrib modules like [Field collection][fc] or [ECK][eck], then those are entities too.

Most of the time you have some fields on those entities, then every time Drupal needs to load one up, it'll also have to read the data for each field from these tables. Once you start having lots of entities, and potentially field collections on those entities, you...

UPDATE: The Extra Field and Extra Field Settings Provider modules facilitate doing this sort of thing in Drupal 8. Read on for older Drupal sites, and for the concepts behind this.

We often want to add things to the content of a node or any other entity in Drupal 7 using hook_node_view(), hook_node_view_alter() or a similar hook in a custom module. This could be anything from a custom social media link, a field rendered in a custom way, additional author information or virtually anything else.

Here's the code used to add that Facebook like button:

/**
 * Implements...

Drupal 7 brought us Entities, and with them the powerful Field API for 'storing, loading, editing, and rendering field data.' attached to them. If you're managing everything through 'manage fields' and 'manage display' tabs of your content type, then every part of that process is rather wonderfully taken care of for you.

We often, however, come across the need to render a field outside the context of it's entity. A common example might include rendering a node's author in a sidebar block. Sure, modules like Panels and CCK Blocks will do this for you, but doing it manually is actually not that hard.