When module uninstall, view is deleted

Created on 13 August 2018, almost 7 years ago
Updated 11 December 2023, over 1 year ago

Hello!

I was testing the module to know if I can use it in my project when I came with the following behavior:

Enable the module
Added to a view
Uninstall the module via "drush pm-uninstall"
The view is deleted completely

Have a good day!

πŸ› Bug report
Status

Active

Version

3.0

Component

Code

Created by

πŸ‡¨πŸ‡΄Colombia Daniel Coy

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡¬πŸ‡§United Kingdom entropea

    So I did a didn't get any warning when uninstalling the BEF module (Gr8 module, btw! :)

    drush pmu better_exposed_filters
     [error]  A non-existent config entity name returned by FieldStorageConfigInterface::getBundles(): entity type: taxonomy_term, bundle: offences_relating_to_directive_2008_99, field name: field_offences_relating_to_direc
     [success] Successfully uninstalled: better_exposed_filters

    The View in question is now gone without warning.

    Sadly it was two days of work without doing a cex, ah well. Just hoping this behaviour can be changed to save any future heartache.

  • πŸ‡ΊπŸ‡ΈUnited States smustgrave
  • I think the first thing to try is to have all the plugins provided by this module implement Drupal\views\Plugin\DependentWithRemovalPluginInterface and its onDependencyRemoval() method. It might be convenient to use the Drupal\Core\Plugin\PluginDependencyTrait as well. One example to look at is the Drupal\views\Plugin\views\field\EntityField plugin.

    Basically you want onDependencyRemoval() to return TRUE when the BEF module is uninstalled, so that the plugin is removed and hopefully prevents the whole config entity from being deleted.

    Not sure whether this by itself is sufficient, since the views handlers/plugins ecosystem is complex, but it's probably a good place to start.

  • πŸ‡¬πŸ‡§United Kingdom joachim

    There are at least 2 separate issues here:

    > The problem is that there needs to be logic to remove BEF from the view's configuration when BEF is no longer used on the view

    > have all the plugins provided by this module implement Drupal\views\Plugin\DependentWithRemovalPluginInterface and its onDependencyRemoval() method

  • First commit to issue fork.
  • πŸ‡ΊπŸ‡ΈUnited States smustgrave

    Would like to hopefully get this in but will admit not sure where to begin.

  • Took a quick look at this, only really looking at the ViewsExposedForm plugin bef (Drupal\better_exposed_filters\Plugin\views\exposed_form\BetterExposedFilters). Handling the plugin types that BEF provides itself will have to be looked at separately.

    So, unfortunately, "exposed_form" is not considered a handler type by core views, so when it loops through looking for handler plugins implementing DependentWithRemovalPluginInterface, the exposed form plugins are ignored.

    What needs to be done looks like:

    • Implement hook_uninstall()
    • In the uinstall hook, load all viewconfig entities and filter for those with a dependency on better_exposed_filters
    • Loop through all the relevant views and all the displays for each view
    • In the display options for the display, if the exposed_form type is "bef", set it to "basic" and reset the exposed_form options to the default for basic
    • Save the view
  • πŸ‡ΊπŸ‡ΈUnited States smustgrave

    Dumb question, when you're on the uninstall confirmation screen won't it show that views are still going to be deleted?

  • Dumb question, when you're on the uninstall confirmation screen won't it show that views are still going to be deleted?

    Maybe, I never do things from the UI. But if so, what might be needed a core issue to allow exposed_form plugins on a View to react to a module being uninstalled.

Production build 0.71.5 2024