Module does not automatically delete content and configuration during uninstallation

Thanks for reporting this @chike! At first I thought this was normal Drupal behavior, when a field has data you can't delete it. However, it looks like the RSS field is bundled with the feed_block module that prevents it from being uninstalled. I wonder if it would be better to pull out the RSS field into its own module?

If the module created the configuration item during installation then I think the solution would be for it to delete it during uninstallation.

I'm not yet convinced that we should change this behavior.

This module is designed to create a Drupal block type, which includes Drupal fields.

This warning during an attempt to uninstall the module is the same Drupal behavior as attempting to uninstall any other module that has content configuration defined. It is also the same behavior as a site using Configuration Management that has entity configuration.

I think it is better that users get warned first, and take the explicit step to delete the configuration before uninstalling the module, to prevent a scenario where users unintentionally delete both configuration and content from their site. The tradeoff is that users that do indeed want to proceed with the removal simply need to delete the block type before uninstalling the module, and that does not seem onerous to me.

I'm happy to be convinced otherwise, of course. Examples of other contributed modules that uninstall block/field configuration automatically would help!

Some modules that created configuration items like views, view modes, entity types, content and such will give a warning that those items will be lost during uninstallation but some will uninstall and leave the configuration items behind. Two weeks ago I uninstalled flag_bookmark sub-module and it left a block configuration item it added on the entities so I started getting a 'missing block' warning when the entities load. I had to remove the block from the display before the warning stopped. So flag_bookmark uninstalled while leaving the block configuration behind on the site. But I know some modules will give warning and go ahead to delete the configuration.

So if you feel the module shouldn't delete anything then it should also safely uninstall and ignore any existing configuration it created. Not everyone will be able to delete a configuration item on the site, in my case I installed config_delete module to be able to do that but not everyone will know that or be able to know the drush commands.

Not everyone will be able to delete a configuration item on the site, in my case I installed config_delete module to be able to do that but not everyone will know that or be able to know the drush commands.

It's true that some site managers may not know how to do this. Because of this, I might propose that the Feed Block module provide documentation, on its project page, about how to do this. Proposed text:

Since this module provides a content block entity type, users will create content that is dependent on this module for display. If, after using this module, you want to remove it, you will first need to delete the content:

1. Find any content instances of the "Feed block" block type and delete them. If your site uses Layout Builder for content editing, be sure to check page layouts for inline blocks that use this module.
2. After deleting the content, you may safely delete the configuration from the UI. You can do this at /admin/structure/block/block-content/manage/feed_block
3. After deleting the configuration, you may then uninstall the module.

I will attempt a further explanation of why I think that it is not a good idea for this module to (A) delete the configuration during uninstall or (B) allow the module to be uninstalled without deleting the configuration.

This module provides a field type, rss_feed_field. It also provides a field instance, "Feed," and a block type, "Feed Block."

If the uninstallation of this module automatically deletes that configuration, any pages that reference the block type (e.g., a Layout Builder page where someone has placed an inline block of the type Feed Block) will have broken displays.

If we leave the configuration as is but allow the module to be uninstalled, the rss_feed_field field type will no longer be in the Drupal field type registry, and this could cause page load failures.

For this reason, I think the only responsible thing is to require content editors to manually delete the content, and then the configuration, before uninstalling this module.

The reason that Drupal adds this configuration validation warning during uninstall traces back to #2278017: When a content entity type providing module is uninstalled, the entities are not fully deleted, leaving broken reference → . So I conclude this is "by design"

Here are other instances that I found in research that, to me, corroborate that this is Drupal behavior normally, not an abberrance in this particular module:

If a module define a field type, it can't be uninstalled if you have a field of this type. This is not related which tables are in the database, and deleting tables in the database wont resolve this.

What you need to do, is to delete the field yourself. Drupal doesn't want to this automatically, as it could mean data loss.

-- https://drupal.stackexchange.com/a/221598

You can also uninstall the core Comment module by following these steps, but only after comment fields have been removed, which is a side effect of Section 6.2, “Deleting a Content Type”.

-- https://drupalize.me/tutorial/user-guide/config-uninstall

Okay I can understand better. The proposed text for documentation will help.

I've added a note to the project page, https://www.drupal.org/project/feed_block → , to explain the additional steps required for uninstallation.