Problem/Motivation
The division of features among content, taxonomy, and blocks--publishability, revisionability, hierarchy, display path, block display, etc.--is somewhat arbitrary, and the community has demonstrated that the original assumptions of mutual exclusivity between concepts is not always sufficient. Consider for example all the contrib modules that add hierarchy to nodes, allow placement of nodes as blocks, or (for a while there) just made everything into nodes. Just because something serves a taxonomic function, for example, doesn't mean it isn't also content.
The effect of the present dynamic is that site builders are often forced into awkward architectural choices. Imagine a zoology website with pages for animal phyla, classes, orders, families, genera, and species. Taxonomy seems like the obvious choice to represent this data--it's practically the canonical example. However, if the pages need to go through workflow, taxonomy is ruled out because terms (
currently →
) aren't revisionable or publishable. The site architect will probably create a content type, therefore, and try to find a bolt-on solution for hierarchy.
In other words, content, taxonomy, and blocks are not mutually exclusive categories, and the distinction between them in business terms is in no way clear or absolute. Whereas in Drupal as it stands, the reverse is true. And it is unsurprising therefore internally to see inconsistent APIs, user interfaces, and permissions between the systems, as we do; and externally a large number of contributed modules compensating for the misalignment and a lot of blog posts trying to explain when to use which approach, as we do.
Proposed resolution
Align our technological assumptions with how users actually view content:
- Abstract the currently distinguishing features of nodes, taxonomy terms, and blocks and make them configurable--much as we did with comments, which used to be an on/off feature of content types exclusively but can now be applied arbitrarily to (basically) any content entity type as a field.
- Eliminate the mutually exclusive distinction between content, taxonomy, and blocks and just make everything "content". Unify the APIs, and if a distinction is still necessary or valuable at the UI layer, make it configurable.
This is a radical proposal, I realize, but I cannot but suppose that it would result in great savings in terms of reducing code in core and complexity in contrib. (Imagine writing code with the knowledge that any content was just a node with fields and properties!) In business terms, it seems like nothing other than an acknowledgment of the manifest facts.
Remaining tasks
TBD
User interface changes
TBD
API changes
TBD
Data model changes
TBD