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.The title pretty much says it: move the search_api_solr module out of the contrib/ folder and into it's own d.o project. Since Solr isn't exactly the base use case, it probably shouldn't clutter the module list of people who don't want to use it.
I created this issue beforehand so anyone chancing upon this can post their thoughts on this.
Possible would also be a discussion of which other modules to move out into their own projects … Views, Facets, Pages, even all of them? Or are they useful enough (Facets without Solr … ?) to stay in the core project?
Comments welcome, otherwise I'll just extract it some time next week.
Comments
Comment #1
marvil07 CreditAttribution: marvil07 commentedBefore my opinion, I will just try to categorize the actual modules(this list is "name: description" from *.info files, ignoring "search api test" module) and provide a simple description of the categories.
Nothing really to mention about Main API :-p
Inside the modules that extend the main API, I can differenciate two types:
1. general: use the main API and provide a functionality. Search views and Search pages.
2. optional: assumes the module implementing the API implemented an optional feature at main API. Search facets.
API implementations use the API.
So, IMHO:
- General modules that extend the main API should stay here
- Search facets(and any new optional API feature module) should stay only if you think that it is easier to maintain it here(easier to sync code?).
- API implementations should not live here, the main reason for this is that I expect that people using this modules is going to use only one API implementation.
PS: but yeah, what you decide is ok :-)
Comment #2
drunken monkeyHm, you certainly got a point. Especially moving out facets would make sense, if people can't use it with some/most search backends anyways.
However, I'd keep the database backend in the main project simply because a) it doesn't need any additional infrastructure and b) people might wonder if they can't yet do anything after downloading and enabling the module. The database backend gives an easy starting point there. Moving it out would of course also make sense, as it just clutters the module list up for people not using that backend … Hm.
I'll think about it. In any case, the framework should handle the case when there are no service classes available (which it currently doesn't, as it seems). If we display an error message which also mentions the db backend (and where one can download it) as an easy starting point, maybe we can also avoid the potential WTF for new users while still keeping the main project slim.
Comment #3
fagoHm, dividing the project in what makes conceptually sense and in what makes sense for end-users is something different. I think it needs a mix of both.
I think keeping the DB impl in the main project is a good idea, as else the search_api isn't usable any more on its own. --> UX Having stuff like views and the pages in the main project makes sense to me, as I'd consider it "core functionality" for the module.
@facets:
>Especially moving out facets would make sense, if people can't use it with some/most search backends anyways.
Hm, I disagree. I'd see having facets as a rather critical part of the search API, thus it should be part of the main project. Ideally I'd like to see having the DB indexer implementing it too, but well we don't live in an ideal world.
@solr:
Having per search-service provide projects makes much sense to me, as a) often other people will work on it and b) it groups code together that belongs together and c) it can hold search-service specific add-ons built *above* the search api - e.g. mlt for solr, too.
Comment #4
drunken monkeyI've now just moved the Solr module to its own project.
If moving other parts becomes appropriate/necessary, we can do that later, too.
By the way, a new release of the module (and, of course, a first one for the new search_api_solr project) is coming up on Sunday or Monday. Would be great if some of you could look around for any major bugs that should be fixed until then (aside from the Views filter operator thing that just won't let itself be solved).