Site search for SKU

[mdius]

I am using the latest updated version of Community Store and Concrete CMS.

When searching using the core site search, you must have a complete word or phrase for it to show results for the SKU. Example: Search ULSM-10 The results are: https://www.mdius.com/search?search_paths%5B%5D=&query=ULSM-10

Now if you search only for ULSM The results are: https://www.mdius.com/search?search_paths%5B%5D=&query=ULSM

It does not show any results for ULSM-10.

As well searching for AS2OY10F0 Show's no results. It should show https://www.mdius.com/products/mini-mercury-hg-pilot-duty-control-float-switch-10-foot-normally-open-narrow-angle-skived-cord-ends

I have cleared cache and Reindex Content all 4 Objects (Pages, Files, User, & Express) and few different times. I've tried to Clear and Rebuild Index and I have tried not to clear and rebuild index.

Do you think this is this a weird Community Store issue or a core issue?

[Mesuva]

I've done a quick test on my local copy of Community Store and V9. I put in ULSM-10 as a SKU for a product, then ran the indexing task. Doing a search for ULSM or ULSM-10 brings up the same product page.

Looking at your two queries above, don't they return the same two pages? (they just highlight different bits of the content)

Why AS2OY10F0 is not returning a page is a bit of a mystery though. I'm wondering if it's because you have the product block within a global area for each product page, and maybe that's not being indexed? (and the reason other searches are working is that there are details in the meta data fields for the product page). That theory doesn't work for other products though, as I can do searches for specific little phrases in their descriptions and they come up in the search.

I'm wondering if the site indexing isn't completing in full. It might require looking directly at the search index in the database.

[mdius]

You asked: Looking at your two queries above, don't they return the same two pages? (they just highlight different bits of the content) Yes, you are correct, it does seem to. I was looking over a couple things.

As for the AS2OY10F0, what would I look for in the database? The test site does the same thing, so I would start with that.

[Mesuva]

The table name is PageSearchIndex, and you'd look in there for an extra with a cID value matching the ID of the product page. The content field should have the text the site's search is looking through (along with some other fields in this table)

[mdius]

/index.php/dashboard/store/products/edit/1502 So I would look for a cID of 1502, if so there is not 1. But I do notice these don't add up:

[Mesuva]

No, that's the product ID. The page ID is going to be the ID of the page that the product points to.

[mdius]

Edit: in PageSearchIndex bout half the content fields are empty and shouldn't be, they mostly relate to the store products. There should be no empty product content fields either.

So, if I do a a Reindex Content. Clear Index No Rebuild Index No Object to reindex Pages It hangs at 1994 / 2000. I'll let this try to finish overnight and see if it does. Going to try and see what happens tomorrow if I: Clear Index Yes Rebuild Index Yes Object to reindex Pages

[mdius]

Oh fun, no idea why, but when I run the Reindex Content I get the following errors a lot in my logs.

Messenger Worker Message Failed: /home/tinytown/public_html/updates/concrete-cms-9.2.0RC1/concrete/vendor/symfony/messenger/Middleware/HandleMessageMiddleware.php:130 Handling "Concrete\Core\Command\Batch\Command\HandleBatchMessageCommand" failed: Handling "Concrete\Core\Page\Command\ReindexPageTaskCommand" failed: Call to a member function getCollectionName() on null

Rejected message Concrete\Core\Command\Batch\Command\HandleBatchMessageCommand will be sent to the failure transport Symfony\Component\Messenger\Bridge\Doctrine\Transport\DoctrineSender.

So I'm guess in issue is some empty cName, which I found a few. Not sure what to do next though. On my test site, I deleted them with no difference at all. I'm sure I did not delete them in the proper way. But I wanted to try to see if it made a difference. So at this point it is no longer a community store issue, I'm sure of that. So I'll find a different route for help.

[Mesuva]

That error isn't going to be for an empty cName, I think that might be some sort of partially broken page. It's trying to index a page, but it can't actually find enough info in the database about it.

That might explain what you're seeing, in that the site overall is only being indexed partially.

I'm not sure if there's an easy fix for this, it might require someone to dig into the re-indexing and how that works.

[mdius]

Could it be the globalArea vs Area? I could try it if you think it could help. I just know I'll have to visit each and every page and make sure the block info is correct. Otherwise, do you think you could look at it? If not, I'll reach out to Nour.

[mdius]

A thought, I could delete the bad ones and re-add them I'll try it on my test site. It is obvious which they are.

[Mesuva]

I'm happy to take a look, but if you're already onto a theory, it's best to test that out first.

[mdius]

I tested 4 theories and your original comment GlobalArea vs Area, some products already have the Area blocks with default setting, some do not. This would make sense, it would scan the products with the Area block and the ones with only the GlobalArea block do not have any content. This is the problem, so I get to change it to Area and click every single product and fix the block. But at least I know the issue now. Apparently CMS 9 doesn't scan GlobalArea for content.