Nodes and entities

Being a CMS, in Drupal, most of your website probably will be structured around content. Whether it's managing it or displaying it in different layouts, themes, and views, content will be driving your website. Even more, content may be associated with the business logic about your website, which then defines a behavior based on content. Some examples for that may be, to send an email notification to users when a new content has been created, or to assign a rating system to content, such as five star rating or kudos, so that users can like it and in turn, this content receives higher visibility among your users. The possibilities are endless.

You have probably understood by now that content is very much a generic term for anything. It can be an article or blog if you're planning to run an online news-magazine website, or it may be a message post limited to 140 characters (if you didn't recognize, that's Twitter basically). Content can even be the posting of images by users, aligned in vertical columns with an infinite scroll, or the posting of videos. Throw into that the ability to rate, tag, create a personalized feed, maybe a customized bookmark/playlist too, then some of that special sauce we call social networking, by adding friendships and following the activity of other users in the website, and you've got yourself what we know today as Pinterest and YouTube.

Nodes

It's been a long time now that the term node has been at the very core of Drupal, so you have probably heard of it by now. As we've seen, content is very abstract and can take on many forms and shapes. Due to that reason, you'll often hear or read that "In Drupal, everything is a node" and that's most often the case. Whether your content is images, blogs, videos, forums, or polls, they all share very common characteristics and can be abstracted as a node.

These attributes of content such as title, body, created and modified time, whether the content may be commented on, and so on, are all pretty common properties across the different content types. And for this reason Drupal considers all these to be of the same nature, and so, to provide more flexibility without limiting the content types, it's simply called a node.

Note

When examining specific content types in detail, it becomes clear that having a specific set of attributes such as Title and Body, is not enough. A Poll type content would require additional fields, such as text fields, which will represent possible answers. Download type content may require a file attachment field, in which a user can upload, and then another user can download. These additional fields have been developed as part of contributed modules, by the community, which answer this exact requirement of adding more fields and field types to nodes than what Drupal provides out of the box. You may have come to known these modules as Content Construction Kit (CCK) and Chaos Tools and many other modules which build upon this field's framework and further enrich content types. We will go into more details soon enough on this.

Out of the box, Drupal 7 ships with two basic content types: Article and Basic page.

The Article content type is used for blogs or news item, and as such it features properties such as, a comments area enabled, fields such as images and tags, displaying of the latest added content of this type in the front page. A Basic Page on the other hand doesn't have the comments area display, nor any special fields. Its display doesn't contain any information about the author who created the page and when it was created, but rather just prints the body of the page. It's easier to see the distinction between the two content types, and designing your content type's fields and settings is a very important part of building a website with Drupal.

Entities

Nodes are Drupal's term for any-kind-of-content, but Drupal 7 has taken a further step in abstraction and possibly coined a new phrase "everything is an entity", when introducing the entity model.

A thought may have triggered in your head when reading about nodes that while many content types are similar, they are definitely not the same. Some may not even require what Drupal would consider as a core field such as a title. This would then result in redundant data and a schema structure that is not very fit for what you had in mind for your content type to be.

To take this further, much inspired from other Object Oriented Design (OOD) concepts, Drupal also figured that it's basic schema for users and other objects such as taxonomy, comments, and so on, may be lacking too, meaning that it may be too strict, and site builders will eventually want to customize and extend those. With this thinking in mind, it has been made clear that nodes are not the only objects to take the even more generalized form of entities. This will rather extend to users and more objects that Drupal has been making extensive use of, for a while now, as its core building block (taxonomy, users, and comments, to name a few).

Note

You may ask yourself what's new about defining entities because if you required your own unique data structure you could easily design the schema for it in your module's install file and decide what fields you need to create the database table that fits your needs. If you choose to go this road then those table fields are almost entirely disconnected from Drupal's built-in hooks system, and you are left on your own to tie them into Drupal's handlers. With Drupal's entity model you get this Drupal-awareness connectivity for free and many aspects of Drupal can then interact with your entities.

Entities allow us to create a common infrastructure across different objects, such as nodes and users. Then, if nodes are able to define a content type such as an article and assign fields to it, this goes the same for the users. This generalization of objects to a common ground provides software developers better maintenance and interoperability, and in result we, site builders, gain more features and powerful tools to customize and create the website as we see fit.

Bundle is the name given for the implementation of an entity type. If we implemented a node entity (meaning, we create a content type) and called it article, assigned some fields to it too, we inherently created a bundle called article. Bundles allow for the grouping of different entity types with their respective fields.

Nodes are not gone nor have they been replaced. For most content types, where it makes sense to treat something as a content rather than an entity, should not be abused and one can definitely build on the node's generic structure design with the envisioned content type and its related fields.

Creating entities is a task which requires defining many properties of it, whether it's fieldable, its basic fields structure, and so on. Sometimes, one would need to create an entity type which Drupal doesn't provide out of the box, like nodes or users, this process is much regarded as "further customization achievable by program code", hence requiring more in-depth knowledge and technical skills, which we will not pursue in the scope of this book.

Creating a content type

So far we've introduced the concept behind the entity model, and in specific, the nodes and their content types. Let's proceed by creating a new content type that we'll name Memo for keeping personal notes.

Tip

What's so special about creating digital "stick it" notes? Even the simplest ideas can grow into great applications that can affect our everyday life. Evernote (http://www.evernote.com), which dubbed itself as "remember everything from saving thoughts and ideas, to preserving experiences" is the company behind the popular mobile and web app, for creating and sharing (rich media) notes with your peers, and is valued at an amazing $1B price tag.

We assume a fresh install of Drupal 7 (7.19 is the version available at the time of writing this book) so the first page should probably look as follows:

Note

When logged in as an administrator user you will see the administration navigation bar at the top in black color. We will often refer to this as the administrative navigation bar, mostly throughout this chapter, since we are just starting out. When otherwise navigation is being described, such as Structure | Content types, it is always referring to the menu items from that administrative navigation bar at the top. For your convenience, we will also often note in parenthesis the direct URL to access the relevant page.

To create the content type we can either make use of the shortcuts present in the page content area (this is the center of the page) or the Navigation block (in the left side of the page). If you are unable to locate neither of these we can use the administrative navigation bar at the top and navigate to Structure | Content types | +Add content type (/admin/structure/types/add).

In the new content type page, we'll provide the content type name, Memo, and an optional description.

Tip

It's a better naming convention to use the singular word for a content type. As you can see, Drupal has already modified our title for its internal use, noted by the Machine name field.

More settings for this content type are available but we'll only customize the Title field name and call it Memo, leave the rest of the default options as they are, which basically are the same as Drupal's built-in Article content type which we described earlier.

Last, we will click on Save content type which saves the settings and submits the form.

At this point, we have our newly created content type Memo and we can test how it works. We want to add content to the newly created Memo content type, so we will either use the shortcut for Add content, or if they are not present we can use the top administrative bar and navigate to Content | Add content (/node/add).

In addition to Drupal's default content types we see our new Memo content type.

After choosing Memo, we will see the Add content form for creating our specific content type, where we will provide the memo title and a more descriptive body message.

Once finished with the memo we'll hit the Save button to submit and create our new memo.

Our memo has been submitted and for logged-in users, it looks as follows:

When looking at the preceding submitted memo, you may realize that there is room for improvements, such as, adding some images would have been more appealing to the eye. Also, it may be nice to have dedicated links field so that we can display them the way that we choose to, like a resources listing of them, at the bottom of the memo.

This brings us to our next topic in this chapter: Fields.