Basic Data is a content entity that ships with an additional data property. The entity type is basic_data and you may add any fielded bundles you'd need.

The primary use case for a basic_data entity and NOT a node entity is not complicated. Nodes do not come with a data property that is required. If you have no data to store in a basic_data entity, consider using Migrate or some custom code to create nodes with fields that make up the appropriate structured content.

If you, on the other hand, would like to store blobs of data that are easily accessible by just about ANYONE using the system (pending permissions, of course) then you may just want a Basic Data entity for storing your data.

As an example, if I am calling an external service often, each hit is costly from a resource perspective. In fact, I would argue that spamming the same API over the same connection for the exact same data is quite wrong due to the environmental cost. So we SHOULD be caching things in Drupal. It is just that, the problem is basic... therefore hard. With PHP and Drupal, a developer can store the data (or just the data I care about) from the response, and they can do that anywhere. We can put it in cache, we can hide it in a hidden field, we can do anything.

That is problematic.

Basic Data assume we have an entity for this concept now. We, as developers, can look to one another to follow a practice that makes sense when working on the same project. That's what this project proposes. From a code standpoint, it looks like a lot of other custom entity types that exist. However, there is a user base that needs custom entities that aren't node, and they do not write the code. They compile architecture, and look to people like us to define the practices that they will use.

So, for some new projects, we are using this Basic Data entity and we've open sourced it here to make it easier for everyone else to use too.

One thing we have found is that we can do really cool things with basic_data entities and their bundles, without mucking up the 'Content' user space (nodes) thereby making the lives of our "Editor" persona more simple. This helps for everyone at the organization, and it really helps the user do the things they must do in Drupal without worrying about other complicated things.

If you are currently living in a world where you have nodes that are programmatically created and used as data store objects, not Content created by Editors... then you may consider working this way, and not doing that anymore. Here's a Basic Data entity that you can use for anything!

Supporting organizations: 
Funded Development

Project information

  • caution Seeking new maintainer
    The current maintainers are looking for new people to take ownership.
  • Module categories: Content Editing Experience, Decoupled
  • Created by saltednut on , updated
  • shieldStable releases for this project are covered by the security advisory policy.
    There are currently no supported stable releases.

Releases