Drupal 7 Media - Third Edition

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.

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.

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).

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.

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.

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:

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.

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.

Let's add some fields to our memo content type.

Using the top administrative bar, navigate to Structure | Content types (/admin/structure/types).

Out of the possible operations we are interested in, is the manage fields option, so we'll click on that for the Memo content type.

In this page we are now made aware, more than ever, of the fieldability of Drupal's node's content types. The Memo content type that we created has a title and body field (which you can tell by the MACHINE NAME column) and it doesn't come by any surprise as we've already set those when creating it. Yet, notice that the title field is an inherent field that is provided by the node entity, and we can't remove it, unlike the body field which we can customize to our liking, or completely remove it.

Other than the fields already present, we can add fields either by defining a new field type and selecting its widget, or choosing a field type that was already created before, in this case it's Drupal's field_image and field_tags.

We'll continue with adding two more fields for the Memo content type: Images and Tags, and we can utilize the already existing options and set their label, starting with the image field:

After clicking on the Save button, we are presented with the field_image type's settings which we can customize to our needs, some of which are:

Once you're satisfied with the settings click on Save settings button and we'll continue with adding the second Tags field:

The curious of us will notice that there are several widgets to use, for this field, which define the rendered view for each field when editing content: Autocomplete term widget (tagging), Check boxes / radio buttons, and a Select list. This is where we need to put some thinking, tags (in Drupal this concept is referred to as taxonomy) have characteristics of being free form, and as such may grow to very big sets, which does not scale well with checkbox/radio HTML elements; and it's a very poor User Experience (UX) practice, if utilizing large items for a select box, so the Autocomplete term widget (tagging) option seems to be the most reasonable one, for a widget.

After saving, we're being presented with the FIELD SETTINGS page and we can notice how the settings for this field are very different from the previous image field. One particular setting that is set by default is the Number of values option which is set to Unlimited and it makes some sense with the use of tags as well as with our selection of the autocomplete widget.

Let's add another field to store links that we may want to add in our memos. Since links are really plain text, we can use the Text field type and its default (and only) widget is Text field too.

The default setting of 255 characters length limit is probably enough for most cases, including our purpose of this field for links, so we can leave it like that, and click on Save field settings. After which, we are then presented with the new text field's settings and we should probably change the Number of values option to Unlimited for this field too and click on Save settings.

Observing our new structure for the Memo content type we can see the newly added fields at the bottom of the list.

This listing also hints on the ordering of the fields, so if we wanted to make some changes there, such as bringing the Tags field beneath the Memo field, we can simply drag and drop this item by using the grey color arrow icon to the left of the label in the LABEL column. Once finished with reordering, we need to click on the Save button.

Adding a memo now will result in the following:

Viewing the form with our newly added fields looks as follows:

While the above fields' ordering dealt with managing the display of the form fields when adding or editing memos, we might also be interested in changing the overall appearance of an actual posted memo.

To do this we navigate to the Memo content type's configuration page again, which is at Structure | Content types | Memo | manage display (/admin/structure/types/manage/memo/display), and we're presented with a new configuration page:

Displaying of content types may be different, depending on which view mode is being utilized. These view modes are for example, Full content, which is equivalent to the Default display mode for most purposes, and represents the mode for viewing the full page of the content type (this is for example, when in content listing, like in blogs, when you click on the "read more" link and view the full article on a dedicated page). Another view mode can be Teaser, which is often used when doing the content listing, similar to a blog, where you don't want to put too much content but rather a sort of summary for the content.

On the upper-right corner of the MANAGE DISPLAY configuration tab, we can see sub tabs for each view mode that we want to customize. By default, there's the Default and the Teaser mode. If we want to customize more view modes we can simply expand the CUSTOM DISPLAY SETTINGS link, choose any of the options there, and they will be added as subtabs.

Sticking with the Default view mode and taking a closer look at the fields table we can see the fields being used in this view (notice how all fields are being used, and none of them is hidden from the layout) and the Label and Format settings. The Label column configures where the field's label shows up, if at all, and the Format settings specify what kind of formatting rule to apply on the content that is being displayed for this field. If we examine the Format options for the Body field, then some options such as Trimmed or Summary or trimmed, makes sense for short content listings, like in the Teaser view mode that we mentioned.

There is definitely some room for improvements on the Default view mode for our memo, so here are some ideas for styling the view better:

We can remove the Image label next to the image as that's pretty self-explanatory, and put the Tags field at the top with the LABEL column displayed as Inline, to eat up less space.

Once you're done setting up the field's display settings click on the Save button, and watch the new layout of your Memo content.

To practice on this, let's revive Drupal's front page node's listing. It uses the Teaser display mode, so we'll go ahead and update the fields listing. In the Image field, add a <hidden> label by drag-and-drop, and set the Image style dropdown to thumbnail by clicking on the gear icon, and setting the select box accordingly, then click on Update. And for Tags, drag and drop this field upwards as well, and set its Label to Inline. When done click on Save (feel free to further customize the teaser display mode to your liking), and view the home page to review your changes.