Suggestion issue fixed (#4175)

[esakkiraja100116]

1. @LHBL2003 was Identified the issue. When we give single special character, it does not provide any search result even that character is exists in the Bookstack.

• I checked MYSQL console for why it's happening like this. So I found for that exact query. Single \ we need to give four \\\. Then only it will consider like only one.

• Came back to the code

• $inputTerm = ($inputTerm == "\\") ? str_repeat($inputTerm, 2) : $inputTerm;

• Added condition for that backslash, then it worked.

2. Also, I noticed that I can't able to get the word called stack and the actual word was Bookstack. So I modified that query in PHP.

• $query->orWhere('term', 'like', $inputTerm. '%'); to $query->orWhere('term', 'like', "%$inputTerm%");

Finally, the issues are resolved 🎉

[LHBL2003]

@esakkiraja100116 Thanks for the error analysis.
Can you also find Server-123?
Because that's what we originally wanted to look for.
THX

[LHBL2003]

Because the words between the \ cannot be found either.

[ssddanbrown]

Thanks for offering this @esakkiraja100116. You're on the right lines but the PR code does not fix the issue at play here.
This only changes the behaviour when a single \ is a search term. This does not apply when the term is anything else (\Server for example in this case or something like \\a\).

Also, I noticed that I can't able to get the word called stack and the actual word was Bookstack. So I modified that query in PHP.

Yeah, the existing behaviour is intentional. Normal search terms are prefix-only match (at a term-level), not a full partial contains match. This is so database indexes can be used for most search operations.
We provide the "Exact Match" search terms (Which can be search upon "using quotes") which does a contains-based match against original text content (rather than our terms table).
I'd need you to revert that part before this got merged.

Some other things upon the above:

• Any logic applies to fix \ usage for normal search terms will also need to be applied for "Exact Match" search terms, Maybe also tag searches.
• Ideally we'd have tests added to cover the current scenarios this patches.
  • Existing search tests can be found in this file.

---

@esakkiraja100116 Finding Server-123 within the text \Server-123 is not something I'd look to address as part of your original issue or this PR (Thing there are existing other issues that somewhat cover that kind of scenario), but instead we'd focus on addressing backslash handling in general, so that you'd be able to find Server-123 within the text \Server-123 using exact match terms (Quoted) within BookStack.

[esakkiraja100116]

@esakkiraja100116 Thanks for the error analysis. Can you also find Server-123? Because that's what we originally wanted to look for. THX

As @ssddanbrown said we can able to filter the word using double quote like "Server-123" , and also I modified the PR code. So please check it. Here, we can filter using backslash \ and it does not apply for \\a\ .

But my concern is like something below

• When we filter use \. It needs to give this right \\a\ because \ is exists here.

[ssddanbrown]

Thanks for updating the PR @esakkiraja100116 but I think this is still not working as intended, now adding more issues. It now seems to be doubling the whole search term whenever it contains a \. Additionally, they where conditions are now overly complex, since you're performing prefix matches, negated prefix matches and contains matches.

Ultimately, I think the logic simply requires \ to be replaced with \\ before they're passed to the where query.
As per my previous comment, this likely also needs to be done for exact matches, and it would be good to have testing added to cover this scenario.

[esakkiraja100116]

Ultimately, I think the logic simply requires \ to be replaced with \\ before they're passed to the where query. As per my previous comment, this likely also needs to be done for exact matches, and it would be good to have testing added to cover this scenario.

• When I search for exact matches "\" . It does not provide any result. As per your previous comment now I replaced \ with \\ in our code.

• Thanks for you suggestion @ssddanbrown

[esakkiraja100116]

@ssddanbrown Have you checked my recent commit ?

• Let me know if I did anything wrong.

[ssddanbrown]

Thanks for updating the code again @esakkiraja100116.
I've now squashed and merged your commits within 78fecdf, before following it up with 23c35af to simplify the implementation, apply it to other search areas, and add testing coverage.

[esakkiraja100116]

Really happy to contribute with Book Stack and thanks for your guidance @ssddanbrown 🙏