At Drupal Europe, I (Joris) guided a core conversation around getting Search API into Drupal Core. There were 2 main drivers for this.
The first driver behind this question were the factual numbers. Today, Search API has 30k installs for Drupal 8 and 70K installs for Drupal 7. Also, Search API is mainly maintained by 5 contributors, split between Search API, Search API Solr & Facets and some others. This bus factor is obviously high and is one of the concerns we would like to address.
Next to that, the current core search module has a few open issues with feature requests of things that already in Search API. There are loads of agencies that are using Search API to provide them with a good base for creating awesome search experiences. To decrease the community split between the 2 modules and to enable a more powerful solution out of the box, we could leverage some of the Search API code
There are different approaches we can take to resolve this problem. We can a do a very simple copy/paste of the module into the core directory, deprecate the current search and upload a patch. We don’t think that’s very likely to be given a green light, and doesn’t provide a transition path.
Another option to resolve that community split is to deprecate the current core search and point people wanting to create searches towards Search API. This is probably the easiest to do on a technical level. It would be a first for drupal core to point towards a contrib module (or contrib module ecosystem) as a solution for something. This unfortunately doesn’t solve the bus factor issue.
We could also copy the API bits of Search API into core and leverage them from Search API’s perspective, disregarding Drupal Core Search. This is bad, because it leaves the core search in the same state and only helps for the bus factor, but has no added value for anyone not using Search API.
The last solution we could think of, is to move parts of Search API that are stable, well-tested and uncontroversial to core and improve core search to work with them. We have to figure out which parts of Search API that is and what internal dependencies they have. When we do that, we can make current search better and decrease the surface of Search API. Eventually this hopefully means that we can keep the UI in contrib-land during the drupal 8 cycle, perhaps even for Drupal 9.
This is the solution that we (maintainers of Search API ecosystem) think is the path of least resistance towards improving the current state and benefits both problem-spaces that we are trying to resolve.
Usecases we are targeting to improve:
- Improve the current core search code by letting it use classes and components that are carried by more hands.
- Ensure the stability on the Search API ecosystem by handing parts off to core.
Usecases we are not targeting to improve:
- Improving the current search UX/HTML output
Sign-offs given:
None yet.
Meet the initiative team
- Joris: Doing the things (Facets maintainer)
- Thomas: Doing the rest of the things (Search API maintainer)
- Jimmy: Help with doing the things (Facets maintainer)
- Nick: Coordinating the things (Search API maintainer)
- Markus: Test the things with other backends (Search API Solr maintainer)
What exactly are we planning to do?
Parts that we propose can move from Search API to core:
- Tracking
- Indexing
These are parts of Search that can also be used by core and they are the most stable parts of Search API. They are small(er) and probably the least controversial bits. That doesn’t mean we don’t want the other components in there, but this makes this conversion lighter and easier to grok.
How we are working
Not yet, but you can find us in #search on drupal slack. That’s where the Search API team hangs out most of the time. Some of us are in the rocket chat (drupalchat.me#search)
As soon as this is approved, we will create issues for the parts we want to solve in the core issue queue.
How you can help
- Help define/confirm the path forward.
- Help write documentation/code for the new features.
- Help us understand the process on pushing this forward.
