Storage Entities

A new entity type for managing data that should be stored in the database, but only displayed within or associated with other content. If you're using a solution like Rabbit Hole to prevent direct access to an entire content type, that content might be better stored as storage entities.

Lightweight by design, but fieldable just like content types. This module is similar to Basic Data but where that module requires a "data" blob in addition to a name, this module only requires a name, and any other fields can be completely custom to suit your specific needs. Also, this module is designed to be revisionable and translatable.

A storage entity might be suitable for anything that does not logically fit into the concept of a node, paragraph or media entity, but where it makes sense to have a subset of fields. Think of a generic entity type for standalone objects.

For a similar use case (similar to Field Collections in Drupal 7), some site builders will use Paragraphs to have nested groupings of fields. Storage Entities are meant to be simpler to use, and on our roadmap is the ability to have nested content deleted when the parent entity is removed from the site.

Possible use cases:

• You have a node and you want to attach further information that logically belongs together, but not directly to the node itself. A concrete example could be: A node of type article should have the information with a first name and last name of a person, defined as two plain text fields. Instead of attaching those fields to the node, you could create a storage type that holds the two fields, and reference to the storage entity from the node.
• You have a node that holds a lot of fields and you have not yet enabled revisioning on that one, because it was not necessary before. Now you get a requirement to add another field to it, but the requirement is that it needs to be revisioned on every save. You could enable revisioning on that node type, but that would revision all fields on every save operation, which brings a lot of overhead that you might not want. You could use storage entities for that field and enable revisioning only on those storage entities.
• You want to store data that lives outside the scope of nodes, e.g. to prevent that data from being indexed by Search API and possibly accessible through existing node access rules. One such example could be to store internal, calculated or aggregated results as field values.

If you'd like to try out this module, you can install the Quick Links Kit module, which uses Storage Entities to store data.

Also, the Admin Toolbar doesn't include menu items for entities other than Nodes and Media by default, but you can apply the patch from this issue to list Storage entities (and other entities too) in the admin toolbar.

Complementary modules

Storage entities may be referenced or embedded within other entities, e.g. by using Inline Entity Form (https://www.drupal.org/project/inline_entity_form).

Besides regular entity reference fields, Storage entities may also be referenced via Entity Reference Revisions (https://www.drupal.org/project/entity_reference_revisions).

When contrib Entity API is installed (https://www.drupal.org/project/entity), Storage Entities are being filtered for accessible items on database level by using its Query Access API.