Drupal uses the concept of entities to represent different types of data, so things like content are stored as node entities and users as user entities. By using this approach developers are given complete control over te data they're working with. Entities can have fields added to them to build up the exact structure you want for your data. It is even possible to create your own entity types if you need something that isn't offered out of the box. Read some of our blog posts about entities below...
Read some of our articles about 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...
Upgrading to Drupal 9
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...
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.
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...
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...
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. [Field API]: http://api.drupal.org/api/drupal/modules--field--field.module/group/field/7 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.