Home › Forums › Product Support Forums › Ajax Search Pro for WordPress Support › Index table problem
This topic contains 42 replies, has 2 voices, and was last updated by Shaun 7 years, 4 months ago.
- AuthorPosts
- October 2, 2015 at 5:03 pm #6100
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?
October 2, 2015 at 5:20 pm #6101The 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 :)
October 2, 2015 at 5:22 pm #6102There 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 :)
October 2, 2015 at 5:26 pm #6103Sorry, 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 :)
October 2, 2015 at 10:37 pm #6104Hi, sorry for not getting back sooner. Its looks like its working much better, thx.
October 6, 2015 at 9:36 am #6140Hi 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
October 6, 2015 at 1:39 pm #6144The accesses are the same if ever.
October 7, 2015 at 9:06 am #6148Hi, really need the fix for “&” sign in the URL so i can reproduce on our production server today.
Thanks.
October 7, 2015 at 1:50 pm #6159Hi!
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 :)
October 7, 2015 at 1:52 pm #6160Perfect, thanks a lot!!
October 14, 2015 at 10:03 am #6225Hi 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
October 14, 2015 at 11:38 am #6227Oh 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 :)
October 14, 2015 at 12:06 pm #6230Can’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,
ShaunOctober 14, 2015 at 12:50 pm #6231Oh nevermind, I found the changes. I will transfer and test
October 16, 2015 at 10:23 am #6288Hi 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
- AuthorPosts
You must be logged in to reply to this topic.