Index table problem

This topic contains 42 replies, has 2 voices, and was last updated by

 
Participant
6 years, 2 months ago.

Viewing 15 posts - 16 through 30 (of 43 total)
  • Author
    Posts
  • #6100

    Participant

    Great, its working. Showed it to the boss and we noticed something strange in the logic.

    If we type a two word phrase, for example “head spot”, the search priotizes the”spot” word. Seeing that we have a lot of articles with “spot” in them we don’t see the searches with both words in them.

    I’ve tried this with the AND logic and the OR logic…no changes. Even selecting “Show exact matches only?” doesn’t change this.

    Anyway to give multiple word texts more weight than single words?

    #6101

    The index table engine calculates the priority based on word occurence. If the word spot is occured more times in the selected fields than the others the result is shown first. For multiple words the occurence values are added together. If seemingly the “spot” word is prioritized it’s because it’s most likely occuring more times for the given results along with the “head” word.

    With tens of thousands of results it’s even more complicated, because the logic determines the operation between each result set. Each result set is limited to a certain number based on an optimum calculation. The AND or OR logic only determines the connection between results sets for each keyword.

    After determining the results, the script orders them by relevance first which is calculated based on the upper mentioned occurence, then if there are results with equal relevance, secondary ordering is used, which is date by default.

    The exact matches will not work with the index table engine, it’s programatically impossible. (if you want I can explain why)

    The index table is an extremely complex thing to explain. It’s a very high performance focused construction. For basic pro-con list you can read the documentation if you want: https://wpdreams.gitbooks.io/ajax-search-pro-documentation/content/index_table.html

    The regular engine uses a bit more intuitive logic to calculate the relevance, but in your case I would not recommend using it. This is unfortunately not possible to implement with the index table engine.

    Best,
    Ernest Marcinko

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


    #6102

    There is one thing I can try though. I can increase the result set limits to a higher number, which might increase the probability of getting the desired results. Let me know if you want to try it 🙂

    Best,
    Ernest Marcinko

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


    #6103

    Sorry, I just checked and I lowered that for testing when you contacted me with the first issue and I forgot to revert it back. I changed it back to the default value. Can you please check if there is any change in results?

    I’m sorry about that.

    Best,
    Ernest Marcinko

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


    #6104

    Participant

    Hi, sorry for not getting back sooner. Its looks like its working much better, thx.

    #6140

    Participant

    Hi there, I’m transferring the plugin to our production site. I get the error about the sign “&” in the Url. Can you let me know how you fixed it before so i can reproduce on the production site?

    Thanks

    #6144

    Participant

    The accesses are the same if ever.

    #6148

    Participant

    Hi, really need the fix for “&” sign in the URL so i can reproduce on our production server today.

    Thanks.

    #6159

    Hi!

    Sorry, I had a business related stuff to take care of today.

    If you transfered over the exact files, the fix should be there. Just make sure that the Javascript Source is set to “Non Minified” on the Compatibility settings submenu. The transfer might have changed that back to the default value.

    The change I did was the following:

    – Open the wp-content/plugins/ajax-search-pro/js/nomin/jquery.ajaxsearchpro.js file
    – Then after line 72, which should be this:

                $this.lastSuccesfulPhrase = ''; // Holding the last phrase that returned results

    I added the following line:

                $this.o.redirect_url = $('<textarea />').html($this.o.redirect_url).text();

    I just checked via FTP, the line is there, so it’s probably only the compatibility option changed.

    Best,
    Ernest Marcinko

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


    #6160

    Participant

    Perfect, thanks a lot!!

    #6225

    Participant

    Hi there Ernest, hope you doing well today!

    We have encountered another problem and I haven’t found any help in the doc or on the site.

    The problem concerns WPML… got the chills yet? Apparently the results returned don’t take in account the language the site is in. So we get multiple results for the same product. You can see this with the following product: Roland HPi-50RW Educational Piano Rosewood

    Is there a way to sort the product by the language the site is currently in?

    Thanks once again!

    Shaun

    #6227

    Oh god, the WPML again. That plugin is going to haunt me in my dreams I swear.

    So I did some debugging, and it turns out, that the function provided by WPML support to get the language of the post by ID is not working, because why not. It was the last thing I was thinking of, I was looking for mistakes in my code, but apparently it’s not my fault this time. The internal WPML function was returning incorrect or no language information, which was later stored in the Ajax Search Pro index table.

    I googled around, and found a post by a WPML staff member to a function that will return the language information of a post. Turns out that does not work either. So after examining my test environment and the WPML database tables I came up with a (hopefully) working solution.

    I changed the index table code a good bit to implement this new function, which I hope is working correctly. I’ve already re-created the index table, so please test the search again. It should now return the results in the correct, current language as it supposed to do normally 🙂

    I hope this solution works, and I can implenent it to the upcoming version finally.

    Best,
    Ernest Marcinko

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


    #6230

    Participant

    Can’t live with it, can’t live without it!

    So far so good. Its looks like its working fine. Could you please let me know the changes you made so I can reproduce them on the production site?

    Thanks a lot,
    Shaun

    #6231

    Participant

    Oh nevermind, I found the changes. I will transfer and test

    #6288

    Participant

    Hi again,

    I’ve moved the files you modified, search_indexable.class.php and indictable.class.php, to the production server and then deleted the index table and recreated it. Unfortunately it did not work as well as on the staging server. Did you change anything else besides those 2 files?

    Thanks, Shaun

Viewing 15 posts - 16 through 30 (of 43 total)

You must be logged in to reply to this topic.