Problem/Motivation
This issue is spun off from the discussion @phenaproxima, @seanB, and @catch had in #2981105-37: Media Library should not modify the media view.
The cleanest and best solution to that problem would have been for Media Library to add a new display to the media
view at install time. This was impossible due to the config dependency problem described in #3085247: RenderedEntity field plugin should be more flexible about view mode dependencies. So, currently, we are stuck with an awkward set-up where one display of the administrative media overview lives in the media
view, and another one lives in the media_library
view. This is freaking weird for everybody.
Once that issue is fixed, though, it should be possible to cleanly merge the administrative views into the media
view alone, thus making things a lot more logical and maintainable.
Proposed resolution
At install time, the Media Library should create a new display of the Media view, which should have the nice grid layout and inherit all pre-existing customizations to the Media view, except for the fields. Upon uninstall, the new display should be removed. This code can be based on the work done in #2981105-31: Media Library should not modify the media view.
Remaining tasks
Write a patch, add tests, and commit the thing.
User interface changes
None.
API changes
None.
Data model changes
I'm not entirely sure what counts as a "data model", but none anticipated.
Release notes snippet
TBD
Comments
Comment #3
phenaproximaIn light of changes that took place in #2981105: Media Library should not modify the media view, I am closing this issue. We were able to remove install/uninstall-time modifications from Media Library, which means that, although the two /admin/content/media layouts are part of separate views, it is a clean separation that doesn't introduce fragility, bugs, and potential for data loss.