I've been trying to create a data structure that resembles something like:

            | Service 1 | Service 2 | Service x |
            |  Price 1  |  Price 2  |  Price x  |
| Feature 1 |    Yes    |    Yes    |    Yes    | Description 1 |
| Feature 2 |     1     |     6     |    20     | Description 2 |
| Feature x |    No     |    No     |    Yes    | Description x |

I've created a content entity Services, which has the following fields:

  1. Service Name
  2. Price
  3. Feature 1
  4. Feature 2
  5. Feature x

This works great, until I realise that I'm not including the descriptions of each feature.

Drawing on my knowledge of database normalisation, I intend to extrapolate the description and feature to its own content entity, Services Info. I think that would probably work just fine, with one small exception, I now need to maintain the list of features in two entities, something I'm loathed to do.

Is there any way I can get Drupal to synchronise the fields across two tables? So that if/when I add more features to the Services entity, it'll appear in the Services Info entity, waiting for me to input a description for it?

Or, if there's a better, more Drupally way to approach this problem, then please feel free to chime in!


I realise that my question might not be clear enough, so I thought I'd explain what I'd do if I weren't using Drupal to make this...

I'd have the following SQL tables:







... Now I'm looking at it, I guess I'm missing an entity..? Which if I introduced I could have them reference each other correctly?

If I were to implement it this way I'd also have the issue of not being able to REQUIRE that ALL SERVICE NAMEs have ALL SERVICE FEATURE VALUEs declared for ALL FEATURE NAMEs... Could I? Or would I just have to create a custom input form for the entities?

  • I don't understand the structure, can you show how you implemented this in Drupal terms? (base/bundle fields, field types, single/multi value). How does feature x scale (if x is a placeholder)?. If this is unlimited, then why not use a tag style reference to a taxonomy vocabulary feature (which would have a description field by default).
    – 4uk4
    Dec 28, 2017 at 19:18
  • The structure I'm looking for is that I can add as many services as needed. Each service has a set of features, of which, each service can store some data against (true, false, 0, 35, 'dog', 'cat', etc)... Then I also need to store additional data about the features themselves (a description, importance, etc.)... I want the feature to be the "question" for the services entity, and then in a view be able to display the description associated with that feature, along with the feature name, and anything else that may be relevant. As well as if the particular service has it.
    – Jack_Hu
    Dec 28, 2017 at 22:50
  • Still looks like you need a reference field, which defines a one-to-many relationship between services and features. Should work like a content type containing a taxonomy term field to a vocabulary, which both are fieldable and can contain as much data as you need.
    – 4uk4
    Dec 28, 2017 at 23:41
  • I don't understand what you mean by, "which both are fieldable"... I have made a feature vocabulary, but a service will have a value for EVERY feature. If you look at the table I drew in the OP, I will create services (Service 1, etc), and I need to say what value it has for a given feature. Not simply if it has a given feature, as a feature might be a value, not just a boolean.
    – Jack_Hu
    Dec 28, 2017 at 23:51
  • You mean like a node has a title for each image stored in the node, not in the image, so that the same image can have different titles? Then you need either a custom field type with multiple properties like the image field or use a paragraph to group the feature reference field with the additional data fields.
    – 4uk4
    Dec 28, 2017 at 23:55

1 Answer 1


Sounds like you want to "listen" for the creation of entities of type Services, and upon creation, you want to programmatically create another of type Services Info. For that, I'd recommend adding the hook_ENTITY_TYPE_insert hook into your custom module. Replace hook and ENTITY_TYPE with your custom module name and entity type, of course.

The function signature will include $entity as a variable, so you can do any sort of tests you want to do on it (for example, make sure the corresponding Services Info entry hasn't already been created, to avoid a possible infinite loop if you ever decide to write the sync for both entity types).

This method will look something like:

function my_module_services_insert($entity) {

  // If desired, add code here to check for pre-existing mathing Services Info; this will depend on your implementation.
  // For example, if name is unique, run an entity query for services_info entities with a matching name.

  $new_entity_fields = [
    'name' => $entity->getName(), // This assumes you want the entry to have the same name as the Services entry; change if desired
    // Other fields as desired
  $storage = \Drupal::entityTypeManager()->getStorage('services_info'); // replace 'services_info' with your entity type
  $entity_new = $storage[$content_type]->create($new_entity_fields);

That should do the trick. Good luck!

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.