[meta] Upgrade to Drupal 8

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

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

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

Added a list of name changes.

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

Thanks for the note, good to know!

Removed superfluous "class" and "interface" strings.

Added #2080791: Make data types into plugins and #2080799: Remove hook_search_api_item_type_info() as suggestions.

Added two related issues.

#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?

Fair point, of course.

Changed the new namespaces for the index and server entities.

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

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

Added #2126979: Overhaul the "Multi-Index Searches" module.

Added the optional tasks #2134799: Allow backend plugins to provide more specific feedback/information and #2134803: Add a "processing level" setting to search queries.

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.

Updated the issue summary with a link to the sandbox.

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.

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.

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

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.

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

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

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.

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.

We're down to the last few beta blockers and I think we can close this issue now.
I'm currently in the process of identifying the release targets and blockers.

Release blockers

We won't create a release candidate without these issues being resolved (either fixed or deemed stupid ideas after all).

Release targets

Issues that would be "nice to have" right from the first stable release, but which can also be implemented later (mostly). In other words, important issues that should still not block a release (candidate).

If you've got any issues still pending which you think would be good to get into the first RC, please bump them to bring them to my attention (in case I missed them).

Actually, I'd like to use this opportunity to point everyone willing to help to #2784849: Tests fail w/ out of memory error., where we could really use some help. It's a problem that lets tests fail consistently on PHP 5 test bots, but no-one has yet been able to reproduce it locally. Would be great if someone could finally manage that, or otherwise shed some light on the issue.

@ sachbearbeiter: We're in the Search API issue queue, no need to prefix the title.