Problem/Motivation
Views which have a relationship on the same entity type, do not properly load entities for results.
Steps to reproduce:
- Go to
admin/structure/types/manage/page/fields, add an entity reference field "Articles" (Type of reference "Content", optional limited to content type "Article"). - Create a bunch of articles, with body text. Create some pages referencing articles.
- Create a new view of "Basic Page" nodes:
- Add a new field "Content: Body" (without relationship).
- Add the relationship "Content: Content referenced from field_articles". Leave it as "not required".
- Add two fields "Content: Title" and "Content: Body", using the "field_articles" relation.
After adding the relationship, you'll notice that the body field of the basic page (i.e. the one without the relation) is not displayed anymore, while the title and body of referenced articles are still shown.
This happens because Drupal\views\Plugin\views\query\Sql::loadEntities() currently maps all tables from the query to thei respective entity type and does not consider that different tables can map to the same type. This leads to information on the original table (i.e., $relationship_id == 'none') being lost, which in turn means that entities will not be loaded for the original table.
Having multiple relationships leads to entites being loaded only for the last relationship/table.
Proposed resolution
[todo]
Remaining tasks
- Write tests.
- Review patch
User interface changes
None.
API changes
None.
Beta phase evaluation
| Issue category | Bug because this clearly does not work as expected. The outcome is confusing for site-builders, as there is no indication in the UI why values are missing. |
|---|---|
| Issue priority | Major because this can be considered a regression from views 7.x, and arguably is common site-building requirement. There is no work-around (?). Not critical because it does not render the whole system unusable. |
Comments
Comment #1
bforchhammer commentedAttached is an example view, which assumes that you have the "Basic Page" and "Article" content types from the "standard" installation profile, and that you have added an entity reference field "field_articles" to the "Basic Page" content type.
Comment #2
bforchhammer commentedAttached patch fixes the issue. All credit goes to @webflo.
Comment #3
webflo commentedComment #4
webflo commentedComment #6
bforchhammer commentedHm, the patch was for an older version of core. Here's a reroll... go, testbot, go!
Comment #7
bforchhammer commentedAttempted to fill out the beta phase evaluation; feel free to correct me. :)
Comment #8
queenvictoria commentedI can confirm that this patch corrects the problem stated. I was actually trying to chase down a very similar bug which is the same symptom with the reversed relationship. I attach here an updated View that demonstrates that this patch does not fix the entire issue. I'll try and update the patch to work in both directions. Nice catch and fix @bforchhammer !
Comment #9
queenvictoria commentedFirst just rerolling against HEAD
Comment #10
queenvictoria commentedAh looks like my View was bad. Here is a better one..
Comment #11
queenvictoria commentedOk to make this patch work with reversed entity references I've just added the relationship_id to the `entity_tables` key. Is there a better unique name? Should the aliases be UUID's? Field names?
Comment #12
queenvictoria commentedOops patch included the .orig. Sorry.
Comment #13
queenvictoria commentedComment #15
queenvictoria commentedOops totally got that backwards.
Comment #16
queenvictoria commentedComment #17
dawehnerThe general idea totally makes sense, we have to take care about relationships when we load all those entities.
should we maybe rename the variable to reflect the new structure?
Sadly we certainly needs some kind of test coverage so this doesn't break anymore in the future.
Comment #18
queenvictoria commentedHey thanks for talking a look. That snippet you mention came via @bforchhammer and @webflo. I've made only a minor change so I'm not really clear on what is going on there. What would you suggest as a new variable name?
So the bug is that we are missing fields in Views on an entity when we add an entity reference relationship (or a reverse relationship). So a test would be
* Create a content type (A)
* Create a content type (B) with an entity reference field (C)
* Create content of type A (Aa) with body content
* Create content of type B (Ba) with body content and a reference to Aa
* Create a View of content of type B
* Add a relationship to content referenced by field C
* Access field 'body' on Ba
* Create a View of content of type A
* Add a reverse relationship to content referencing via field C
* Access field 'body' on Aa
Does that sound right? Have I missed any steps?
Comment #19
bforchhammer commentedI'm working on tests...
Comment #20
bforchhammer commentedDone.
I have extended
EntityReferenceRelationshipTestto check that we have valid entities set on the result set when we use a relationship as described above. I also included the test from #2350699: Using entity reference views selection handler with a relationship results in a fatal error, which has the same problem when using views-based entity reference selection handlers.Comment #21
bforchhammer commentedComment #22
dawehnerPerfect!
The existing test coverage also tests _relationship_entity
Comment #24
bforchhammer commentedThe test-only patch was expected to fail, so this is still RTBC :)
Comment #25
bforchhammer commentedComment #26
alexpottCommitted a4bb2fa and pushed to 8.0.x. Thanks!
Thanks for adding the beta evaluation to the issue summary.
Comment #28
webflo commentedComment #29
bforchhammer commentedAwesome this got in! :)
The commit message should have also credited @webflo and @jhedstrom, who actually wrote most the initial patches. I should have added that into the issue summary; I'm really sorry, guys.
Comment #30
alexpottre #29 - fixed :)