hesk3.4.6 knowledge base search problem feedback

[wanshili6]

Script URL: Private deployment
Version of script: Hesk 3.4.6()
Hosting company:
URL of phpinfo.php: Private deployment
URL of session_test.php: Private deployment
What terms did you try when SEARCHING for a solution:

Write your message below:
Hello, I am a Chinese user. I downloaded the latest 3.4.6 from the official website. After creating the knowledge base, I often cannot find content in the knowledge base. I also have similar problems when trying the official knowledge base. The search results are not accurate.
Another problem is that the template set in the background is not valid for anonymous users.

[Klemen]

Hesk uses MySQL's fullxtext search with all of it's pros and cons.

Your main problem is likely due to your hosting company having MySQL fulltext search ignore words of 3 or less characters.

For Chinese, you will need to ask your host to change ft_min_word_len system variable to 2 or 1, then rebuild indexes.
https://dev.mysql.com/doc/refman/8.4/en ... uning.html

The search will also improve greatly when you add a lot of articles into the knowledgebase.

Not sure what you mean with "the template set in the background is not valid for anonymous users." though, can you provide an example?

[wanshili6]

Hello, thanks for your answer!
The template is not valid for anonymous users, refer to the picture below. The template is only valid for logged-in users, and the question template is not displayed for anonymous users.

[Klemen]

This is a feature; the ticket templates are only available to Hesk staff.

If you need to populate the fields for customer side, you can generate custom links for them like this:
https://www.hesk.com/knowledgebase/index.php?article=83

[wanshili6]

Thank you, I'll try it.
---------------------
Regarding the knowledge base search, I tried to modify ft_min_word_len and ngram_token_size, setting them to 2, but it did not change the problem of inaccurate search results. I tested it and found that there should be a problem with the word segmentation retrieval of the query statement. The "subject" field and the "content" field of the "hesk_kb_articles" data table were not segmented. English words are separated by spaces, but Chinese words are not segmented by spaces, but are continuous unless punctuation is encountered. This guess was verified by my search test. When searching for a sentence in the full text, search results can be obtained, but deleting a character will not be able to search, even if only the last character is deleted.
I guess that we should start with the word segmentation of the database and segment the "subject" field and the "content" field of the "hesk_kb_articles" data table. I guess Chinese, Korean, and Japanese users must have the same problem, and other languages ​​that do not use the space bar as a word segmentation symbol may also have the same problem.
Although I guessed the reason, I am not a developer and I cannot improve Hesk. I hope you can fix this problem. I have seen similar feedback in the Chinese community in January 2023, but it has not been fixed. Please refer to https://dev.mysql.com/doc/refman/5.7/en ... earch.html

[Klemen]

Did you rebuild database indexes after changing ft_min_word_len variable? If not, MySQL still uses old indexes.

The should rebuild indexes if you use MyISAM tables (it is default in Hesk):

Code: Select all

REPAIR TABLE hesk_kb_articles QUICK;

Did you try ft_min_word_len set to 1? Does that improve anything (don't forget to rebuild indexes again)?

The Chinese, Japanese, and Korean text parsers mentioned in MySQL documentation are something that needs to be enabled on the MySQL side, not something that can be fixed in Hesk.

[wanshili6]

Hello, I tried to rebuild the cache, but it didn't work. Regarding what you said about changing the relevant settings in MySQL, I am not a developer, so I can't fix the problem. In the same MySQL settings, I have tested other ticket products, such as osticket, which can search Chinese normally, or other programs, which can also search Chinese normally. I guess this problem can be optimized by Hesk instead of asking users to search. Relatively speaking, Hesk is a very lightweight ticket with simple settings, but it is because of this problem that it cannot be put into use. I will refer to relevant information and try to solve it myself. Maybe it will be easier for you to fix this problem. If I find a way to fix this problem, I will share it with the community.