4.24 glitch

This topic contains 25 replies, has 2 voices, and was last updated by Ernest Marcinko Ernest Marcinko 1 year, 5 months ago.

Viewing 15 posts - 1 through 15 (of 26 total)
  • Author
    Posts
  • #40038
    Preet
    Preet
    Participant

    Hi there, I think the latest update 4.24 has changed some search behaviour
    https://www.loom.com/share/feac7a14dfa64f7988f65c198ffd5268

    Best wishes,

    #40056
    Ernest Marcinko
    Ernest Marcinko
    Keymaster

    Hi,

    Thank you for the detailed video!

    I cross checked the search query files, but there was no (significant) change in that area, so this issue is very likely linked to something else as well, but I can not replicate it.
    It is going to be something in the configuration + a change somewhere else in the code, but I don’t know where to look.

    Can you add temporary (s)FTP and back-end access? The only way I could get to this very quick is to first debug the old query and compare it to the new one with your specific configuration. There must be a difference in the query, and that will eventually lead me to the problem.

    Best,
    Ernest Marcinko

    If you like my products, don't forget to rate them on codecanyon :)


    #40057
    Preet
    Preet
    Participant

    I’m sorry, I can’t give access to a system with customer data. But I can dig it out for you.

    #40068
    Ernest Marcinko
    Ernest Marcinko
    Keymaster

    Is there any staging/test environment with test data or something I can check? I probably can’t debug this without actual access to the plugin files, it is quite complicated.

    Best,
    Ernest Marcinko

    If you like my products, don't forget to rate them on codecanyon :)


    #40073
    Preet
    Preet
    Participant

    I do have an environment that is free of customer data and based on the same framework. But unfortunately it only has a few dummy products, so not the same product set at all.

    #40075
    Preet
    Preet
    Participant

    Could I have the prior version before 4.24, as it is not easy for me to extract it from backups? That way we can be sure it was 4.24 that caused it.

    #40082
    Ernest Marcinko
    Ernest Marcinko
    Keymaster

    I’m sorry I can’t do that due to the platform security policy. Switching back and forth between versions without an actual rollback is a terrible idea anyways, as the data may get messed up and cause a fatal error.

    Can you please make an export of your search bar via the export options (settings only)? Then please upload as a .txt file to your next reply. I will try to replicate the same settings locally via the export to see if I can get any closer to the issue. Once I can replicate it, it’s a piece of cake.

    Best,
    Ernest Marcinko

    If you like my products, don't forget to rate them on codecanyon :)


    #40084
    Preet
    Preet
    Participant

    OK. Understood. I am also getting some other odd behaviour even with 4.22.5 installed so that may be it. I have updated back to 4.24. To be clear, we only noticed the results differences the day we updated to 4.24, but it is possible it was ocurring before.

    I have exported the public instance. I also have a second instance which is substituted for logged in users which should be identical except for additional members’ content. But other result differences have appeared.

    Thank you and I’m sorry about the restircted access.

    Attachments:
    You must be logged in to view attached files.
    #40086
    Preet
    Preet
    Participant

    Hi there, It seems to work better when not using the index table engine. Maybe that gives a clue.

    Also one thing that may not be helping is that minimum word length is 1. This is because we sell products such as Vitamin D.

    #40114
    Ernest Marcinko
    Ernest Marcinko
    Keymaster

    Perfect, thank you!

    I may have actually found something. The actual search query is exactly the same on both versions, I just compared, so luckily there is no massive search query problem, it is something with the arguments only.

    It is still very hard to track, but there is a possible problem of passing the search fields to the query, when using the regular vs. the index table engine – basically always the regular engine parameters were used in some cases.

    I made a patched version, and I am uploading it with this reply. Please install this one, clear all layers of cache and test again. I am not a 100% sure you will get the same exact results as in the previous version, but there should be a difference.

    Attachments:
    You must be logged in to view attached files.
    Best,
    Ernest Marcinko

    If you like my products, don't forget to rate them on codecanyon :)


    #40140
    Preet
    Preet
    Participant

    Genius! That has worked on “brain”, thank you.

    One thing I am still struggling on is results for “vitamin a” We do have one product with that in the title but it is not returned in the first page of results using the index table with or without inverted commas. In fact with inverted commas, it says: No results for “”vitamin a””, did you mean… vitamin a…?

    With regular search enabled it does appear in the first page only when in inverted commas.

    I suspect it may be related to the Minimum word length of 1 that I have set.

    #40142
    Ernest Marcinko
    Ernest Marcinko
    Keymaster

    Great!

    I think I may know what the problem is with that query too. The index table configuration is probably okay, but there is also a limit to ignore single characters within the search query. Can you pelase check minimum word length option and set it to 1 here: https://i.imgur.com/AgQcbLG.png
    That should deal with queries like vitamin a

    Quoted searches like “vitamin a” may still be an issue because of the index table limitation. The performance benefit comes from indexed queries, but those are only used whenever matches are on the start or the end of the keywords. Basically, when something is placed in quotes like “vitamin a”, it is considered as a single phrase. Then the plugin will try to match “vitamin a” against the start or the end of the database of singular keywords + the post titles. And there is the issue, because “vitamin a” does not actually match any singular keyword nor any title beginning or ending. It would match some post titles within, or whole category names, but remember that is not possible to execute for indexed queries.

    I can very likely improve this though. I think if the taxonomy term names would be indexed both as keywords and as whole it would be beneficial, and searches like “vitamin a” would very likely yield results as expected. I will see what I can do about that for todays upcoming release.

    Best,
    Ernest Marcinko

    If you like my products, don't forget to rate them on codecanyon :)


    #40147
    Preet
    Preet
    Participant

    OK. I already had that word length option set to 1. That would be brilliant. I have recently removed taxonomies from results because they were so unfocused and the products came too far down, but my business partner uses them a lot so is keen for them to be reinstated.

    I’ve set up a page with both available in case that helps. To be honest, there is some quite odd behaviour in the filters.
    https://naturedoc.shop/searches/

    Many thanks,
    Christopher

    #40196
    Ernest Marcinko
    Ernest Marcinko
    Keymaster

    The update 4.24.1 was released this weekend, if you update and re-index, you should see some improvements.

    Best,
    Ernest Marcinko

    If you like my products, don't forget to rate them on codecanyon :)


    #40224
    Preet
    Preet
    Participant

    Hi Ernest,

    This is now updated with 4.24.1, rebuilt index table, caches cleared:
    https://naturedoc.shop/searches/
    Trying to find this product https://naturedoc.shop/product/metabolics-vitamin-a-oil/
    For “vitamin a” in inverted commas it is perfect top result with the index table and good (no3) with the standard search.
    But without the inverted commas (which is how 99.9% of our users will search) it is nowhere to be seen on the index table and c. no20 on the standard.

    I have also added back the taxonomy sources and chnaged the logic to AND exact/AND which mitigates this a bit.

    I can see this is tricky!

    Many thanks for your help.

Viewing 15 posts - 1 through 15 (of 26 total)

You must be logged in to reply to this topic.