Watch videos with subtitles in your language, upload your videos, create your own subtitles! Click here to learn more on "how to Dotsub"

What are Drupal Entities?

0 (0 Likes / 0 Dislikes)
[What are Drupal Entities? Working with Entities in Drupal 7] One of the things that's challenging about learning the entity API is all of the terminology you need to understand first. In this lesson, we're going to go through a bunch of different terms —entity type, bundle, field, property, and even entity itself— and try to understand what each of those things mean. We're also going to take a little bit of a look at why the entity API exists, and in order to do that, we have to kind of look at a little of Drupal's history to understand where it came from and why it's important. So let's go ahead and get started understanding all of the base components that we need in order to build things with entity API. What you're seeing on the screen here is a list of terms that we think are important to understand in order to fully grok the entity system in Drupal, though it's a little bit hard to explain these terms, because we have kind of a chicken-and-egg problem. It's hard to understand what an entity type is if you don't already understand what an entity is, and vice-versa. So we're going to go through and explain each of these terms, and if you stick with us, by the end, you should have a better understanding of what each 1 of these means. We'll try to go through them in order, but I'm sure there will be a little hopping around as well. An entity type can be thought of as a way of grouping like entities together under a common umbrella and allowing the system to understand that while all entities may share some common properties, they are not all equal. Nodes, users, and files are all types of entities in Drupal, and all 3 of these have things like a unique ID. But only nodes have titles, and only users have user names and passwords. They share some properties, but in some cases, they differ as well. So the entity API provides us with ways to define new entity types— like node or user, or any that we can think of— or augment the existing ones by using a common set of functions and classes, which we'll be exploring throughout the rest of this series. The next term we need to understand is bundles. Bundles are an implementation of an entity type to which fields can be attached. They're kind of like subtypes. The most common and familiar use is content types, or also known as node types, like article, page, and blog post, or whatever other custom content type you can come up with via the UI. Each of these is a bundle of the node entity type. Note that some entity types only have a single bundle. Users, for example, don't have multiple different types of user. You just have the user entity type and a single user bundle. And some entity types don't have bundles at all. Files, for example, are just an entity type without bundles. The thing to remember here is that bundles are sub-types of an entity, and without bundles, you cannot attach fields to an entity of that type. Bundles, in fact, are what field instances are attached to, not the entity type itself. So bundles are collections of fields applied to an entity. And as you flesh it out a little more, it starts to look something like this. We've got our entity type of node, which has, in this case, 3 different bundles—basic page, article, and then our custom bundle type. When you go and view an article in Drupal, or you load an article from the database and you're interacting with it in your module's code, you're interacting with either properties or fields of that article. That's the actual data that's stored for that piece of content or that piece of data. Properties are pieces of information that are the same for all entities of a given entity type, regardless of what bundle. An example of that is something like the title. For nodes, which is an entity type, every node type— basic page, article, and any that we create—all have a title property. This is the same for all nodes, no matter what the bundle. Another example of that is something like the unique ID that you can use in order to identify a node. Every single entity in Drupal has a unique ID, and if they're revisionable entities, they also have a version ID. So these are things that are common across all entities, and in most cases, across all entities of a given type. We call those properties. And then there's fields. Fields are bits of information that are configurable per bundle. We think of fields as sort of data primitives. Anytime I add a field to a content type via the UI, I'm attaching that field to a bundle, and fields don't have to be the same for all entity types or for all bundles. This is the part that's configurable, but remember, if you don't have bundles, you've got nothing to attach fields to. Like files, for example, which are an entity type with no bundles, so I can't attach fields to a file entity. Put it all together and we've got this concept of an entity. An entity is sort of like a discreet piece of data of a specified entity type with a set of common properties and some type specific properties—if you've got bundles implemented for example—and if you do have bundles, it may contain fields as well. Another way to think of it is an entity is 1 single node. It's 1 single blog post. When I fill out the form and create a blog post and hit save, I've just created 1 new entity, and that entity consists of the data that was entered into each of the property fields and each of the UI fields that were attached to that blog post bundle. In addition to that, you could also think of an entity as a common interface that other modules can implement in order to gain access to the data without having to rewrite the code for every possible type of entity. For example, an entity implements a save method. That means that if I have an entity, even if I don't know what type of entity it is, I can call the save method, and that entity will take care of whatever it needs to do in order to save that data to the database. I can call save onto user, save on a file, save on a node—it doesn't matter. That entity is capable of saving it's information, it's properties, and it's fields if it has them, into the database. It's also capable of retrieving them and so forth. This makes it really easy to create code in Drupal that's reusable across lots of different entity types. Fields are a really good example of this scenario. You can create a module that implements a new field, and that field can be attached to any bundle throughout all of Drupal. This creates a really powerful system, and it's kind of why the entity system exists in the first place. I think that it can also help to have a little bit of history about how this whole system came into being. If you've been doing Drupal development for a while, or even just working with Drupal sites, you're probably familiar with a lot of these concepts, though may know them as something different. In Drupal 6, we had this concept of nodes and node types, and we had the ability for someone to create a new node type like we do today, with bundles on entity types. At that time however, nodes was the only system that allowed that kind of abstraction. And then there was CCK, or the content construction kit, which allowed you to add fields to all these different node types, and this was viewed as a really powerful solution. It was a really powerful solution, and you could do all kinds of things by combining the ability to create your own new node types and add any field that you downloaded and installed to those node types. So it ended up in a scenario where all of a sudden, everyone was trying to turn everything into a node so that they'd get the power of the full flexibility of a tool like the content construction kit. All these modules were trying to do things, like make comments into nodes and make users into nodes, store them in the database as nodes so that we get the flexibility of CCK. And it kind of worked, but at the same time, you had all of the additional baggage of the node system, even if you didn't need it. Users, for example, don't really need to have commenting applied to them. But if you're turning your users into nodes, all of sudden you have the ability to leave comments on your users. So for Drupal 7, that concept was abstracted even further. Rather than have just nodes which you can apply fields to, Drupal now allows you to have entity types, and fields can be attached to bundles on any entity type, and a user can be a type of entity, and a node can be a type of entity, and comments and so forth. So now we have the power of the field system and we can apply it to all of these other content types or data points, like users in Drupal, without having to try to turn those things into nodes or force them to be something that they're really not. What I'd like to do next is take a look at some of these things in a Drupal website— navigate though and look at a node and a user, and talk about the properties and fields that make those things up. So let's go ahead and do that. What I've got here is a simple Drupal 7 site with a couple of additional modules installed, and I've gone through and generated a bunch of content using the Devel module so we have something to look at. First thing I want to do is take a look at this node here. I view the node with the Devel module enabled; I get this tab up at the top here which allows me to basically view a more detailed output of the node itself. Looking at this node object, which is of type standard class, I see a whole set of properties and fields. This, what we're looking at right now, is an entity. It's an entity of the type node, it's an entity with the bundle of page since this is just a simple page node, and it has a set of properties, like for example, the user ID of the author that created this node, and some fields, like for example, the body of the node. I can close that, and let's take a look at another node, like this 1. Same thing. I've got an object that is an entity. It's an entity of the type node. You can even see that right here. It's a node with a bundle article, it has some properties like the UID, which we see again and we saw on the previous node, which was of the bundle type page, and some fields. Still has a body field, but it also has a couple of additional fields that weren't present on the other entity type. I can also look at my user account. Same thing. This object is an entity and the entity type is user, and the bundle in this case is actually just user. So we said there's not configurable bundle types for users. There's just 1 bundle to which you can attach fields. But it's got properties, just like our node entity type—UID, name, etc.— and we could also optionally attach some fields to this entity type if we wanted to. In addition to the entity types that come with Core, there's also some that are provided by additional modules. I've got the BEAN module installed on my site right now. The BEAN in this case is a acronym that stands for block entities aren't nodes. Essentially what it is, is it's a module that allows me to create new blocks using the entity system. And what this has given me is the ability to go to the structure tab, and I've now got this block types option up here. Block types are a bundle. They're attached to the BEAN entity type. When I create a new block type, I'm creating a new bundle. I'll go ahead and do that. Once my block type has been created, I've now got a new bundle named block bundle, to which I could attach fields, and then I can create a new block. I go to content. Up here at the top, I've got a new tab for blocks, and I can add a new block entity. When I create a new block and give it a title, I'm filling in a couple of properties for this block entity and saving it, and now I've created a new entity in my system. This entity's treated as a block though, so I could place it places using the block configuration screen. There's lots of other examples of entities from Drupal contrib as well. The file entity module is neat. It takes the file entities that already exist in Drupal Core and extends them in order to make them fieldable. Essentially what it does is it adds the ability to have configurable bundles to the file entity type, which means you can then attach fields to it. There's also the Recurly module, and this one's interesting in that it doesn't provide a new entity type, but it works with the entity API and the entire entity system in order to do some pretty neat things. What it does is it allows you to create a Recurly subscription and attach it to any entity type in Drupal. And it can do this because all entities in Drupal implement this common interface of save, update, load, delete. There's 1 set of functions that you can call that will work on all of them. So a module like the Recurly module can write its code once and allow some configuration where you choose, "I'd like to have this applied to the user entity type," but the code will just work, no matter what the entity type is. And finally, modules like Drupal Commerce are making heavy use of the entity system in Drupal in order to make their modules even more flexible. In Drupal Commerce, almost everything is an entity type, including things like the shopping cart. An order that's made when somebody checks out products in the system are all entities, which means all of those things are fieldable, so you're adding all kinds of additional flexibility, but you're also limiting the amount of code that people need to write in order to work with your system. I could write code like the Recurly module that implements the common save functionality for all entities, and you could make use of that code on any entity type, including those provided by a module like Commerce or like we're going to do throughout this series when we create out own we create out own entity type, that code would work with those as well. [Drupalize.Me]

Video Details

Duration: 15 minutes and 2 seconds
Country: United States
Language: English
License: All rights reserved
Genre: None
Views: 220
Posted by: drupalizeme on Jul 17, 2013

In this lesson Joe will explain what an entity is and provide a little bit of history about how they came into being. We’ll also learn about some of the differences between custom entities and nodes (which happen to be a type of entity) and when, and why you might want to choose to write your own custom entities instead of using the node system or a more traditional datastore.

Caption and Translate

    Sign In/Register for Dotsub to translate this video.