Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Posted by xjm
Problem/Motivation
This is a followup issue for #1871696: Convert block instances to configuration entities to resolve architectural issues.
Currently, the plugin system does not offer any consistent way to respond to changes in the derivative definition list. For example, when a custom menu is deleted, any menu blocks using that menu should also be deleted.
Proposed resolution
There are two possible resolutions:
- Each module that provides plugins is responsible for manually deleting the instances of those plugins that depend on removed derivative definitions. So, menu adds an
entity_delete_multiple('block', $ids)inmenu_delete(), custom_block adds something in $block->delete(), aggregator adds something in... uhm, yuck, aggregator_admin_remove_feed_submit()... - We add a systematic way for block plugins (and/or other plugins) to indicate what data should be cleaned up when, perhaps by providing a method on the derivative class, or a hook, or... something...
In either case, we need to review all the block plugins that provide derivatives and ensure that their respective modules are cleaning up their data, and that this has test coverage.
Remaining tasks
This issue is postponed on #1871696: Convert block instances to configuration entities to resolve architectural issues, which introduces some patterns for interaction between configuration entities and the plugin system.
Comments
Comment #1
sunDoesn't this apply to non-derivative plugin instances, too?
What are we going to do in update.php? In case a plugin ID needs to change?
IMHO, we need a global plugin manager (the plugin manager of all plugin managers) to handle global CRUD of plugin instances and to dispatch appropriate actions to child managers and other subsystems.
Comment #2
xjmWell, I believe non-derivative plugin instances only need to be ignored when the owner module is disabled (#1199946: Disabled modules are broken beyond repair so the "disable" functionality needs to be removed) or cleaned up when it is uninstalled (#1776830: [META-1] Installation and uninstallation of configuration provided by a module that belongs to another module's API), which are general problems outside the plugin system. The derivative definitions are implementation-specific, though, and depend on the owner module's API or even other modules' APIs, so either the individual modules should always have some code to handle this, or we need some systematic way of handling it for the plugin system and ConfigEntity.
Comment #3
xjmComment #4
xjmComment #4.0
xjmRemoving myself from the author field so that I can unfollow the issue. --xjm
Comment #5
XanoThis sounds like a follow-up of #2031859: Invoke an event[s] when a plugin ID disappears.
Comment #6
dawehnerWell yeah: this issue describes the bug and the other issue provides one possible solution for it.
Comment #9
tim.plunkettNot actively part of the Blocks-Layouts work.