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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

drunken monkey’s picture

Version: 7.x-1.x-dev » 8.x-1.x-dev

*cough*

freblasty’s picture

I'm willing to help and have been writing modules for Drupal 8 for a couple of weeks now.

jsacksick’s picture

Status: Active » Needs review
FileSize
37 KB

The 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).

jsacksick’s picture

Same patch without return; statements (Those were added during testing to avoid fatal errors).

drunken monkey’s picture

Status: Needs review » Active

Wow, 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!

jsacksick’s picture

Status: Active » Needs review
FileSize
50.54 KB

Hey, 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...

drunken monkey’s picture

Status: Needs review » Active

Yes, 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 the Plugin\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.

drunken monkey’s picture

I now adapted processors to use standard interfaces for some of their methods, so the ProcessorInterface now extends ConfigurablePluginInterface, PluginFormInterface and PluginInspectionInterface. 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.

drunken monkey’s picture

Issue summary: View changes
Parent issue: » #2044421: [meta] Upgrade to Drupal 8
drunken monkey’s picture

Status: Active » Fixed

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

The last submitted patch, 3: search_api-convert-services-to-plugins-2044077-2.patch, failed testing.

The last submitted patch, 3: search_api-convert-services-to-plugins-2044077-2.patch, failed testing.

The last submitted patch, 4: search_api-convert-services-to-plugins-2044077-4.patch, failed testing.

The last submitted patch, 4: search_api-convert-services-to-plugins-2044077-4.patch, failed testing.

The last submitted patch, 4: interdiff-2044077-3-4.patch, failed testing.

The last submitted patch, 4: interdiff-2044077-3-4.patch, failed testing.

Status: Closed (fixed) » Needs work

drunken monkey’s picture

Status: Needs work » Closed (fixed)