REST views: DataEntityRow allows itself to be added to non-entity views

Created on 10 February 2016, over 8 years ago

Updated 27 February 2023, over 1 year ago

Problem/Motivation

Some views are not over entities. The 'Entity' row display for REST views still allows itself to be added to them, it just breaks.

Steps to reproduce:

Enable the REST module
Create a view over 'Log entries', and provide a REST export display. Hit Save. See NewView.png
Notice that the new view uses the 'Entity' row display, and yields an error. See ViewError.png

Without an actual entity, QueryPluginBase::getEntityTableInfo() finds nothing, and no base fields are added. So there's no fields at all, and the query breaks.

Proposed resolution

Solution: use hook_views_plugins_row_alter() and add all entity base tables to data_entity][base. (Per @dawehner, see #5.)

This is not the most elegant solution, but it retains BC. The "proper" solution will have to wait for D9. We should open a new issue for that proper D9 solution and add a @todo to the hook_views_plugins_row_alter() implementation pointing to that issue.
The proper D9 solution:

DataEntityRow should filter by entity type (or rather, by the base table). This probably means making it a derived plugin. Just like \Drupal\views\Plugin\views\row\EntityRow uses deriver = "Drupal\views\Plugin\Derivative\ViewsEntityRow", we'd need pretty much the same for DataEntityRow.
While we're at it, we might want to make DataEntityRow and EntityRow both inherit from a TranslatedRowPluginBase. That would save a bunch of boilerplate (eg: for EntityTranslationRenderTrait), and they could probably use the same deriver too.

Remaining tasks

User interface changes

Minimal. Only the default row will change for new REST export views on non-entities, but that's broken anyway. We might decide to change the displayed row plugin name from 'Entity' to eg: 'User', 'Node', etc.