Partial word search for Drupal 7

works for me (linux, apache, mysql, drupal 6.13)

See #103548: Partial Search in Drupal Core - initially exactly the same issue, later moved further to certain techniques of providing this functionality (so the title is not so clear on first sight now). Although that issue seems to be moving a bit slowly, it's still the right place to discuss this IMO.

New features are not added to Drupal 6. You can participate in the issue mentioned by JirkaRybka or repurpose this for Drupal 7. Marking as won't fix based on the previous conversation. Feel free to reopen for Drupal 7 if you feel that is the better way to go.

I used this patch. It works.
(being new here, i guess I'm expected to say that here)

The issue mentioned in #2 is discussing doing this for Drupal 7.x/8.x. As noted in #4, we will not be adding new features such as this to Drupal 6. So I'm closing this issue as a duplicate of the issue mentioned in #2.

subscribing

#3: search.module.patch queued for re-testing.

Not that I want to revive an old thread or anything but this is how I fixed it using the core search module.

It seems people are having issues applying the patch so I manually changed the code in search.module as follows:

line 835: comment out $query2 = substr(str_repeat("i.word = '%s' OR ", count($arguments2)), 0, -4); and add: $query2 = substr(str_repeat("i.word like '%%%s%%' OR ", count($arguments2)), 0, -4);

line 861: comment out return array("d.data ". ($not ? 'NOT ' : '') ."LIKE '%% %s %%'", $num_new_scores, $num_valid_words); and add: return array("d.data ". ($not ? 'NOT ' : '') ."LIKE '%%%s%%'", $num_new_scores, $num_valid_words);

line 1188: comment out $boundary = '(?:(?<=['. PREG_CLASS_SEARCH_EXCLUDE . PREG_CLASS_CJK .'])|(?=['. PREG_CLASS_SEARCH_EXCLUDE . PREG_CLASS_CJK .']))'; and add: $boundary = '';

Obviously you could delete the old lines of code but I prefer to keep them there just in case. I've had great success with this, it's fast, and it doesn't appear to break anything. I'm running 6.20. My props to the original patch designer.

Confirming #12 works.

dshelton Thanks!!

Any idea why full phone numbers, with or without hyphens return results, however when searching for that same phone number with one or more numbers missing, there are no results? Has anyone else run into this?

It's because numbers are saved in the search index all munched together (without any punctuation). So 12/15/2012 and 12-15-2012 are both stored as 12152012 (for dates), and 678-43-2100 and 678.43.2100 and (678)43-2100 will all be stored as 678432100 (for phone numbers). And since partial words don't match, searching for 2100 would not match (for instance).

Thanks for the quick response! I've implemented the hack (ugh) so that partial search is working for words, however, partial search is not working for numbers. Any idea if there's somewhere in the module I can make a similar change to make numbers partial?

This is just for reference and is a solution similar to #12 but for drupal 7. (Note that it is a core hack)

Oops, here is the patch again rolled with git.

#19 works perfectly in Drupal 7.17. But it is indeed a core hack - so beware if you plan to update.

Thank you dshelton :) you really helped me!
#12 was the solution to my problem.
It workes fine in D 6.28
Only I changed your lines a little bit:

in line 835 eliminated the first two %-signs:
$query2 = substr(str_repeat("i.word like '%s%%' OR ", count($arguments2)), 0, -4);

line 861 eliminated the second blank:
return array("d.data ". ($not ? 'NOT ' : '') ."LIKE '%% %s%%'", $num_new_scores, $num_valid_words);

This way it worked quicker for me.

Would be possible to add patch #19 on Drupal 7, eventually with an option to enable/disable the feature?

@FiNeX:

I would like that but seeing as it is a feature request, I would think not.

However if it could get in D8 maybe people could be swayed to back port it.

There was another issue #103548: Partial Search in Drupal Core that was previously marked as won't fix for drupal 8, however that was for slightly different, more complex functionality.
I feel like just adding wildcards to the beginning and end of search terms or the search string would be a great thing for drupal core to have.
I have clients asking for it all the time (especially the clients with no budget who are using drupal core search).

Not sure if there is a current drupal 8 issue or not.

yes #19 works in D7, but: the matching word is not shown in "bold" in the result set; and it breaks something in "Faceted Navigation for Search" modules - which is not aware of any result. :(

@francoud:

Yes, Faceted Navigation for Search has it's own querying, which you would also have to modify in a similar fashion to the changes in this patch.

+1 for patch in comment #19 for D7. Still applies and works with current version.

We have used partial word search in D6 and D7 with patch to core for almost 8 years now.

It seems a natural requirement for even a basic search function and would be great to see it in drupal core. And as suggested for that to happen being a feature request it would need to start in the next cycle for Drupal 8.

This issue was closed as a duplicate of #103548: Partial Search in Drupal Core

However, comment #23 highlights that issue is different and more complex.

This issue is related to the other but should not be closed as a duplicate.

This issue was and can remain as an active feature request for Drupal 8.1.x

OK, I agree this is not the same as the n-gram approach.

But the patch in #19 would need considerable work before we would put it into Drupal core:

a) Tests.

b) We would need to check performance impact.

c) As noted above, it doesn't work with the highlighting of search terms, so that would need to be fixed.

d) Probably it should be an option rather than always on.

e) We should also think about this some more... Really this is not what people expect from searches. What they expect (from their experience with Google etc.) is that they get *relevant*, related similar words. Like if they search for "walk", they would expect to get results for "walked" and "walking" (linguistic stemming). But I don't think they expect that if they search for "cat" (meaning an animal) they end up with pages containing "category" or "concatenation" or "scatological", which this patch would return.

For reason (e) especially, my feeling is that neither this nor the n-gram search belongs in Core. However, it would be very easy for someone to make a contrib module for either one of them in Drupal 8 (in fact, I think the n-gram search module exists at least for 7). That would allow sites that want this functionality and all its implications (performance, etc.) to install the contrib module and sites that want to use linguistic stemming to install the appropriate contrib module for that (they do exist on drupal.org for several languages).

So ... why would we want to consider this for Core?

See also:
#487764: Allow wildcards like * in search
which is another approach to similar needs.

@jhodgdon Thanks for the detailed response and link to other issue for wildcards in search but there is no solution there yet.

c) As noted above, it doesn't work with the highlighting of search terms, so that would need to be fixed.

This may be related to #916086: search_excerpt() doesn't highlight words that are matched via search_simplify()

The question as to what do people expect from searches is at core of this issue.

The examples you give on searching google for cat is a good one.

Although with partial words searching for " cat " will give the results you want.

Nonetheless, in our experience many users need either partial word searches or porter stemmer approach (which is not good with multi-language sites) or both. In real life the core search is not adequate for many end users.

Nothing wrong with having the right contrib module.

I agree, some sites may want partial word search. I would highly encourage making a contrib module for this, the same as for fuzzy N-gram searching. The earliest it could get into Core at this point is 8.1.x, and Core is stricter about tests, coding standards, etc.... Meaning that it might not make it into core even then, if it's not up to standards, or if the Core maintainers decide it would be better to just do it in contrib anyway. So, if it starts now as a contrib module, site builders will have a way to add it to their sites now, and it can then be considered for core inclusion later.

Regarding the highlighting, fixing #916086: search_excerpt() doesn't highlight words that are matched via search_simplify() for Drupal 7 (it has been fixed for Drupal 8) will not make it work for partial words. It will definitely need additional work. (Trust me on that -- the patch on that issue makes it work for words that are matching due to search_simplify() stuff, but this is different.)

And regarding multilingual linguistic stemming... in Drupal 7, stemming was a problem for multilingual because the stemming modules run off hook_search_preprocess() and that did not have a $langcode parameter. In Drupal 8 that parameter has been added to the hook, so stemming modules should hopefully be able to run side-by-side in a multilingual site, each stemming content in their particular language.

@jhodgdon Thanks for the concise summaries of three items in one comment, each a brief paragraph.

I saw there was progress in D8 on multilingual stemming and limitations of D7 hooks. Not sure if a d7 backport is likely.

And the first paragraph on the process of getting features into core is helpful.

I agree, some sites may want partial word search. I would highly encourage making a contrib module for this, the same as for fuzzy N-gram searching. The earliest it could get into Core at this point is 8.1.x, and Core is stricter about tests, coding standards, etc....

If it were in core your earlier suggestion is good,

Probably it should be an option rather than always on.

It might also include a simple tip on searching full words only with quotes and spaces.

I think that a D7 backport of adding $langcode to the preprocess hook is not going to happen, because it would change the API that existing contrib modules are relying on.

Regarding search tips, people don't read help and tips as a general rule. They might seek them out if they got results they didn't want, but I think they'd be more likely to go Huh, what? and just think your site search is kind of useless if it is returning irrelevant results.

So... I guess I've already said this, but my gut feeling is that most people would be surprised by non-linguistic unrelated partial-word results -- so I think that by default, search shouldn't do that in Core. For this reason, I would be more supportive of the wildcard approach (#487764: Allow wildcards like * in search), where you only get partial-word matching if you explicitly put * into your search terms. Plus, that would be more flexible, allowing you to do things like ca*ion (having the wildcard in the middle, if that is what you want to search for).

ported patch to 8.

Just in case somebody will need, updated patch of #19 works in D7.53

Patch #41 still works wonderful. How can we proceed here? I think it is not possible to solve this in contrib via a hook? So what do you (and the core maintainers) think about an optional switch in core search configuration to enable partial word search?

Thank would be a great benefit for many many smaller pages where search_api is simply too big but the current full word implementation isn't powerful enough?

It's a small non-breaking change, so I don't see why not.
It could potentially even just be a variable you can set in settings.php if there is any push back against changing the UI.

Thank you for your feedback rooby. I guess the default behaviour could then stay as-is and we should add an option in cores search ui?

I'll do a new patch over the weekend and add some tests so it's got a better chance of being accepted.

Hello everyone,

Please see the following:

https://mymanthemaker.blogspot.com/2019/10/drupal-7-ubercart-7-partial-w...

I have over 30 proven upgrades, tweakes and fixes now documented to Drupal 7 / Ubercart 7 (and counting)

g.
----

Hi, I've stopped to hack Drupal core in order to solve this bug since a long time. I've adopted Search API with Solr/Elastic which is (IMO) a much better solution.

... just my 2cents :-(

Agree, I think we can CWF this for D7 as the functionality is available with Search API, you can use the database backend as well, so no need Solr/Elastic if you want to keep things a bit more simple, and the performance it pretty reasonable as well.

FWIW, the patch in #41 still works for those who want to use it.

Re-rolled patch for 9.3.

@j-vee Maybe your patch efforts for D9 should be directed to issue #103548: Partial Search in Drupal Core

Updated the title of this issue for more clarity that it is for Drupal 7.
Patch in #41 still applies to Drupal 7.84 and works well.

I am hiding the patch file in comment #50 because it is not for Drupal 7 and there is a separate issue for Drupal 9 #103548: Partial Search in Drupal Core