Closed (fixed)
Project:
Block Visibility Groups
Version:
8.x-1.2
Component:
Code
Priority:
Major
Category:
Bug report
Assigned:
Unassigned
Issue tags:
Reporter:
Anonymous (not verified)
Created:
14 Mar 2018 at 10:27 UTC
Updated:
24 Aug 2022 at 03:54 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
Anonymous (not verified) commentedAlmare created an issue. See original summary.
Comment #2
arnaud-brugnon commentedI have the same issue
I agree that it is really annoying and i will never do it in normal case.
But in this case, like i want to uninstall this module, i have to edit block_visibility_groups_uninstall function.
If you remove those lines, you will be able to uninstall this module.
foreach ($blocks as $block) {
$conditions = $block->getVisibilityConditions();
if ($conditions->get('condition_group')) {
$conditions->removeInstanceId('condition_group');
$block->save();
}
}
Comment #3
vishalkhode commentedI added
hascondition to check if block has an instancecondition_group. You can apply this patch, this fixes issue.Comment #4
vishalkhode commentedComment #5
msankhala commented@visshu007 Thanks for the patch. I am not sure if this is a correct way to fix this uninstallation issue. I followed these steps to test this patch.
get()tohas()simply made this condition false and prevented this if block to execution.I think we need to understand why this
[error] Plugin ID 'condition_group' was not found.error is being thrown at first place.Moving this to Need work.
Comment #6
dadderley commentedThis was behaving badly and borked my block settings.
I could not uninstall this module. The patch in #3 allowed a clean uninstall.
Thanks
Comment #7
tedbowThis uninstall function was added in #2880373: Delete blocks on uninstall
It add test coverage in
\Drupal\block_visibility_groups\Tests\VisibilityTest::testSingleConditionsTo do a basic test on uninstall. The first step for this issue would be updating test coverage to demonstrate this problem.
A few questions:
bumping down to "Major" since the answers to these 3 questions would determine how it is critical.
Comment #8
jonathanshawI'm getting this while:
- starting with a a D8.3 or D8.4 prod database
- composer update for both core (to 8.5) and maybe this module
- drush updb
- drush cim (module is disabled in core.extension.yml therefore uninstalled on cim; config comes from D8.5 dev environment)
Comment #9
jonathanshawThe patch from #4 didn't suffice for me, as I still hit issues during the uninstall of this module when the route could not be detected by the redirect module's entity delete hook. The fix was to uninstall the module in the db prior to config import.
Comment #10
robshambaugh commentedThe uninstall patch in #3 worked for me for Drupal 8.5.5. Thanks!
Comment #11
robshambaugh commentedComment #12
mherchelThe patch in #3 worked for me, also running 8.5.5.
Comment #14
mlncn commentedCommitted #3 as reported working harm reduction. Leaving issue open for now as it's not clear it's the correct/sufficient fix.
Comment #15
mlncn commentedNo problems reported since the patch here and #2880373: Delete blocks on uninstall were released.