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.
D8 finally introduces a proper Plugin API in core, which we should therefore use for our own plugin types (processors, datasources, service classes).
Since I currently don't understand the D8 plugin system at all, and frequently start to hyperventilate when looking at corresponding code, I'll first have to read the documentation to get an idea of what we actually need to do here to make this work.
Comments
Comment #1
drunken monkey*cough*
Comment #2
freblasty CreditAttribution: freblasty commentedI'm willing to help and have been writing modules for Drupal 8 for a couple of weeks now.
Comment #3
jsacksick CreditAttribution: jsacksick commentedThe attached patch converts the service class to plugins. I didn't know what do with the query Interface so this will have to be fixed (The Interface isn't defined yet).
Comment #4
jsacksick CreditAttribution: jsacksick commentedSame patch without return; statements (Those were added during testing to avoid fatal errors).
Comment #5
drunken monkeyWow, quite a feat. Thanks a lot!
I just committed this for now, after scanning the patch. Hopefully I can then further work with it some time later this week. In any case, thanks again, you are really a great help here!
@ freblasty: Thanks a lot for also volunteering! What exactly did you want to help with, just answering questions or also coding yourself? In the latter case, you could take processors and turn them into plugins.
If you need more detailed instructions, maybe we can meet up in IRC or Skype in the next day to discuss the plan. But thanks in any case!
Comment #6
jsacksick CreditAttribution: jsacksick commentedHey, here's an initial patch that converts the processors to plugins. Looking at the code, I realized that somehow you decided to merge the concept of processors and data alterations callbacks, Is that true? I restricted the work to the actual processors.
Some of the processors are "broken" because of the call of non existing functions anymore... (e.g drupal_parse_info_format())
The data alterations callbacks haven't been touched. Same problem here with the DefaultQuery, I added the use statements but this will obviously be moved and change.
Furthermore, I'm wondering if the processors and some other concepts will stay in the actual form...
Comment #7
drunken monkeyYes, data alterations are being merged with processors, see #2044311: Change workflow plugin system.
However, at the moment it's probably enough to do a straight port of the processor plugin system, and later go and add the additional methods that previously belonged to data alterations. Until then, the former data alterations will just have to stay dysfunctional.
In any case, thanks again for this new patch, I just committed it! I'll probably re-join the fun mayself this weekend. ;) (There are 18 new issues to look at before that …)
However, I don't completely understand the problem with the queries. The interface is already defined as
Drupal\search_api\Plugin\search_api\QueryInterface
. Of course, it will be moved later to thePlugin\Type\Query
namespace (at least the way it looks right now) – you can either do that right away, or just use the old name and we'll refactor later. Easier than later replacing all the hard-coded references to the default implementation with the interface, only where appropriate.Incidentally, I'm a bit confused by these namespaces anyways, there doesn't really seem to be a unified guideline/standard for those. I'd have said the sub-namespace under
Plugin\Type
should definitely in some way contain a reference to our module – but it seems that this isn't the case. So, I guess it's fine this way.(Drupal 8 is in alpha and already I can't wait for Drupal 9 to come and fix this mess. ;))
If you want to create a query object, just use
search_api_query()
or$index->query()
, those should be the most future-proof ways.Comment #8
drunken monkeyI now adapted processors to use standard interfaces for some of their methods, so the
ProcessorInterface
now extendsConfigurablePluginInterface
,PluginFormInterface
andPluginInspectionInterface
. The index and options are now passed in the configuration array – I don't really know if the__construct()
method should stay in the interface, though. We definitely require it with a certain signature, but it doesn't seem to be defined anywhere else in core. Leaving it there for now, but this might change in the future.There is another interface,
ContextAwarePluginInterface
, which we might want to implement, but I don't really know how it would be used and whether we should do that. Blocks, e.g., leave it out, so I did the same for the moment.Comment #9
drunken monkeyComment #10
drunken monkeyComment #20
drunken monkey