What are the advantages or disadvantages of using reference based modules instead of taxonomy module?

Question

I wonder how to decide either to use core Taxonomy module or Entity Reference module?

I didn't use Entity Reference module before but I've used the taxonomy module (and some related modules) on 10-15 websites.

What are the advantages or disadvantages of using reference based modules instead of taxonomy module?

---

Recently, I've started to build a magazine archive website.

There are lots of magazines. These magazines have issues. Each issue has articles.

The smallest (and deepest) part here is the articles.

Article

• Page number (range):
• Title:
• Author:
• Article type:
• Keywords:
• Magazine:
• Issue:

Issue

• Issue number:
• Cover image:
• Date (published):
• Magazine:

Magazine

• Description:
• Cover image:

Here, there are (at least) 2 methods to implement this website:

1. There will be a content type called article and all others (issue, magazine, author) will be taxonomy terms (hierarchical). There would be a hierarchy between issue and magazine etc.

2. There will be lots of content types: article, issue, magazine, author. While creating articles; issue, magazine and author could be referenced etc.

So, theoretically both ways are seem very similar.

Is there anybody who faced similar situation and could you please say which method you preferred, why?

Answer 1

There are also other solutions to your problem.

Field Collection

You can use field collection and field collection views modules to store and organize contents. Using this approach the Issue and Magazine are going to be Field Collection type, Issue is a field of Article and Magazine is a field of Issue. I have experience of implementing such structure. In my case the requirement was a Library that should contain books (with Title, Publisher and ... fields), Every book contains multiple volumes (Number of pages, translator, ... ) and each volume also contains unlimited number of some other items (like the scan of some pages that are not the same among the books).

I implemented this using Field Collection approach and it is very nice. You can easily create a link to edit every individual items of every field collection and you can also filter by items of field collection. I posted an answer to Group items in Views by value in Field Collection which shows how to work with Field Collection Views

Entity View Attachment

Also known as EVA module.

"Eva" is short for "Entity Views Attachment;" it provides a Views display plugin that allows the output of a View to be attached to the content of any Drupal entity. The body of a node or comment, the profile of a user account, or the listing page for a Taxonomy term are all examples of entity content.

You can use EVA to display only fields values for a particular piece of content, giving incredible control over the display and formatting flexibility of the fields. For example you may desire to have two fields concatenated in some special way. You can add your fields to your EVA display, set the contextual filter to NID, add a Global: Text Field, and using tokens format your fields with HTML. Don’t forget to exclude your fields from display if you are going to use them together in a Global: Text Field. Example: You may have a city, state, and zip fields. You can combine them in a Global: Text Field in Views to display as “City, State ZIP”. When you manage the display for your content type add the EVA just created to the display and whenever a node the type is displayed it will pass its nid to the EVA and the EVA will return the fields you select, formatted as you desire. (source : EVA and Entity Reference Use Case How-to)

This module is perfect, It attaches a View as a field to nodes of a content type. I used this module to create an Album. The album contains singer (with some information about each one) and songs that contains a File, Title, Rate and ... . So I created a View of type EVA and I attached it to a node. So on the node page of every Singer, I displayed this View which gets it's appropriate information from the node. The Views with Entity Reference is a perfect tutorial of how to use this module.

Taxonomy Terms V.S Entity Reference

I recommend you to read Entity reference vs. taxonomy and Are there any benefits/caveats with using Entity Reference over Term Reference? , As it says Taxonomies are best used when organizing similar items in a hierarchical fashion. Like tags.

Taxonomy allows you to use free tagging (it can be disabled using Content Taxonomy module), which enables the creation of new tags on-the-fly. It is very easy to modify the skeleton of contents. Using this approach, regular or at least some authenticated users (who have no knowledge of programming) can change this skeleton. Hierarchical Select module is perfect example of such approach.

Even though Taxonomy is easy to use but I myself prefer Entity Reference, it opens up lot's of possibilities and scalability and allows of creation very complex structures. The concept of entity in this context is not limited to content. It can be comments, users, taxonomies and ... . It is much more scalable so you will not be worry about the customizing content types, or modifying it in the future (as it was pointed out in Entity reference vs. taxonomy). I believe the Entity approach is more powerful than Taxonomy.

There are also some other combinations of these approaches which it is unnecessary to mention them.

Anyway I recommend you fully understand Entity approach and it's related modules. If you use it in multiple projects, despite of it's complexity it will be very easy to you to use it. Not only in the yours current requirement but also in the future it is going to be a Very Reliable Tool for you.

Answer 2

You could also have some other combination, like articles and issues are nodes an magazines are taxonomies.

There isn't really a right or wrong answer for this it comes down to personal preference, specific project requirements, etc.

It is best to use nodes for content and taxonomies for categorisation of that content, however sometimes it can get a bit murky as to whether something is just categorisation or its own content.

For example, your article type and keywords fields would seem to more obviously be taxonomies, but issue and magazines could really go either way.

One thing that could influence your decision is out of the box functionality. For example, there are a lot more add-on modules for nodes than there are for taxonomies but for taxonomies you get out of the box listing pages (if you want them). There might also be hierarchy related functionality that is easier to get out of the box with one solution or the other.

Content type definitions are only part of the picture. You should definitely fully consider how you intend the content to be presented to the user, how you want the user to navigate through the hierarchy of content, how does this content relate to other content on the site, how do you want admins to administer this content, etc. For example, do you want some sort of hierarchical menu system, do you want people to be able to go to magazine or issue pages or is content related to those only visible on the article pages. Do you want to have a single search that lists all 3 types of content (this may be less trivial if some are nodes and some are taxonomy terms).

Plan all that out and then see what modules are available to help you achieve that. You might find one way will make it easier to achieve what you want. If not then you just have to go with the one you think is best for whatever reasons you have.

Sometimes you may go one way and then find something that makes it difficult to achieve your requirements. If you plan it up front as much as possible you lessen that risk.

Answer 3

One other consideration when using taxonomy terms for things like "Magazine" is that you will lose out on functionality such as revisioning and comments on those items. Granted revisions can be added with a module such as Taxonomy revision but that's a module with a very low install base. Personally I'd trust core's on revision handling on nodes over this.

I can think of at least one occasion when I've had to change something from a taxonomy term to a node after a project has gone live due to changes in the requirements, and this involves a fair bit of restructuring and migration.

You'll probably find that if you do move to using other entity types such as nodes with entity_reference then there you won't have any trouble making the change as everything works in much the same way but it will give you more flexibility.

Answer 4

I won't say this is the most accurate answer, but it is how I think about it. I will explain with some examples.

I usually use taxonomies to categorize nodes based on an abstraction. For example, news can be categorized into sport, political, etc.

But when I want to have a reference like a magazine I am thinking about the future. Think about when you want to help the user decide which article to choose. Magazine rank (Impact Factor maybe) is a possibility. Or maybe I want to contact that magazine. A term would not help me in this situation, where if it were a node or entity it would.

On the other hand you have to do some stuff by yourself. For example, clicking a taxonomy term would lead you to a page filled with categorized nodes of that term. So now a view and a contextual filter is needed, etc.

Answer 5

I was sure someone asked why I would stay away from field collections, but the comment appears to have been removed. Either way my 2 cents:

Taxonomies should be used for classification and categorisation. Not for content relationships. By linking 2 pieces of content via a taxonomy term you are using 3 entities where you only need 2.

In my experience, whilst taxonomies are now fieldable, they are not fully fledged entities, and so should not be used as "content".

In this particular case, if your Magazine has content (a description of what is it, details on ordering it etc.), or a "page" of its own, then it should be a content type, because it is content.

The issues are are a little ambiguous, but odds are you have an overview etc, so they likely have a page, and are likely content too. So another content type.

The articles are obviously content types.

In building the admin for this you can use the Entity Reference to link these pieces of content, but you can go one better.

In the same way that @Drupalist suggested using Field Collections, you can use inline entity forms (I think part of Entity Reference). Field Collections are one of these old modules that where a great idea, not very well implemented, and with many collisions with other modules. Whilst they are now entities, they still have issues, and you would be better using fully fledged entities (even content types) for things like you authors etc.

Inline entity forms lets you create and edit referenced entities, from inside the entity you wanting to reference from... so, create/edit author from inside an article, or just reference one that has already been created.

Add in CER and you will automatically get a reference from the author back to the article, the article back to the issue, and the issue back to the Magazine, or whatever direction you are going. This has advantages in how your views perform, but also lets you show a list of articles on the author page, and the author info on the article page, all without views at all.

Full circle back to taxonomies, you would then use these to "tag" articles etc. with... "fishing", "car", "computers" etc./whatever... so you can find any issue, magazine, article or author that has content/written about that tag.

Tried to make that brief, so hopefully it helps and makes sense. I have done this on dozens of sites. Global sporting events, travel/holiday booking sites, international broadcasters, beverages, charities etc. Robust powerful, and covers you for unforeseen requirements.