I would like build out page content using entity references. The problem is I would like to reference multiple types of entities (nodes and terms) plus content that is not an entity (views.)

I've explored this and what I have now is a field for both Node Reference and Term Reference and another with a View Reference which is not a very user-centric. Is there a more succinct way to achieve this?

  • what more succint approach do you want ? .... wouldn't you need a drop-down per relationship!?
    – tenken
    Commented Oct 8, 2013 at 18:13
  • 1
    I would like 1 field, not 3. From a general user's perspective content is content; a page is a page. So why shouldn't they be able to create a relationship/reference to different types of content with a single field? Commented Oct 8, 2013 at 20:48
  • sorry, you will end up storing 3 entries in the database somehow. you could always create an autocomplete dropdown list or fancy select list that includes options across any Type, Term or say User reference. If I understand this is a UI question now, i dunno just get creative. But the DB will store each value separetely (or 1 encoded value of 3 parts). Relation will store 3 fields, attached to the relationship entity.
    – tenken
    Commented Oct 8, 2013 at 21:27
  • 1
    It's a back-end question. I don't need to store/reference multiple values in a single instance of a field. I would have a repeating field that would reference a single piece of content per instance. Commented Oct 9, 2013 at 2:31
  • In case somebody else finds this question many years later like I did, another potentially useful module doing at least some flavor of the "multiple entity reference types in a single field" thing is Dynamic Entity References (though I think it still wouldn't support the Views case). Commented Jul 8, 2020 at 2:57

3 Answers 3


While relation can handle multiple entity types in a single relation type it can't reference Views. It's a challenging problem for two reasons: the view_id is a string unlike say nid so a database schema made to refer numeric IDs won't be able to copy with views. Also, views is not stored in the database necessarily so the utility of such reference is limited.

It should be possible to maintain an entity in the database that has a numeric ID and all it contains is the Views ID. Your only problem becomes when someone changes the machine of a view that is maintained in code -- how do you plan to be notified of such a thing when it happens outside of Drupal?

  • Thanks for the module recommendation! To your second point: machine names being changed won't be a problem. I'm developing for the end-user and such functionality would be covered in documentation for any future devs. Commented Oct 8, 2013 at 21:00

In Drupal 9 and beyond, this use case is covered by the Dynamic Entity Reference module, which in its latest 4.x version allows you to reference all content entities as well as config entities.

This feature may eventually end up in core.


How about https://drupal.org/project/entityreference and https://drupal.org/project/entityreference_view_widget for nodes and terms and https://drupal.org/project/views_field_view for embedding views?

Entity reference has nice usage statistics. I quickly tested Entityreference view widget, and it looks convincing (see the inspirational screen capture https://drupal.org/files/images/view_widget.png). Views field view I didn't test, but its usage is around 10 000.

  • 1
    Entity Reference still requires you to choose an entity type per field. I would still need more than 1 field. Commented Oct 9, 2013 at 2:27
  • The idea of Entityreference view widget is that you only need one field. So anything you can show in a view, you can select with this widget. Entity reference is just a dependency for the widget. Commented Oct 9, 2013 at 7:05

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.