When is a content type?
Written in response to
This set of really good questions by @jjosephmiller gets at the heart of what the CMS's job is. Do its "content types" (or templates, or post types, or entity types, etc) necessarily map to the conceptual "kinds of content" that exist in the high level map of an org's content? https://t.co/6z2fWtN0qm
— Actually, (@eaton) October 28, 2020
The most obvious reason to create separate content types is because different content structure, different fields.
Other reasons to define a separate content type can go beyond differences in the needed field structure:
- Different editorial workflows.
- Governance: difference in content life cycles.
- A simple(?) way to segment who can access what
Yes, there are other tools available to achieve the above (i.e. taxonomy, roles, groups in Drupal parlance), but at a certain point, the maintenace and complexity cost of DRY (don't repeat yourself) can become too high.
The definition of the function of a content type is a wider consideration than its functional-structural definition on field level alone.
(I suspect there's an analogy to be made here with object oriented code. Not all giraffes, kangaroos, wolves, mice, cows, lemurs should be instances of the same mammal class?)
An example of “all in one”: in one case we pushed really hard on gathering wildly variable service-related content into a single content type for:
- future extensibility. Much of the service was info at first. Actual handling of service requests (order this, request that, subscribe to) will be added over time and can be made available across the whole set.
- governance: tighter control of who can create these items to reduce the chance of duplication, which was a problem
At the same time we created different versions of a training because even if most fields were shared, which ones were required varied greatly. No meaningful (predictable) shared set of what we could assume to be available. Hard to create view modes for that.