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
    Oct 8 '13 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? Oct 8 '13 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
    Oct 8 '13 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. Oct 9 '13 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). Jul 8 '20 at 2:57

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. Oct 8 '13 at 21:00

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. Oct 9 '13 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. Oct 9 '13 at 7:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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