When installing a site with config_installer or running `drush cim` on a broken installation site, I get this error:
Drupal\Component\Plugin\Exception\PluginNotFoundException: The "entity:break_lock:node" plugin does not exist. in [error]
/var/www/docroot/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php:52
From the stack trace, this basically starts from \Drupal\content_lock\EventSubscriber\SettingsSaveEventSubscriber:49:
if (empty($action)) {
$action = $this->entityTypeManager->getStorage('action')->create([
'id' => $type . '_break_lock_action',
'label' => 'Break lock ' . $type,
'plugin' => 'entity:break_lock:' . $type,
'type' => $type,
]);
$action->save();
The above block was introduced in #2938600: Add new Bulk Action to Break Lock.
The problem is that this early in the process, the node module is not yet installed and yet we try to install a plugin with a reference to node. The BreakLockDeriver does not return a plugin (since the node is not installed) and there is the above exception.
Now, I think that this should have been implemented as a config entity so that we can define dependencies. That's a big task and may not be worth it here, and I am thinking of other things.
I have a question as well: What happens when a new entity is defined after the module is installed? Is the action added in some other manner? I can't find any references to that in the code but didn't really look thoroughly.
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | 2941814-2.patch | 878 bytes | hussainweb |
Comments
Comment #2
hussainwebThis workaround works for me and at least gets the site install working. Of course, the problem with this is that we won't have the actions for breaking locks but it is certainly better than an exception on install. The workaround is just to run
drush cimagain after install is done.In the long term, either the settings should track dependencies and the module should handle them, or we should move to config entities where we get dependencies for free. Another thing we could do is hook into entity type creation and add the actions there as well.
For now, this patch helps us avoid the exception. :)
Comment #4
chr.fritschI have committed this for now until we found a better solution.
And I will leave that issue open
Comment #5
hussainweb@chr.fritsch, thanks. Any plans to mark a release soon?
Comment #6
chr.fritschJust created 😁
Comment #7
gngn commentedI know it's a quite old issue... but I stumbled upon it looking for a possibility to translate the "Break lock node" label.
I did not find a UI based solution for that - so I directly edited the 'label' in system.action.node_break_lock_action.yml.
Another way would be to add a new config/sync/language/de/system.action.node_break_lock_action.yml and edit this one.
But I can answer the question from @hussainweb in the description:
The code above is executed saving the settings form - so if you enable a new entity type for the first time a new action will be created.
Comment #8
smustgrave commentedQuestion is this relevant in 8.x-2.x?
Comment #9
smustgrave commentedComment #10
astonvictor commentedAs I can see patch #2 was committed to 8.x-2.x and changes from the patch exist in the 3.x branch. So, we can close the issue.
Comment #11
astonvictor commented