Problem

If a widget set is renamed or deleted, no action is taken on the block (and block_node_type) tables. At the very least, this results in messy tables. At worst, if the block for the widget set was enabled when the set was renamed or deleted, you will get empty block output. I discovered this when I renamed my widget set, enabled the new block, and noticed some extra spacing above my widgets. A DOM inspection revealed the markup from the old block was still being output even though this block is no longer being handled by the module.

Solution

Ideal solution #1: The Block module should handle clean-up on non-custom blocks via _block_rehash() or some such. I'll bring this to them, but you know how it goes with core and, besides, there may be some reason I'm missing that they wouldn't want to do this.

Ideal solution #2: Maybe Widgets should handle the machine names for its widget sets in the same way that the Menu module does-- by not permitting them to change. Even though you can rename a menu, its machine name (and block delta) is permanent. One nice extra in handling things this way is that blocks wouldn't have to be reconfigured when a widget set is renamed. If there's some interest, I would do what I can do help implement it.

Quick and dirty solution: Create a clean-up function that is invoked from widgets_set_form_submit() and widgets_set_delete(). For now it would contain (yes, you guessed it):

if (db_table_exists('block')) {
  db_delete('block')
    ->condition('module', 'widgets')
    ->condition('delta', 's_' . $set['name'])
    ->execute();
}  
if (db_table_exists('block_node_type')) {
  db_delete('block_node_type')
    ->condition('module', 'widgets')
    ->condition('delta', 's_' . $set['name'])
    ->execute();
}  

This problem is far from critical, but it created a small headache for me today. Thoughts?

Cheers -