This is a meta-issue for collecting the main tasks needed for implementing a working version of the Search API. Everyone familiar with the Search API, especially (but not only) development-wise, is encouraged to chime in, discuss the changes we should make and also propose others.

The upgrade can be divided into two categories: necessary changes, and optional changes. While the former are absolutely necessary to make the Search API compatible with D8, the latter are nice-to-have code changes which we might want to make now that we have the change to easily re-define our API.

Necessary changes

For the optional changes, see the child issues.

Especially people familiar with Drupal 8 and its changes are needed, but in general all developers (even new to D8) are more to welcome to help, there are tasks for all knowledge levels!

Regarding the inevitable question of whether the API/architecture changes will be backported to a new 7.x-2.x branch: I don't know. While having these advantages available in D7, too, would of course be a good thing, dealing with different, incompatible module branches and APIs is just a big pain for all extension modules. Probably most or all of them would have to create their own 2.x branch to stay compatible.
Also, kind of a killer argument, at the moment I have to be glad if I've even got enough time to complete the D8 upgrade in time. There's little chance I'll be able to simultaneously backport all API changes to D7.
So, let's see about that once the D8 version is working and in more or less good shape.

Files: 
CommentFileSizeAuthor
#2 variable_update.patch10.33 KBdrunken monkey

Comments

klausi’s picture

Proper unit tests with PHPunit and/or DrupalUnitTestBase please.

drunken monkey’s picture

StatusFileSize
new10.33 KB

Completely forgot to create an issue for it, but I just updated the variables to use the new systems.
Patch attached, if someone wants to review, but the changes are already committed.
(In case it's not obvious: I'm picking out the small easy tasks for now, since I'm much too scared of the Plugin API to tackle the major ones.)

drunken monkey’s picture

Anyone more familiar with D8, please see if you can help me with the question in #2044133-1: Support replacing the query class.

drunken monkey’s picture

Issue summary:View changes

Added note about 7.x-2.x branch.

drunken monkey’s picture

Issue summary:View changes

Added a list of name changes.

drunken monkey’s picture

To make it easier for other developers to keep track (if they want to help, or just update their own, dependent modules), I have added a list of all relevant class and interface name changes to the issue summary. I'll try to keep it up to date.

So, e.g., if you come across a reference to SearchApiQueryInterface in the code, you should change that to Drupal\search_api\Plugin\search_api\QueryInterface (that is, change it to QueryInterface and add use Drupal\search_api\Plugin\search_api\QueryInterface; at the top).

aspilicious’s picture

Core has changed the place were entities are stored, you should change your code accordingly. So in stead of Plugin/Core/Index it should be Index

drunken monkey’s picture

Thanks for the note, good to know!

drunken monkey’s picture

Issue summary:View changes

Removed superfluous "class" and "interface" strings.

drunken monkey’s picture

drunken monkey’s picture

Issue summary:View changes

Added two related issues.

freblasty’s picture

The usage of entity_load() needs some attention. Is there an existing issue for this? Some parts still use the Drupal 7 way of loading entities. As a result #2044093: Adapt menu entries to new Routing system results into WSOD unless fixed. I have a patch ready just need an issue :).

ianthomas_uk’s picture

drunken monkey’s picture

#2044119: Minor D8 changes might have been more appropriate, since it's largely just a change in arguments, but it doesn't really matter. Right now, things are pretty chaotic anyways, and I find getting things to work more important than documenting the changes correctly in the issue queue.

Also, right now I wouldn't be concerned about causing a WSoD, especially if it's just when viewing a certain page (and not for Drupal completely). If we can avoid it, great, but as long as we're moving in the right direction, it's not really an issue for me. After all, the module is useless at the moment anyways, so what does it matter if it gets a little more useless?

freblasty’s picture

I agree, but it's difficult to test #2044093: Adapt menu entries to new Routing system if the converted pages result in a WSoD :-)

drunken monkey’s picture

Fair point, of course.

drunken monkey’s picture

Issue summary:View changes

Changed the new namespaces for the index and server entities.

drunken monkey’s picture

Relevant for all our plugins, entities, etc.: Annotation based plugins don't need a use statement anymore.

drunken monkey’s picture

Issue summary:View changes

Added the »Add a flexible way for marking fields as "required"/"locked"« issue to the list.

drunken monkey’s picture

drunken monkey’s picture

drunken monkey’s picture

Issue summary:View changes

Removed the "optional changes" list, just reference this issue as the parent issue for those.

Also, there are three new issues: #2138843: Add more view modes support, even for content that is not an Entity, #2138839: Reduce the amount of code that unnecessarily relies on Drupal structure and #2138837: Add more flexibility in how we show data in an index.
I'm pretty sure the latter two are pretty minor, though, if they exist at all. We should definitely make sure to support external data as well as possible, but I think the basic framework already exists in our D7 version.

giorgio79’s picture

I found a strange bug with multi valued fields #2193723: Hierarchical multi value field - count is always 1. Now, that entity reference is in core, perhaps the module could handle these better :)

drunken monkey’s picture

Issue summary:View changes

Updated the issue summary with a link to the sandbox.

drunken monkey’s picture

A quick reminder here that proper development on this will (re-)start next Monday, with the Dev Days Szeged sprint. So if you have some discussion or thoughts to add, now's the time to do that. If you want to help, either be there in Szeged or follow the issues here to keep up to date and see where you could help. Being in IRC would probably help, too, some of the sprint attendees are bound to be there (maybe even me).

Something I would especially like feedback for is #2126979-1: Overhaul the "Multi-Index Searches" module, where I propose to let indexes have several item types, making combined site searches finally as easy as they should be. It would be a huge change, so I'd like to be pretty confident that it's the right choice before commiting to it.

drunken monkey’s picture

I guess we could/should also discuss the current rule of not being able to sort on fulltext or multi-valued fields: #2223659: Allow sorts on multi-valued and fulltext fields.

m1r1k’s picture

Issue summary:View changes
drunken monkey’s picture

Also to mention it here: during Dev Days Szeged, we are coordinating the porting effort in the #drupal-search-api IRC channel on Freenode.

ivanjaros’s picture

Hi guys. I need the elasticsearch module for D8. How's Search API services looking? When can I start to work on service provider(or help guys that made elasticearch for D7) ?

drunken monkey’s picture

We are currently hard at work in the sandbox (and its issue queue). You are more than welcome to give it a spin and maybe help out with the port. It's already improved a lot, but still not really usable. Also, I still expect a lot of API changes, so if you would start a port now, you would surely have to update it frequently until Search API 8.x becomes stable.
That being said, mollux is already working on porting the DB backend, so it surely can be done already. For now, there are only minor changes in the API, especially regarding service classes.

However, especially regarding Elastic Search, there might be a GSoC project doing this already, starting at the end of May (so very probably finished before Drupal 8 itself approaches release status.

drunken monkey’s picture

Issue summary:View changes

Removed the list of class renames, since it was so outdated it was more confusing than helpful.

drunken monkey’s picture

Issue summary:View changes

Updated issue text to reflect the current status (no more sandbox).

drunken monkey’s picture

A quick overview of our current status:

  • The code is now again in this project's repository, not in the sandbox.
  • The framework is basically working, but there are a lot of new features/improvements left to implement – and most of the Views integration.
  • I'm currently working on finalizing #2349435: Seperate filters/processors by stage (and fixing some current problems with the Filters form along the way), but am now going on vacation until about January 20 – so no work from me in that time. If someone wants to pick up the issue, that would be great.
  • Also very important to fix would be #2386357: Fix testbot failures, since that currently prevents us from having automated tests for D8 patches in the issue queue. Maybe upcoming Core changes will fix this, maybe more work will be required on our side (apart from fixing the really failing processor integration test).
  • But if you are interested in helping, you can also pick up any other issue in the queue. Just assign it to yourself and post if you have questions. For newcomers, the following will probably be the easiest options:
    • The patches that need to be ported from the Drupal 7 version of the module (see #2387007: [meta] Port patches from D7, where appropriate). These will usually not require too much knowledge and will serve as a good introduction into some parts of the module's D8 version.
    • Normally, bug reports will be much easier to implement than new features or tasks.
    • Especially for non-developers, reviewing the existing older issues in the D8 branch for whether they still apply, and whether patches (where present) fix the issue, would also be a great help.

If you have any questions, a good place to ask them (except for the issue queue, of course) is the #drupal-search-api IRC channel.

MickL’s picture

Your last post is 7 month ago, but the last update was 10 days ago, so whats the current status? :)

drunken monkey’s picture

Category:Task» Plan

More or less the same. ;)
The framework is basically working, but there are still a lot of architectural changes planned before we can release a stable version. Also, there hasn't really been any progress on the Views integration or any of the extension modules (except Solr and Attachments).

There are "Novice" issues (mostly just those that need to be ported from D7) for anyone who wants to help, as well as a lot of other issues for more experienced people (as said, bug reports will usually be easier to work on, and even help reproducing them or checking back with the creator would help).
Also, I'd be more than glad to help anyone who wants to help get started. Likewise, if you have a patch ready and I'm slow to look at it, please just ping me – in both cases, the #drupal-search-api IRC channel is probably the best place to do so (or use the contact form).

I'll be on vacation most of the time until Barcelona, so don't expect much progress until then, but there will be a week-long sprint again there (see and sign up here) so we'll probably get a lot closer to a stable version then.