Deleting a Media view mode should not result in the deletion of an entire text format

i am working on this .

When i keep the checkbox Allow the user to override the default view mode checked i am not getting the error .

Following the steps of the IS can confirm the bug still on 11.x

Pushed up MR 12404 with a POC of a different approach, described as follows:

• Views has the interface DependentWithRemovalPluginInterface, with an onDependencyRemoval() method. When dependencies of a View entity are removed, View::onDependencyRemoval() checks each of the view's displays to see whether any views handler plugins implement the interface and method. If onDependencyRemoval() in the implementing plugin returns TRUE, then the handler plugin configuration is removed from the view and prevents the dependency removal from deleting the view config entity
• The idea here is to create a similar interface and method in the Core namespace, and that method should be invoked any implementing plugin in a config entity's plugin collection, when a dependency of the config entity is removed
• The core version of DependentWithRemovalPluginInterface::onDependencyRemoval() is slightly different from the Views version. Instead returning a boolean of whether the plugin should be removed or not, it returns an it, which is 1 of 3 values: -1 if the plugin settings have changed, 0 if the plugin settings have not changed, or 1 if the plugin should be removed from the entity's plugin collection. (This could possibly be an enum?)
• In ConfigEntityBase::onDependencyRemoval(), if the entity is an instance of EntityWithPluginCollectionInterface, then any plugin in any plugin collection that implements DependentWithRemovalPluginInterface will have its onDependencyRemoval() invoked, and the return value is reacted on appropriately
• To address this issue specifically, the MediaEmbed filter is updated to implement DependentWithRemovalPluginInterface, and in onDependencyRemoval(), if any media view mode is being deleted and is present in the plugin's "allowed_view_modes" or "default_view_mode" settings, those settings are updated to remove that view mode and set to use the "default" view mode as needed. The method returns that the plugin settings have been changed, so ConfigEntityBase::onDependencyRemoval() returns TRUE. The dependencies for the filter format are then recalculated and should prevent it from being deleted when the media view mode is deleted

The new MR also includes the test from MR 3115
(The Build tests has failed consecutively a few times, but I can't identify any related reason in this MR, so just going to let that sit for a bit.)
Moving to Needs Work for this POC and soliciting feedback for this change to config entity subsystem.

ensure that any media already embedded with a removed view mode falls back to the default view mode

Is this still something we want to do? Right now MediaEmbed renders an error "The referenced media source is missing and needs to be re-embedded" for media embedded with invalid view modes, so it would be a change in behavior to make it show in the default view mode as fallback instead.

oily → changed the visibility of the branch 3326447-fail to hidden.

In our case, we validated the display mode configuration deletion a bit too fast and completely lost the data related to several fields in various entity types. Hopefully we had daily backups.

Moving to Needs Review to get feedback on PoC MR. Also, there's functional test coverage for the specific issue, but will probably need additional tests for the new Interface/API introduced if we go with the approach.

Looks like my proposed resolution in #16 overlaps a lot with 🐛 Config entities implementing EntityWithPluginCollectionInterface should ask the plugins to react when their dependencies are removed Needs work and might make this a duplicate of that.

I also ran into this and opened 📌 Deleting filter formats may result in data loss Active for issue I faced as consequence: deletion of text item fields that have the text format as "allowed_format". I do think we should fix both, this issue and 📌 Deleting filter formats may result in data loss Active .

Checking on the proposed solutions I think both are viable. I agree that MR 12404 is the best approach though. Since it's a generally new feature, I guess it's best done over at [#579743]?

Agreed @fago; any issue that implements a fix for this can be treated as a critical UX bugfix (even if it requires a feature or API addition).