Drupal Association members fund grants that make connections all over the world.
The list of available plugins is not static, as the derivative system allows you to create a dynamic list of "subplugins"
based upon entities, configuration, content and what not. While this is a really nice feature it results in the fact that these
plugins might disappear.
One example: The menu module provides one block per menu. Once a menu is removed the corresponding block configuration should disappear itself. Once you are in contrib world, also the corresponding panels configuration should be cleaned up.
- Allow tell the plugin manager that a certain plugin ID is removed
- The plugin manager throws an event, which allows various subsystems to subscribe to that event.
User interface changes
Original report by @sdboyer
@dawehner pointed me to this code. that code deletes all block plugin instances that are based on a particular views block display when that display is removed. this is the outcome we want, but it's not the way to achieve it - even after that patch goes in., which made me realize that we're letting other code assume things about how block plugins get placed and used that they should not be assuming. specifically,
the problem is that any other system that might be wanting to create or manage block instances in its own way - like, say, how princess does right now - is left out in the cold. so, this behavior needs to be changed to invoke a hook with the ID of the disappearing block plugin, so that all block implementations can listen and update their datastructures accordingly.
moreover, that hook should have a flag that is used to indicate whether the disappearance of the block plugin identified by the provided ID is (more) permanent or temporary. e.g., deleting a view with a block display is a permanent deletion, but merely disabling the block display on that view is equally temporary (disabling a module is a tougher question, but the flag still helps us be more granular) this way, the hook implementations can potentially choose to 'stash' the created block instances in some way for the temporary case, rather than deleting it, which could be a big gotcha for users.
now, yes, the example i linked to above is within block.module, but that specific plugin's responsibility is to (ultimately) provide block plugins via a derivative - which means it's on the block-plugin-producing side of block.module's responsibility, not the block-instance-placing-and-management side. and keeping block plugins, or their producers, from assuming anything about block plugin instance storage, is the crux of this issue.
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] 80,028 pass(es), 722 fail(s), and 128 exception(s). View
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] 78,821 pass(es), 18 fail(s), and 159 exception(s). View
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 78,871 pass(es). View
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 77,735 pass(es). View