Since D7 is now coming up on EOL I need to begin planning the transition of a complex D7 site to D8/9. There are 2 particular data design issues I want to revisit. Number one is that I have a number of pieces of data that are tightly coupled to each node (i.e. external reference numbers) that do not need to be normalized on their own tables and revisioned. I would rather integrate them.

Two, I have about 18 multifields in place. In case you aren't familiar, this is like a field collection, but without an underlying entity, and that is for speed. They work as a sort of shortcut to bundle fields together into a single custom field without having to create custom fields in code.

If I were working with bare Symfony and Doctrine both of these would be easy to solve-I would just create exactly the entities I want and work with them on those terms. Since the main UI is headless there is something tempting about using Symfony as a framework instead of Drupal, but I think Drupal will make a more stable platform for other requirements.

So one proposed solution is to create custom entities that will encapsulate the tightly coupled fields and use my own entities instead of nodes as the base for the site. I would also directly create custom fields instead of using the multifield module. I don't know D8 well enough to know if by using a custom entity I might be giving up a lot of the convenience methods/integration that the node entity has.

Another route is continuing to use nodes, normalizing out the tightly coupled fields, and using field collections instead of multifield. In doing so, the underlying data structure is a worse fit but I stay on well-worn Drupal paths. I just don't know how performant this solution is, and how much it over-complicates external querying.

Last, I could skip Drupal and use Symfony and Doctrine, and import packages like Elasticsearch integration, logins and user role management through composer.

So my question really comes down to 3 points:
* Full Drupal or Symfony + composer installed packages
* Standard Nodes or Custom Entities?
* Custom-built fields or field collections?

Thanks for your consideration

  • 1
    Oh man, you really took some effort to write down your question(s). But honestly, it's simply an opinion-based issue. It's absolutely up to you. You can ask this question 10 dev and probably get 10 different answers.
    – leymannx
    Feb 26, 2019 at 16:38
  • In D8 compound fields are the most efficient option, too. Since it is easy to generate a custom field type plugin you don't need a contrib module, only Drupal Console, which you probably already use to generate custom entities. For nodes vs. custom entities there is no clear answer. If you need the features nodes provide, build content types, otherwise build custom entities.
    – 4uk4
    Feb 26, 2019 at 16:45
  • Thanks to you both for weighing in. Leymannx, I guess I'm most interested in if someone can spot big pitfalls that I'm not aware of, so it helps just to know these are all valid. 4k4, do you have any hints where I can find docs on what benefitsi leave on the table if I use a custom entity? Feb 26, 2019 at 17:06
  • 1
    @greendemiurge, this was asked before, see drupal.stackexchange.com/questions/22586/… and drupal.stackexchange.com/questions/197669/…
    – 4uk4
    Feb 26, 2019 at 17:43


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Browse other questions tagged or ask your own question.