If you define a Display Extender plugin in a module and enable it, then uninstall that module, you are unable to load any pages. You get a "Drupal\Component\Plugin\Exception\PluginNotFoundException" error.
The same thing will occur if a module defines an input filter and then that module is uninstalled. If you go to a page with processed text using a format that filter was enabled in, then it will error out with a plugin not found exception.
While we can check uninstall requirements on a per-module basis, having core do this would make much more sense and prevent the dreaded WSOD as more modules get tried and uninstalled.
Simplest fix would be in DisplayPluginBase.php:165:
if ($plugin = $manager->createInstance($extender)) {
Change to:
if ($manager->hasDefinition($extender) && $plugin = $manager->createInstance($extender)) {
The other, more involved but possible better option would be to define a default fallback plugin for display extenders, and possibly any other Views plugins that can be defined and cause this problem.
What may be the best solution is to include these plugins, along with any others in the uninstall validator. Perhaps a new method in DefaultPluginManager (or even a trait for plugin managers to include) that allows each plugin manager to perform a check if it can be safely removed or not.
eg for the views handler:
public function uninstallRequirements($module_name) {
foreach ($definitions as $definition) {
if ($definition['provider'] == $module_name && $config->get('views.settings.display_extenders' . $definition['id'])) {
//Throw an exception or return an explanation of why this module can not be uninstalled.
}
}
}
For Filters it would have to loop through each formatter config entity and check if that filter is enabled.
Until this bug is fixed, any module implementing display extenders should implement hook_uninstall() to require removing dependencies on it from existing views.
Needs work
11.0 🔥
Last updated
There is consensus among core maintainers that this is a major issue. Only core committers should add this tag.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
There are several hundred sites that need to uninstall the views_ajax_get module in 10.1. It doesn't implement the hook_uninstall() workaround. Bumping to critical since this leaves sites hosed.
This bug prevents Gutenberg module from being uninstalled when using webprofiler module. See #3261040