-2

I working on my first Drupal 8 site, and I heard 3 rules about Content Types:

  • More than 5 content types is too much
  • When content are similar (news, articles) is better to do one content type
  • Do not store data in taxonomy

My content on site look similar to that:

  • Editorial (title, description, author, contents, image, publish date, tags, category) :

    • News
    • Article
    • Blog
    • Review (summary, ratings)
    • Deal (link)
    • Contest (regulations, prizes, tasks)
    • Video (link instead of contents)

  • Database:

    • Anime
      • Studio
      • Characters
      • Anime Reviews (generated by users)
  • [and more]

Editorial have common fields, and some sub-types have additional fields. Anime have its own field, including Studio and Characters, which should have own fields (name, description etc).

And I'm lost, and researches don't give any results. There is my thoughts:

  1. All as content types ;)
  2. Editorial as content type, sub-types as drop down field, which change other fields. There is some solution for that ?
  3. Anime as content-type, Characters and Studios as Vocabulary.
  4. Anime Reviews are like comments with rating. Maybe add this like comment type ?

How to setup that kind of structure with the best performance ?

Improve this question
4
  • 1
    You might try out the demo_umami install profile to get an idea about how someone would put together a magazine like site. It's an example site with content about an online Food/Recipe Magazine. It only uses stable core modules, but in the next core version it should be using the stable Layout Builder module to do its layouts.
    – mradcliffe
    Nov 20, 2018 at 16:06
  • 1
    Also, I think you are on the right track to outline your site. This is what I do. There are probably too many opinions about how to build sites. I think your idea is going to work, but I probably wouldn't use characters as Vocabulary because they might not be re-usable? Studios, definitely, those are categories. I would only make one Editorial content type IF, and only IF, you plan on changing existing nodes from one sub-type to another.
    – mradcliffe
    Nov 20, 2018 at 16:07
  • You could probably reword your question to a specific content strategy question about who is going to be creating content, how content is displayed and that might be specific enough for a non-opinionated answer on how to create content types.
    – mradcliffe
    Nov 20, 2018 at 16:11
  • 1
    Here's a tutorial which shows one way that you could publish Anime as a content type, then allow users to select which published Anime they want to add a user-generated review of (using Entity Browser module): ostraining.com/blog/drupal/embed-entity-in-node-form
    – hotwebmatter
    Nov 25, 2018 at 0:35

1 Answer 1

Reset to default
2

Whoever gave you those rules was probably trying to stop you tying yourself in knots, so means well, but these rules are IMO just wrong.

The rules of good data structuring can be found in textbooks and I would encourage you to read them, but for this purpose:

  • Use different content types to store different kinds of value. So in your example, although both News and Review both have body text, they are not interchangeable: you want news with news and not mixed with articles.

  • Do not use different content types just because the appearance (rendering) of the content on a page differs. Use view modes, templates and/or CSS to do that.

  • Keep the number of content types to the minimum you can that does not require "magical knowledge" such as "knowing" that a news article written by author bloggs is actually a Blog -- etc

  • Be consistent. If you have four types of content as a group, and technically you could share two of them, don't: the consistency rule suggests that you need four types (and indeed you may find later that the two do indeed diverge).

  • Where there are shared groups of data (a gallery of images, perhaps), consider whether it would be useful to make a content type (or paragraph entity) for that shared part, and then reference it as needed. Sometimes such referencing can help keep repetitive code at bay, but it can also complicate the data model. If unsure, don't.

  • Look for opportunities to improve the model as the site grows and don't be afraid to adapt. Nothing is forever. Adopt the principle of least surprise.

Content types and entity definitions are composed of fields, and it is possible to share field definitions as well as types. Apply the same logic as above: just because you have an integer field doesn't mean you should use it wherever you need an integer: the field should IMO store a particular kind of data (e.g. speed in kph, dress size in EU units, number of items in cart). Don't mix them up.

As a result, fields should have names that reflect both their use and their "units": field_dress_size_eu, field_thrust_newtons, field_speed_kph, etc. Of course the units can be omitted from the name - but only because the site never uses an alternate for that kind of datum (e.g. all speeds are kph, not metres_second or miles_per_hour).

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.