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

CommentFileSizeAuthor
#3 3085247-3.patch2.7 KBphenaproxima
#2 3085247-2.patch2.61 KBphenaproxima

Comments

phenaproxima created an issue. See original summary.

phenaproxima’s picture

Status: Active » Needs review
StatusFileSize
new2.61 KB

My favorite part: let's see how many tests this breaks!

phenaproxima’s picture

StatusFileSize
new2.7 KB

Switched to EntityDisplayRepositoryInterface::DEFAULT_DISPLAY_MODE, instead of hard-coding it.

lendude’s picture

Status: Needs review » Needs work

The main issue I see with the fallback is unintended information disclosure.

Scenario:

  • View that shows teasers and a limited set of data
  • Remove view mode
  • View shows full entity with all data

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 :)

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.