Missing row plugin in views ui

OOH

Did maybe #2184951: Allow plugins to declare themselves a derivative caused that?

Maybe we should reset it so it will be loaded again automatically later?

I had the same issue and can confirm that the attached patch fixes the problem.

--- a/core/lib/Drupal/Core/Extension/ModuleHandler.php
+++ b/core/lib/Drupal/Core/Extension/ModuleHandler.php
@@ -611,6 +611,7 @@ public function install(array $module_list, $enable_dependencies = TRUE) {
// @todo install_begin_request() creates a container without a kernel.
if ($kernel = \Drupal::service('kernel', ContainerInterface::NULL_ON_INVALID_REFERENCE)) {
$kernel->updateModules($module_filenames, $module_filenames);
+ \Drupal::moduleHandler()->loadAll();
}

at least $this->loadAll() could be used instead. Have you tried to use $this->reset() to lazy do that loading?

Awesome work!

I don't understand, why are we removing the defaults? That wasn't really explained.

And there aren't any tests yet, so not RTBC.

Affects row plugins too #2217571: Cannot use Content row plugin in Views UI

I also created #2221037: Empty base plugin definitions overwrite derivative definitions when a plugin (annotation/id) is used as a derivative, which was just closed as a dupe of this.

One thing that issue does that this does not, is keep any other default values that the derivative doesn't populate. I think that is a better approach, as you are guaranteed more consistency between plugin definitions then? I was also talking to chx about this, the method I used in above issue means you could not override an empty value on your plugin annotation as the derivative definition would win in that case.

Or do we say if you are doing this, derivatives have to specify all their keys manually (which I think this does?).

Or do we let the defaults array on plugin managers handle that instead? Then the annotation classes are purely for documentation purposes really.

This is actually a missing row plugin but #2221503: Missing row plugin text in Views UI says 'style'. So closed issue from #16 was also correct in its naming. This is all the same thing :)

Here is the patch from #2221037: Empty base plugin definitions overwrite derivative definitions when a plugin (annotation/id) is used as a derivative. I think it makes more sense to try and fix this at the derivate level, rather than the plugin level. Like mentioned before, this means it is hard to override a value with an empty one. But will that case come up really? In that case, you just don't make it a derivative or something.

thoughts? olli?

+++ b/core/lib/Drupal/Component/Plugin/Discovery/DerivativeDiscoveryDecorator.php
@@ -90,7 +90,10 @@ protected function getDerivatives(array $base_plugin_definitions) {
-            $derivative_definition = $base_plugin_definitions[$plugin_id] + ($derivative_definition ?: array());
+            $filtered_base = array_filter($base_plugin_definitions[$plugin_id]);
+            $derivative_definition = $filtered_base + ($derivative_definition ?: array());
+            // Add back any empty keys that the derivative didn't have.
+            $derivative_definition += $base_plugin_definitions[$plugin_id];

I really really prefer this approach. +1

Yes! let's do that now. Added some unit test coverage too.

Cool!

Committed/pushed to 8.x, thanks!