Long story short:

I have various entity types in my system and some of their subsets (bundles) has the very same fields. So far I have 3 "common fields" sets, which are from EntityRelation perspective the weak entities. A set has from 3 to 9 fields in it.

The following constraints I need:

  1. When changing something in field bundle settings (eg: make it required) I don't want to sync all of the other occurrence of this field.
  2. Field content should be translatable (based on the parent)
  3. Field content should be revisionable (based on the parent)

So far the following solutions came to my mind:

  • Field Collection (bad experiences in D7, still in dev)
  • Separate bundle / entity (ECK maybe) + Inline Entity Form (months ago there was a problem with revisions)
  • Paragraphs (translation + revisioning good, but I couldn't make it to appear in forms just like Inline Entity Form (it always had the "+ Add new paragraph" and if it was a new content, the form of the paragraph didn't appear, only after clicking the add button)
  • Custom entity, which includes these fields as base fields. (a lot of hassle to generate the forms, listers, revision support.. etc.)

Do you have any advice for me to solve this issue?

1 Answer 1


Not a defintive answer, just some input.

We (the paragraphs maintainers) are working on reaching feature and user experience parity (or be better, of course) with the Field Collection module, specifically for non-typical paragraph scenarios (single paragraph type, single cardinality, default paragrapht type, ..). There are discussions on officially deprecating field collections in favor of Paragraphs, this might or might not happen. So I'd recommend to not use FC, but I'm obviously biased there.

The latest Paragraphs dev version has support for setting a default paragraph type now, which means that it will by default show the form fields for that already, and you don't need to add a type. The add button should only be shown if you allow more than one field, which is the default for paragraph fields but can easily be changed.

Revisions should work fine in IEF as well, if you use an Entity Reference Revisions Field. If not, then you'll have to report a but, but I assume the maintainers are actively working on that as it is a critical element of Commerce 2.x.

One important difference between the two is Paragraphs are by definition a composite of the parent node, that means they have a parent reference and not re-usable, in case that is a requirement. IEF doesn't have that and allows to search and reference existing entities.

The advantage of custom entitiy types (with base classes or traits to re-use base field definitions) is that they're way more efficient, Paragraphs/IEF both result in separate entities that need to be saved, and all the configurable fields need to be stored in separate tables. With custom entity types, you can add all the fields you need as base fields. We're constantly working on requiring less code for custom entities, listings can be done with views with none or very little custom code, widgets work for base fields too, so anything you can do with configurable fields can be done with base fields as well. One major pain point right now is a revision UI, but we're making improvings there as well and entity.module provides some basic user interfaces there as well, diff.module is also working on supporting all entity types.

Yet another option would be to define base fields/configurable fields in code. That is possible as well, but I personally wouldn't really recommend it, there are still some unfinished areas there, especially uninstalling/removing those fields is really hard, as the delete/purge process only works for configurable fields. You could technically also maintain configurable fields with code and sync them between multiple bundles.

  • Thanks very much! That's much more I was expecting in the first place! Based on these facts I will able to make the right way to choose!
    – ssibal
    Jan 5, 2017 at 10:13

Your Answer

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

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