Closed (duplicate)
Project:
Drupal core
Version:
8.0.x-dev
Component:
views.module
Priority:
Major
Category:
Bug report
Assigned:
Unassigned
Issue tags:
Reporter:
Anonymous (not verified)
Created:
4 Oct 2014 at 21:25 UTC
Updated:
2 Jul 2022 at 07:15 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
Anonymous (not verified) commentedComment #2
Anonymous (not verified) commentedI got my xdebug working, and this is the XdebugStack:
Hope this is of any help.
Comment #3
Anonymous (not verified) commentedAccording the Tips for making a good issue report I think I can mark this issue priority "Major"
Comment #4
jhedstromConfirmed this is an issue.
Digging into it a bit, the problem is in this code from
ViewsSelection::getReferenceableEntities():For whatever reason,
$row->_entityis null.Comment #5
jhedstromComment #6
jhedstromI think the issue lies in
\Drupal\views\Plugin\views\query\Sql::loadEntities. From the docblock:and the relevant code in that method:
So, in this example, even though the entity does belong to the base table (it's a 'beer' node, filtered by brewery status), since it is filtered on a relationship, the logic above fails to place it in the
_entityvariable.Comment #7
vijaycs85Comment #8
vijaycs85Comment #9
jhedstromThis adds a failing test. All that is needed to reproduce this error is to add any relationship, and filter using that relationship. In this test, I add a relationship to the users table, and filter on UID.
Comment #11
vijaycs85Thanks @jhedstrom for the tests. Here is the patch that checks for entity of type so that no fatal. Still need to check, what the result should display as test is looking for a node. So still one fail, but no fatal
Comment #12
jhedstromI don't think this is the way to fix the issue. While it will remove the fatal error, it will make it impossible to use complex views for the selection widget. I think the fix needs to go further up the stack, perhaps into how
Sql::loadEntities()is categorizing results.Comment #14
olli commentedHere's a patch from #2320989: only one relationship per entitytype allowed which reverts parts of #1712456: How to leverage cache tags in Views. The interdiff is against #9.
Comment #15
olli commentedComment #16
jhedstromThe fix in #14 makes sense to me. I've added a beta phase evaluation. Somebody else should bump to RTBC.
Comment #17
dawehnerSomeone seriously needs to update the IS:
@olli
Can you please explain why you had to reverts parts of the changes in the other issue?
Comment #18
olli commented@dawehner: reading the code up from the hunk in #6, we must make getEntityTableInfo() return table info keyed by alias to know the relationship id, that's why I reverted changes to getEntityTableInfo(). I think we could try loading the entities by type like the current code instead of by table like in #14.
Comment #19
jhedstromI was about to update the issue summary, but when trying to reproduce this, I was unable to do so. I wonder if it has been fixed elsewhere? Even the test in #9 passes with the removal of the distinct option (which was throwing a different error). I've re-attached that to test.
Comment #20
jhedstromSo...it appears the issue was fixed (bonus points if somebody can find the fix--bisect is failing me). I think it's still worth adding this test to the entity reference module to avoid future regressions.
Comment #21
jhedstromThis is definitely still an issue, and can be reproduced using the steps originally reported. The test to prove it needs a bit of work though. I've simplified the issue summary.
Comment #22
jhedstromThis fixes the test. Interdiff is on #14.
Comment #24
jhedstromComment #25
jhedstromComment #28
bforchhammer commentedI think the problem in this issue is the same as described in #2383197: Entities not loaded for relationships on same entity type. I'm working on a new patch at the moment: I'll include the test from #22 over there to ensure this is fixed as well.
Comment #29
avpaderno