[Policy, no patch] Move Search module to contrib

This seems like a bad idea to me. The functionality of this module seems pretty essential for Drupal core to have a minimal feature set.

Something like search API module is much too complex to set up and maintain if you want just a basic content search to work.

Clearly the code could use some continued adapting to be more OO, but I don't think it has a high maintenance burden?

@pwolanin

Something like search API module is much too complex to set up and maintain if you want just a basic content search to work.

The idea is that once #3467764: Specification document for Advanced search in Drupal CMS is available in Drupal CMS (and once Drupal CMS is stable), then Drupal CMS will provide a pre-configured search recipe using search API and that would be the default search experience for most new users.

Drupal core won't have the standard profile any more (or not in its current form anyway), so then it becomes confusing having a search module that's not enabled in core by default and is completely replaced by Drupal CMS.

It's true that search API configuration is pretty complex, but you end up doing that anyway once you need something that core search doesn't provide out of the box, so as long as the Drupal CMS recipe gets people started sufficiently, then it should be a better situation than now.

@catch - that sounds like a lot of thing that may not come to pass.

Also - if I'm building a data-oriented web app, I don't think I'd start from Drupal CMS, and I think there needs to still be consideration for all the use cases that want to start from a reasonably fully functional Drupal core.

So, at the very least this issue sounds premature until the Drupal CMS being stable with a good search_api recipe is implemented. At that point, it sounds like the only concern is around user confusion?

So, at the very least this issue sounds premature until the Drupal CMS being stable with a good search_api recipe is implemented. At that point, it sounds like the only concern is around user confusion?

This is where we are now, Drupal CMS 1.0 was released and it includes Search API with a good setup.
I'm not sure how much continued adaption it requires from people building on top of Drupal CMS, but I hope it is minimal.

Sorry, this is not a good idea.
Core still needs to ship with a built-in search system. A CMS without out-of-the-box search isn’t complete, and offloading that to contrib creates gaps for smaller sites, intranets, low-budget builds, and any installation that expects basic functionality without extra setup.

Search API is excellent, but it’s optional. Not every project needs external servers, custom indexing, or the overhead of a full search suite. Many sites just need simple search that works immediately after installation. Removing core search forces everyone regardless of their requirements into a more complex path and breaks the promise that Drupal Core provides baseline functionality for common CMS needs.

Improving core search is fair discussion. Removing it isn’t. Core should continue to provide a minimal, dependable search feature so Drupal remains usable out of the box for all project sizes.

Drupal core's search is very underpowered.

Drupal CMS is stable and it provides a search-specific recipe (Drupal CMS Search) which you can apply to any Drupal site (you don't need to be using Drupal CMS in order to use its recipes). It will set up Search API for you with reasonable defaults. No external server needed; it uses Search API's database-backed index. And it just works, immediately after you apply it, and the extra power and capabilities of Search API are available if you need them.

When a turnkey solution like that is available, and included in the default download of Drupal (i.e., Drupal CMS), I don't see much value in core providing a less powerful, barely maintained search feature that I'm not certain has seen active development in quite some time.

So, +1 on moving core Search into contrib.

For all its deficiencies, search is part of core. The big question is should core include search, to most that would be an overwhelmingly yes.
If searchAPI is swapped with current module, thats a fair trade.

Drupal CMS is bloated and I won't use it to build any sites.

Drupal core needs to ship with Search. And Search should be enhanced, not removed.

@xmacinfo - when you build sites, do you use search module or search_api?

Depending on the sites I build, 50 % the Core Search module and 50% Search API.

This was discussed at a meeting of the Core Leadership team at DrupalCon Barcelona 2024. Those present agreed to the removing the search module from core and moving it to contrib. The product managers were not able to attend so tagging for their review.

Responding as a Drupal core product manager. I believe we discussed this on prior Drupal core leadership meetings too and product managers there agreed. I don't believe core search is a fundamental ecosystem module that various contributed modules build on or contributed modules need to integrate with to be consistent. It could easily be a contributed module that people add. In fact that would make it easier to do what @xmacinfo hopes, that it could be enhanced with more flexibility and a more dynamic timeline than core. If there are interested folks that is to maintain it there :) There are various other key modules and tools that are not in core but immensely useful on simple sites too such as pathauto or drush, so I think a feature being historically in core is not by itself an argument to keep it in core.

a feature being historically in core is not by itself an argument to keep it in core.

Let’s remove the Announcement (announcements_feed) module.

This is not related to Search, but the Announcement can be removed without any issue at all. 😀

Feel free to open a different issue to discuss removing the announcements module from core.

Adding some additional perspective to what Gábor shared.

The reason behind this proposal is a broader strategy shift in how we're thinking about Drupal core versus the ecosystem. Previously, the thinking was that Drupal core should provide turnkey solutions for all common CMS needs. In practice, this approach hasn't served users as well as we'd hoped because core solutions have ended up competing with more capable contrib alternatives. When users eventually need capabilities that core doesn't provide, they face a migration to the contrib solution. Making the contrib solutions easy to adopt and getting users to adopt them from the beginning would put users on a better path from day one.

This isn't a statement that Drupal doesn't need the search module. It's a question of where that functionality belongs. The criteria we're using is whether something is a foundational capability that contrib needs to extend and integrate with, or a baseline expectation that doesn't face significant competition from contrib because core already handles it well. I don't think the search module fits these criteria.

The usage data supports this too. Looking at modules enabled in Standard profile, search has the second-lowest adoption at 60.5% (#3158669-49: [Policy] By default deprecate non-experimental modules that are used by less 5% of sites before the next major version), only announcements feed is lower. For comparison, most Standard modules sit above 80%. This suggests users are actively choosing to disable core search, likely because they're replacing it with Search API or not using search at all.

I understand the instinct that "a CMS should ship with search", but I'd reframe that as "a CMS should make it easy to have good search". Ideally, we'd have a powerful search capability that's as easy to set up as core search is today. Convergence between Search API and the search module would be wonderful, but that's unlikely to happen while search remains in core with its current constraints. Moving search to contrib might actually create more space for that kind of evolution.

For users who don't want the full Drupal CMS package, the Drupal CMS Search recipe can be applied to any Drupal site independently. This provides a pre-configured Search API setup without requiring adoption of Drupal CMS as a whole.

One extra thing to add on top of #19 is that search_api has approximately 140,000 installs reporting back to d.o https://www.drupal.org/project/usage/search_api

This is despite search module being in core. For token and pathauto and other contrib modules with higher usage than search_api, they extend core functionality or add completely new functionality rather than competing with it. pathauto doesn't come with its own path alias system. admin_toolbar extends the toolbar module rather than fully replacing it from the ground up.

With search_api module, it did not really start as a fork/replacement of core search as such, but as a way to consolidate the alternatives to core search module that already existed in contrib such as https://www.drupal.org/project/apachesolr or https://www.drupal.org/project/xapian. Even if they extended search module, they had to re-implement a lot due to the lack of pluggable backends and tight coupling to modules like node, which is still in there now. Note I don't know first hand the origin story of search_api but that's how I understand the timeline.

It is not impossible that we could decide to move search_api into core at a later date too, but the change with Drupal CMS is that for Drupal 7 and most of Drupal 8 and 9, we only ever had a choice of moving something from core to contrib with no replacement, or getting the replacement into core first; and then only after that, moving the core module to contrib (which is still the process we're following with Toolbar vs. Navigation). With Drupal CMS brand new Drupal users get something that works out of the box, experienced but very low-code people can use the recipes individually or install and configure contrib modules with more background knowledge, developers pick what they want to use anyway.

Moving search_api into core would be a large undertaking which hasn't even been discussed in depth anywhere that I can remember, so that could be a good 2-3 years to move search_api into core (e.g. if we wanted instant search configuration on install, which could require a UI for installing recipes in core, then it all spirals from there), then another year or two after that to move search module to contrib, taking us probably past 2030.

Even if we decided to move search_api into core tomorrow, if we didn't couple the removal of search module to it, it would still shorten that timeline by a year or two because they two things could be done in parallel, instead of one only strictly after the other becomes stable in core.

The result of the Drupal 7-9ish approach was not that every core module got continually better because everyone spent their effort improving them, but that several of them stagnated for years, while the people interested in that area worked on similar contrib modules instead.

For a different example, I have spent nearly 18 years so far trying to get 'access rules' fully removed from core.

I opened #228594: UMN Usability: split access rules into an optional module in 2008 after UMN Usability testing participants got very confused, going to 'access rules' expecting to find permission/roles, and not a ban list.

#1570102: [Policy] Deprecate Ban module was opened in 2012 and decided in 2024.

#3482198: [meta] Tasks to deprecate the Ban module can only fully be completed in Drupal 12 in 2026. Since Drupal 11 will be supported until c. 2028, it will actually have taken 20 years by the time it's done.

The removal of Ban module (finally!) is largely because Drupal CMS used a completely different suite of contrib modules for its anti-spam recipe and didn't use Ban at all.

I don't think people have the same affection for Ban module as they do for Search module (which actually works really well, it's just hard to customise), but the ability to move things out of, and into, core without having to maintain duplicate feature sets in core for potentially years really helps a lot, and then it allows us to concentrate on the things in core that genuinely do really need to be in there.

#3482198: [meta] Tasks to deprecate the Ban module can only fully be completed in Drupal 12 in 2026.

Will Search follow the same track and be fully deprecated with Drupal 12 in 2026 or Drupal 13 in 202x? If the target is Drupal 12, how confident are we that this target can be met?

What will be the recommendations to replace Search? Not an exact replacement since 140,000 sites never used Search and installed Search API instead.

I understand the reasoning for removing Search, I just expected to have it replaced by something else in core.

Fortunately, on some sites, Views keyword search is sufficient. Maybe Views can have a better keyword search functionality.

What will be the recommendations to replace Search?

The recommendation for existing sites with search module would be to install the search contrib module.

Will Search follow the same track and be fully deprecated with Drupal 12 in 2026 or Drupal 13 in 202x? If the target is Drupal 12, how confident are we that this target can be met?

Drupal 12 if it all happens in time, Drupal 13 if it doesn't.

Curious about where the HelpSearch and all related logic to search in help topics should be placed?

Reading through the more recent comments, I don't have any strong-enough arguments to hold up this decision.

I hadn't known about HelpSearch, so thanks andypost. This does seems like a place where moving core search to contrib could result in a loss? It doesn't look like anything in core implements HelpSearchInterface. What contrib modules implement it?

I do wish we had a middle ground between core with a heavy process and sometimes intense 3rd party review review, and contrib with sometimes no process and only self review. Especially for modules/themes moved out of core it would be nice if we made sure the next series of releases were not harmful or disruptive to existing users.

So instead of plainly moving Search to contrib, we may need to refactor the Search module itself and create one or more view.

/search/node
Move a scaled down version of the Search module to contrib, where it would initially deal only with nodes.

/search/help
Move all the help search code to the help module, including indexing the help content.

/search/users
Transform to a view with an exposed filter. But that would not support expression.

> Curious about where the HelpSearch and all related logic to search in help topics should be placed?

The docs in HelpSearch say:

 * Help items are indexed if their HelpSection plugin implements
 * \Drupal\help\HelpSearchInterface.

but a search for this shows nothing - no interface, no implementations. Does this even work at all?

I bet help search is not used by contrib but it's wired into some tests like #3144933: Add help_search plugin to the base admin theme test except the issues linked to https://www.drupal.org/node/3072984

Swap link text with href

Agreement to remove was reached months ago. Marking fixed.

How can this be fixed when the module has not been moved to contribute yet?

This is a [policy, no patch] / plan issue, not for doing the actual removal but to reach a decision.

The actual steps are at #3565780: [meta] Tasks to deprecate the Search module and many steps have already been done. Added to related issues.