Problem/Motivation
This issue is spun off from the discussion that @phenaproxima, @seanB, and @catch had in #2981105-37: Media Library should not modify the media view.
The cleanest solution that issue would have been to consolidate the media_library and media views into a single one. However, this was impossible because the RenderedEntity field plugin declares a config dependency on the view mode it's configured to use, and does not implement any kind of handling for removal.
This means that, if you are using the RenderedEntity field in any view, and you remove the view mode...you also end up deleting those views. That seems needlessly harsh and destructive.
Proposed resolution
RenderedEntity should implement DependentWithRemovalPluginInterface, to support onDependencyRemoval(). When a view mode is removed, it should fall back to the default view mode rather than enforcing a config dependency that results in deleting the entire view.
Remaining tasks
Implement the aforementioned interface on RenderedEntity, and add test coverage. Then commit.
User interface changes
None.
API changes
None really; a specific Views field plugin will implement an additional interface.
Data model changes
None.
Release notes snippet
TBD
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | 3085247-3.patch | 2.7 KB | phenaproxima |
| #2 | 3085247-2.patch | 2.61 KB | phenaproxima |
Comments
Comment #2
phenaproximaMy favorite part: let's see how many tests this breaks!
Comment #3
phenaproximaSwitched to EntityDisplayRepositoryInterface::DEFAULT_DISPLAY_MODE, instead of hard-coding it.
Comment #4
lendudeThe main issue I see with the fallback is unintended information disclosure.
Scenario:
If the teaser is being used to restrict the information you are allowed to see on a site you can now see more than you should. This is the main reason that #2468045: When deleting a content type field, users do not realize the related View also is deleted was restricted to fields and not other plugins. The effects of removal/fallback are almost impossible to judge. So at the very least I think we should disable the View when we do this (since onDependencyRemoval in the current patch returns false, Views won't do that out-of-the-box), but that would mean this becomes dependant on #2832558: Add a 'disabled' section to config changes page when removing config landing, since I don't think we can sneak another one past the core commiters :)