Needs review
Project:
Views Reference Filter
Version:
2.0.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
24 Dec 2024 at 16:16 UTC
Updated:
27 Oct 2026 at 09:30 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
maximkashubahi anisha,
could you tell me more the details about the bug, how to reproduce it.
Is it after update to 2.0.0-beta5 ?
what is the current version of the module you use?
Comment #3
anish.a commentedI am using 2.0.0-beta5.
I am not sure whether it happened after the beta. I think I selected some wrong options and got locked out of the page.
These are the warnings I was seeing in the Drupal messages.
I tried debugging and found that this is getting as
$renderableinprocessOptions. This obviously is not the array it is expecting.I am stuck here. Sending the configuration file for the view.
Comment #5
maximkashubaHi @anish.a,
Thanks for reporting this and for the debugging details, and sorry it took me so long to get back to you.
The root cause is that the filter's reference_display (entity_reference_view:entityreference_4) points to a display that is not of the Entity Reference type. Only an Entity Reference display returns its results as rows keyed by entity id, which is what the filter expects. Any other display type (page, block, default) renders the whole view as a single render array. The filter then walked its keys (#theme, #view, …) as if they were rows. That is where the Undefined array key "#row" warnings and the "0" is an invalid render array key exception came from. Since this happens while Views UI validates the filter, the whole view edit form became inaccessible.
The filter settings form only lists Entity Reference displays, so such a value can't be selected there directly. Most likely the configuration got into this state outside the form: through manual config editing or import, or a migration. The display id entityreference_4 also differs from the entity_reference_N ids that Views UI generates.
Still, a configuration like this should not lock you out of the view. I've added a runtime check of the display type. If the configured reference display is not an Entity Reference display, the filter no longer tries to build options from it. It returns no options, and a warning is logged:
▎ The display %display_id of the view %view_name is not an Entity Reference display.
The view edit form opens again, and you can point the filter to a proper Entity Reference display. A kernel test covers this case.
The fix is ready in MR !32. Ready for review.