Integration with the plugin project

1. +++ b/search_api.plugin_type.yml
   @@ -0,0 +1,19 @@
   +  label: Data source
   

   These labels are rather generic. This won't break anything at all, but may be slightly confusing in lists of plugins of different modules.

2. +++ b/search_api.plugin_type.yml
   @@ -0,0 +1,19 @@
   +  plugin_definition_decorator_class: \Drupal\plugin\PluginDefinition\ArrayPluginDefinitionDecorator
   

   Did you confirm your definition array keys can all be read by the decorator? If not, you may need to subclass the default decorator provided by Plugin. See Plugin's BlockPluginDefinitionDecorator for inspiration.

Seems to make sense, thanks!
If I understand this correctly, Plugin is more or less what Entity API was in D7, just for plugins? And while we're not using it in any way, this could still help other modules work with our plugins generically?
I'm all for that, of course, so thanks for the patch!

I only have to say that, in the Search API, we generally write "datasource", not "data source".
Apart from that, and Xano's comments above, of course, this looks good to me.

Do note that the core issue may not be finalized until 8.1, and by that time both Facets and Search API are final, and cannot change their schema names anymore, something that currently can (Facets is in dev) or can possibly (Search API is in alpha) still be done.

#2543420: Add schemas for core plugins' configuration should solve this. We need confirmation from Alex Pott and Gábor Hojtsy that such completely dynamic schema types do not come with any side effects.

Sorry, again not following: does your last comment mean we don't need to change our plugin schema type IDs after all, or, on the contrary, that we don't have to postpone on the Core patch and should just go ahead?

Although I can't really see the point of postponing on the Core patch in any case – changing our own schema type IDs can be done without any side effects anyways, I'd say, the YAML file also won't hurt anyone, and, as you point out in #6, sooner is better than later here.

I'd recommend changing them for consistency. If we can get this standard into core, we will no longer need the complexity that #2543420: Add schemas for core plugins' configuration introduces.

OK, then setting this back to "Needs work".

Looks good, thanks!
Just a few more tweaks, now it should be good to go.

Except: did you already confirm that the plugin definition decorator works for all our plugins out-of-the-box? Otherwise, I guess that still needs to be done before we can commit.

You're right, that does look like a good start. However, I see all the descriptions are missing, even though all our plugins, except data types, have them. So probably that would need some additional code?
Xano, can you shortly provide your input to this?

I dug through this and found that the descriptions are not displayed because of #2638076: ArrayPluginDefinitionDecorator should support descriptions. The UI works well with that patch applied. I expect the patch to pass all tests soon, and that it can be committed within the hour. When that happens, you should test using Plugin 8.x-2.x (I notice that the screenshots use a slightly older release or dev version).

Also note that plugin types and plugins can provide their own operations providers, which allows you to add links to the dropbuttons in these overviews. Currency does that, for instance, to provide its own plugin listings, and by adding configuration links for its plugin types (see screenshots).

#2638076: ArrayPluginDefinitionDecorator should support descriptions has been fixed. If you pull Plugin, the descriptions will be visible in the UI.

I tested the patch from #12 again and can confirm the descriptions show up. All plugins are also available as field types now (see screenshot).

Excellent, thanks a lot for testing yourself and confirming it works!
Committed.
Thanks again, everyone!

Datasources still use search_api.datasource.plugin.[%key] as their config schema. I expect that's not on purpose?

Committed.
Thanks!

It seems we missed the backend plugin when updating the schema keys? Or was that on purpose, for some reason?
Patch attached. (Will break the Solr backend, of course.)

OK, good.
Committed.