1

I want to store some data that is related to a node and trying to figure out the best way of doing it. For example, I send emails related to a node and I want to save details such as:

  • To Email address
  • Cc Email Addresses
  • Date sent
  • User
  • Email type
  • Other chosen email options etc

In the past I would use Paragraphs to have an unlimited field but this will, over time, grow to have a lot of entries. I'm also using Revisions on the node so I think this will slow everything down when saving the node.

My question is... should I create my own entity for this? One that doesn't have a page like a node does? Or is there a better way of storing the data? I could create a custom table, store it there, and maybe register that with Views but I would like to have the entity API available on the content and maybe add fields in future using the UI. Any ideas?

Is there a module similar to Paragraphs but is not a Entity Reference Revision type? Or is the Drupal way to create a custom entity in a module?

Improve this question
2
  • Well, probably an opinion-based thing. With no right or wrong answer. If you want to keep it as simple as possible maybe create another custom node type, let's say "Node mail log", and then have all the fields you mentioned as simple multi-values fields in there. And now when you send a new mail, create a new "Node mail log" node and add a reference to the node to which the log entry belongs. – leymannx Oct 18 '20 at 15:38
  • @leymannx I thought about doing this but I don't want actual nodes, as in visible or accessible pages which would require some extra coding to hide. I'm really looking for the most 'Drupal' way of doing this as a developer, so I'm now thinking going the custom entity via a module route makes more sense. But I agree, maybe there's no 'correct' way of doing it – Web Assistant Oct 18 '20 at 15:49
6

Create a custom content entity with entity_reference fields relating each "email" entity to a node and a user.

The information you're saving is neither part of the node's content nor part of the node's metadata. It is metadata about an email that has been sent. Since the email records aren't related to any particular revision of the node, you want the email records to remain even if the node is reverted to a previous revision. So you shouldn't put the email records in a node field of any kind.

Creating a custom content entity is more useful than creating a custom table, because - as you have pointed out - you can make use of the built-in Entity API, which allows you to add field bundles, but also makes it easy to relate your records to node and user entities, and optionally do cleanup if those users or nodes are deleted. If you generate your custom entity using Drupal Console then it will work out of the box with views.

Improve this answer
1
  • I agree. I've always made do with using Paragraphs but as you say, the email data isn't related to any revisions of the node, so I think a custom entity is definitely the answer! Thanks – Web Assistant Oct 18 '20 at 15:44

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