Which Drupal Entity
Drupal 7 offers several default entity types. Node (content) types, Taxonomies, and Users by default, File and Custom Entities with add-on modules. When you are first confronted by Drupal, these can be confusing. Sure Users seems straight-forward, but Taxonomies and Content Types can turn you in circles if you aren't careful.
What is a Drupal Entity? I think of them as building blocks. Just like with LEGOs when I was a kid, there are different types of entity blocks. They have different characteristics and they serve different purposes. Also like with LEGOs, two people may use completely different approaches and blocks to build extremely similar projects.
You will also see these listed in various places as Content Types. Different terms for the same idea. They are the type of Entity that encompasses what most people think of as pages. If you're transferring a simple static HTML site to Drupal, this would be where most of your content would go. Nodes have some simple benefits:
- They're easy to put in menus
- They are easy to add fields to
- Most of your clients will easily identify the idea behind a "Basic Page" node type.
It gets somewhat more complicated
A default Drupal install gives Page and Article node types. Why would you want more than one type of "page"? An easy example is a Blog like this one, or Press Releases like a company might want. This allows you to have one type of node that functions as the site's basic structure ("Page" in this example). This is the content in the menus, the "About Us" page you link to, etc. This content can have whatever fields you need, be displayed any way you want, and is editable by the people of your choice.
Then you have Articles. Articles can have different fields, be displayed in a different way, and be editable by a different group of people. With a module like Views you can easily display our example Article content type differently. This type of content you may choose not to put in menus. Instead you archive this content type by publication date.
While we're modifying this Article content type, we can choose to add fields like a Term Reference. There are a number of modules that allow this sort of field, but we'll address that another day. For our purpose here, it doesn't matter. We have a field that allows you to choose one or more Taxonomy terms. The same default Drupal installation we previously mentioned comes with two Vocabularies, Categories and Tags. Functionally they are interchangeable. You can also just delete them and make your own.
Taxonomies are made up of a Vocabulary (think of it as a parent item) and Taxonomy Terms. Taxonomies, like nodes, have some inherent benefits.
- You can easily add fields
- Easily use taxonomy terms to group content
- This grouping nature is built into Drupal, but is easy to modify as needed
Like node content, terms are easily styled and organized. While Nodes tend to be organized through menus, Terms can be organized within a tree like structure with Terms or groups of Terms placed under other Terms.
For a long time if Drupal, Taxonomy terms were mostly used for simple groupings of content. Yes they can be used to group and organize content, but they are much more powerful than that. Think about that Article content type we discussed. That term reference we mentioned might reference a list of Categories that you can display on the page. This list of Categories could contain links to the various Terms. Then your visitors can click on the links to view more Articles on the same topic. That's a fairly straight-forward use of taxonomies.
Why stop there? You could also have an additional Term reference on your Article content type that referenced a different Vocabulary. For our example, lets use a Vocabulary of called Office Locations and lets choose not to display this taxonomy as links. Think of term references as two way connections. Yes, you can use Taxonomy Terms to groups Node content, but you can also use Taxonomy Terms to pass information to Nodes. Rather than displaying our Articles on the Office Location term's page, we'll display Office Location information on any Article that has an Office selected. So while the Categories I select in an Article display as a list of links, we can choose to display Office names and addresses (fields on the Office taxonomy terms) for any Office Location terms chosen.
Sometimes there are benefits to linking to a taxonomy term, like with Categories. In other cases, like our hypothetical Office Location taxonomy, the benefit is not in the taxonomy term page, but in being able to use the reference to display term information on the Node. In more complex examples, the benefit might be both ways. The Office Location information on the Node may be the primary benefit, but you could also link to the Term page, so that a visitor could view all articles that referred to a specific Office.
This Redesign Project
For the redesign of DouglasT.com, I'm currently planning for two Node types, Page and Blog Posts. Page is fairly basic, using the Main Menu for organization, and has an image field in addition to the content field. Blog has an image field and two taxonomy references. One Taxonomy field is linked to a Topic taxonomy to group posts by related subject. The other references a Project Taxonomy to group Posts into series.