Delete blocks on uninstall

Bumping the priority as data loss problems are serious.

I just had this problem, too. Rescued with a backup, but seriously a major problem. Right now, this module "does not play well with others," it seems.

Lets make it critical, because data loss is.. critical.

Basically the goal should be: uninstalling the module should not delete any blocks, it should only delete the block visibility group configurations.

I had the same experience with 8.x-1.1 -- any blocks that had previously been in groups were deleted when this module was uninstalled, even if the blocks were no longer in any group. Not sure this module should be considered stable as long as this behaviour persists.

Same thing for me on 8.3.6 and BVG 8.1.1.

It seems wrong to me that block_visibility_group is listed as a module dependency in a block's `.yml` file.

In example of a View or Google DFP ad block it makes sense that these block's `.yml` files have views and dfp listed as module dependencies. However, why is this the case for BVG?

A workaround for this is to export the block's configuration, edit the resulting YML files and remove the "block_visibility_groups" line from the dependencies > module section of the block's YML file, and re-import the block's configurations. You may also want to remove any lingering BVG settings from the "visibility" section of the YML file as well.

Not directly related to this issue, but in case it helps anyone else: I came across this issue while looking into another BVG issue where blocks weren't appearing with BVG installed even though no BVG settings were set for those blocks through the UI. In this scenario I had blocks that should have had no lingering visibility settings (global blocks) so I simply replaced the full "visibility: ..." section with "visibility: { }", re-imported the YML files, and that resolved the BVG block visibility issue.

@nwoodland: Good insights, thanks for uncovering that.

This suggests that it should be possible to have a hook_uninstall() script that loops over all of the blocks to remove the visibility groups. The question is, though, would the visibility group data's presence result in the blocks being deleted before hook_update() is executed?

Installed this module.
Did not perform any explicit configuration of this module.
Did some work creating blocks and placing blocks.
Some blocks stopped working, and some blocks no longer appeared (See #8 above), despite not having done anything explicit with this module.
Decided to uninstall module.
Module uninstall deleted all blocks (including main menu block) that had been edited during the time this module was installed (major data/content/functionality loss).
-
This module causes unexpected block failures and behaviors.
This module causes data loss on uninstall.
Keeping the module would have meant having inexplicably non-working blocks.
-
Site builders beware!!!
-
I agree that this module should be considered both extremely hazardous and unstable until the problems reported in this thread get repaired.
-
... seriously burned - will have to rollback to one of various backups, possibly before BVG module install, and lose significant work ...

Any progress on this issue by anyone?

Would like to use this but what DrupalWebsiteBuilder wrote is a stark warning and makes this unusable until fixed.

Kind regards

I recently started using this module to control more complex visibility rules for one of my blocks that were not working how i expected with just the Core blocks system.

After seeing this issue, I decided to try it and uninstall the module.

After uninstall of the module, it did delete the block that was using the visibility rules with the module, but it did not delete all of them.

Ok module maintainer here sorry I did not get to this sooner.

Here is patch that removes the condition from all blocks on hook_uninstall.

It also has test coverage to prove a block that had a group condition is visible and the condition now longer applies.

This means visibility will no longer be restricted.

The "TEST_ONLY" patch proves it fails without the fix.

+++ b/block_visibility_groups.install
@@ -0,0 +1,23 @@
+    $conditions = $block->getVisibilityConditions();
+    $conditions->removeInstanceId('condition_group');
+    $block->save();

Performance wise we could check if the condition exists first and only remove and save blocks that have the condition.

Good idea!

+++ b/block_visibility_groups.install
@@ -0,0 +1,23 @@
\ No newline at end of file

just a nit

@andypost thanks for taking look.

1. Fixed #15
2. Fixed #16
3. Updated a comment

Since this is critical I committing and making new release.

I pretty this fixes the problem and don't see how it could make it worse.

Still interested in other testing this.

I tried testing this on 8.x-1.1 and never could get an uninstall to delete ALL blocks, like stated in other comments by others. I did however, get it to delete any blocks that were added to a block visibility group. So, if i had one block added to a group, when i uninstalled the module, that single block was deleted (removed from the Block UI).

I did verify that after updating to 8.x-1.2, after uninstalling the module, that block was not deleted like it was with 8.x-1.1.

@joshua.boltz Thanks reporting back here!