Problem/Motivation
Views style and row plugins are specific to types of displays, you can see this in:
\Drupal\views\Plugin\views\display\DisplayPluginBase::buildOptionsForm
Where it does this:
'#options' => Views::fetchPluginNames('cache', $this->getType(), [$this->view->storage->get('base_table')]),
However, the \Drupal\views\Plugin\views\display\DisplayPluginBase::validate method does not validate that the selected plugins are actually valid, so you can easily cause problems.
See #2955378: Fatal error on Drupal 8.5, on a data_export display that uses not the data_export style but the *default* style, #3551130: Improve cloning in views to prevent crashes. for example.
Steps to reproduce
- Create a new view
- Add a page display, and override the default display plugin, but set it to the 'default' plugin, which is called 'Unformatted' in the UI.
- Use the 'Duplicate as REST export' functionality to produce another display
- Tweak the path of this display so that you can save the view
- Save the view
- On collecting routes, this will now cause a fatal error, since the Rest Export display plugin assumes that the style plugin is compatible, but it isn't because it's the 'default' plugin and doesn't have a
getFormatsmethod.
Proposed resolution
Validate the style and row plugin in the validate method.
We already do this in Views Data Export, see: https://git.drupalcode.org/project/views_data_export/-/merge_requests/90
Remaining tasks
Review the code.
User interface changes
More error messaging.
Introduced terminology
None.
API changes
None.
Data model changes
None.
Comments
Comment #2
steven jones commentedComment #3
quietone commentedHi, in Drupal core changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies. Thanks.