Shop search v2.1.0(statssearch) not write searched words in ps_statssearch table

[elly63]

Hi everyone,
I updated to PS 8.2;
the Shop Search 2.1.0 module, however, doesn't write the search terms to its table (ps_statssearch).
I've already tried uninstalling and reinstalling the module;
everything is fine, and the table is correctly created in the database;
however, the problem persists; it isn't populated when searching from the website's front end.
The back office also correctly reports in the statistics that no search terms were found, since the table is empty. For testing, I manually inserted a row into the ps_statssearch table, and the back office displays the entered data.
Any suggestions?

[El Patron]

This is a known issue after upgrading to PS 8.x — the search terms are often not logged because the hook that the statssearch module depends on is no longer fired, or the search controller is bypassing it.

Below are the main things to check.

1. Check that the module is hooked to actionSearch (critical)

The statssearch (Shop Search) module relies on this hook to write terms into ps_statssearch.

After the upgrade, it’s common for modules to lose hook assignments.

Ask the member to check:

Back office → Modules → Module Manager → Shop Search → Configure → “Exceptions & Hooks”

Make sure the module is attached to:

• actionSearch
• displayHeader (not required for logging, but sometimes needed)

If actionSearch is missing, add it manually.

Note; there are other reasons but this is the primary thing to look at first.

[elly63]

First,
thanks for the quick response.
Second,
I checked the SHOP SEARCH 2.1 module's hooks as you wrote, and
- the module is correctly connected to actionSearch.
- it cannot be connected to displayHeader, which doesn't appear in the list of available hooks (img 2).

Any other ideas?

[Andrei H]

Hello,

displayHead is not needed. The statssearch module makes use only of the actionSearch and displayAdminStatsModule hooks

Some things that you should watch for:

1. Check the `ps_hook` table and make sure that active is set to 1 for actionSearch. You can also add position 1 (to the same row) if it's not already set (SELECT * FROM `ps_hook` WHERE name = 'actionSearch';)

2. Make sure there are no overrides (or direct code changes) for controllers/front/listing/SearchController.php, src/Adapter/Search/SearchProductSearchProvider.php and modules/statssearch/statssearch.php. If there are, you should check the code for them in GitHub and make sure you are not touching the execution of the actionSearch hook

[elly63]

Hi Andrei,

To be safe, I downloaded 8.2 from GITHUB and replaced the folders
controllers/front/listing/
src/Adapter/Search/
modules/statssearch/ directly on the server.
I cleared the cache.
I ran a search from the front.
But nothing, no writing to the ps_statssearch table.
I'm attaching a screenshot of the BO where it seems that online users used to appear in addition to the 'active shopping carts'... maybe the problems are related.

thanks

[elly63]

...`ps_hook` table: active is set to 1 for actionSearch YES

... no overrides ...

Edited December 1 by elly63 (see edit history)

[Andrei H]

Hello,

Do you have any custom search modules installed? Or any module that implements the 'productSearchProvider' hook?

Can you try the following: go to classes/controller/ProductListingFrontController.php and on line 317, add the following code:

die(get_class($provider));

Then try and search something. When redirected to the search page, what are you seeing? Is it PrestaShop\PrestaShop\Adapter\Search\SearchProductSearchProvider?

[elly63]

[elly63]

[elly63]

and finally i see this

 

[elly63]

ps

in the faceted search module i replace

/modules/ps_facetedsearch/src/Hook/ProductSearch.php (line #54)

if ($query->getIdCategory()) {
with
if ($query->getIdCategory() || $query->getSearchString()) {
 

[elly63]

no sorry, the above change was undone with the update to 8.2.3

[Andrei H]

Hello,

Ok, this makes more sense now.

In your ps_facetedsearch module's configuration, in the template used, you are most likely having Search (experimental) checked in the Pages using this template: section.

The problem seems to be the fact that ps_facetedsearch does not execute the actionSearch hook. If you uncheck that option, the default search class will be used in the search page, and this class does implement the hook, so you should start seeing the search keywords inserted into that table.

Edited December 1 by Andrei H (see edit history)

[elly63]

Right, you're great,
but then I can't enable faceted search in the search results without losing the writing in the table?

[elly63]

..it even writes two lines for research now 🙂 it seems he has to make up for lost time

[Andrei H]

Hello,

Since this is experimental, you would expect things to be missing.

You can manually fix it for now. You can edit modules/ps_facetedsearch/src/Product/SearchProvider.php and on line 197 add the following:

\Hook::exec('actionSearch', [
    'searched_query' => $query->getSearchString(),
    'total' => $productsAndCount['count'],
    'expr' => $query->getSearchString(),
]);

If it's inserting things twice, this means the hook is called twice, although it shouldn't. Did you add it for debugging somewhere in the code and forgot to remove it?

[elly63]

a, I understand, it writes lines every time you add text and give it time to preview the results... I type cia, it previews the results under the search bar, then I add "o" and it previews the results again, and it writes both the line with "cia" and "ciao."
I don't know if I'm understandable, my English is googleenglish.

 

Tomorrow I'll test with the code you told me and I'll let you know... now I'm exhausted...

[elly63]

grazissimo ... A thousand thanks

[Andrei H]

Hello,

Oh, yes, that's how it was working in PrestaShop 1.7.x too. Both the preview and the search page will add entries to that table

Glad I could help

Edited December 1 by Andrei H (see edit history)

[elly63]

11 hours ago, Andrei H said:

Hello,

Since this is experimental, you would expect things to be missing.

You can manually fix it for now. You can edit modules/ps_facetedsearch/src/Product/SearchProvider.php and on line 197 add the following:

\Hook::exec('actionSearch', [
    'searched_query' => $query->getSearchString(),
    'total' => $productsAndCount['count'],
    'expr' => $query->getSearchString(),
]);

If it's inserting things twice, this means the hook is called twice, although it shouldn't. Did you add it for debugging somewhere in the code and forgot to remove it?

ok, it works👍...

Thanks again for the help

[elly63]

Hi,

We've solved the writing problem in the ps_statssearch table, but I have a few considerations:

- Between yesterday and today (24 hours), the table was populated with 5,000 rows.

- Of these 5,000, after running

DELETE FROM yourTableName WHERE yourColumnName IS NULL OR yourColumnName = '';

There are about 80 left.

Now I'm trying to

-modify statssearch.php with some if statements.

-or insert a 'before triggers' statement in mysql so that it doesn't write rows with the keywords ""

[Andrei H]

Hello,

That is weird. I tried added empty spaces in the search input and even search for that, but they are not inserted into the table

Does adding the following code at the top of the hookActionSearch method, in statsearch.php, fix the issue?

if (empty($params['expr'])) {
	return;
}

 

[elly63]

So,

I inserted the code and it seems to work.

Below are the images of the insertion and the DB with the blank lines before your change.

Now I'll run the site through a bit and see...   👍🤞

[elly63]

I also added

if (strlen($params['expr']) < 5) {
return;
}

to avoid strings under 5 characters that aren't meaningful for the site.

[elly63]

Hi,
Anyway, the code that writes ps_statssearch to the DB needs to be made smarter.
Yesterday I did a search on the site I manage, and when I searched for "testando" in the DB, 8 lines were written in 8 seconds... and thank goodness I included the strlen if on the var ...
I'm trying to implement some SQL triggers that will improve the situation...
Maybe someone more knowledgeable on GITHUB will be able to make the module smarter...

Ciao 😉