Forum Replies Created
-
Posts
-
Hm, this is going to be really hard without any access, but I still have ideas.
For starters, I’m attaching a slightly modified version of the plugin, which completely ignores these warnings. I’ve removed anything that can prompt for permissions.
Please uninstall the one you have currently, install this one and let me know what happens after activation.
Hi!
Just checking in, I didn’t forget about you, no worries 🙂 I’m still working on the update, so far it looks very promising. I completely reworked most of the queries, it’s almost done.
I will upload a test version for you once it’s safe for testing. (around 48 hours)
Hi Kristina!
Wow, I didn’t know it was possible yet. I know that plugin, but I didn’t know it had that feature, amazing. Thank you for telling me. I guess I was wrong 🙂
In that case if I may suggest turning off the override on ajax search pro. If it’s turned off I believe the search everything override will activate and display the comments on the search results page.
I will examine Search Everything, hopefully I can learn how to mix comments into the results list and implement a solution to the ajax search pro as well. I’m afraid I can’t give you a quick fix to that soon, it’s definitely much more complicated as category exclusions.Yes, exactly that – excluding comments from categories that have been excluded.
Today I have a bit of a peak of support requests, so you might have to wait until sometime tomorrow until I can fix this issue, I hope it’s not a problem.
Oh, sorry I forgot about the highlighter 🙂
There is a simple keyword highlighter implemented, you can enable it on the Layout Options -> Results Behavior panel: http://i.imgur.com/djOveqW.png
It’s not as clever as the one on amazon, but it should do the trick.
Thanks, it actually helps 🙂
Let’s try disabling the FTP credentials access prompt in the code first, and then we see what comes next. I’m guessing you have access to the files, if not please ask for FTP access, because we are going to change a few lines.
Once you have FTP access, open up the wp-content/plugins/ajax-search-pro/includes/compatibility.class.php file and go to lines 67-72, where you should see this:
[php]
$access_type = get_filesystem_method();
ob_start();
$creds = request_filesystem_credentials(site_url() . ‘/wp-admin/’, ”, false, false, null);
$_c = ob_get_clean();
if ($access_type === ‘direct’ || WP_Filesystem($creds))
return true;
[/php]simply disable those lines by commenting them like so:
[php]
/*$access_type = get_filesystem_method();
ob_start();
$creds = request_filesystem_credentials(site_url() . ‘/wp-admin/’, ”, false, false, null);
$_c = ob_get_clean();
if ($access_type === ‘direct’ || WP_Filesystem($creds))
return true;*/
[/php]or you can remove these lines if you prefer that way.
Now after saving, the FTP prompt should disappear and hopefully the plugin starts to work as normal.
Hi!
The plugin will work with those warnings without problems. There is a fallback method implemented if those directories are not accessible.
Putting FTP details into the wp-config.php file shouldn’t be a security concern, because the database access is also stored there as plain text – it’s a commonly used method with wordpress.The inaccessible front-end is not caused by the permission issues, I’m 99% sure. The screenshot didn’t get through for some reason, can you please re-attach it?
If there are any error messages that you can copy/paste here, that would help a lot as well.I believe we can still make it work despite the restrictions. If I can see any notifications, error messages, that I will be able to tell what’s the possible cause.
Hi!
From what I can see the Sticky Menu has an original and cloned container of itself on the same page. I’m guessing it basically uses the clone for when the sreen is scrolling.
There is a huge problem with that approach: it also clones ajax search pro as well. This is never going to work, as the javascript event handlers cannot be cloned. If you put any kind of javascript event driven element to that menu, it’s going to fail, it’s not exclusive to ajax search pro, nothing would work that way.I’ve looked at the code via FTP and the header is cloned via javascript, so there is nothing I can do about it. It is simply impossible to clone html element with the event handlers. Moreover it does not change the element IDs either, so there are multiple elements with the same ID, which is invalid HTML as well.
As a solution I would suggest not using javascript cloning in the header menu, instead simply creating the “clone” HTML in the header.php file and remove the javascript cloning completely. That way the same search shortcode would be used twice and it would work correctly. It’s also much faster and safer, and you would be able to use any kind of element in the header that uses javacript.
You are welcome 🙂
Well it’s not possible with the index table in sense of the performance. There is a MySQL behavior that the index table uses to gain performance. Basically the database can create so called “indexes” that are accessible at a very low cost in a very high speed. There are limitations however to use these indexes – especially when searching. The limitation is that you can only search from the beginning of the words. (the ending is solved by storing the reverse of the string in the same table). If you however decide to look for matches within the words then the database will not use these indexed values for fast access, since the foundation of the index is that the matching has to begin with the first character.
The reason why is it like this is roots in rather complicated math and binary trees and such.Basically the index table engine provides very precise matches at high speed but at the cost of not be able to search in the middle. The regular engine provides wider set of matches, but the relevance is much worse.
I can suggest a modification to be able to look in the “middle” of the indexed values, but I strongly recommend testing it before live usage. I have never tried that, and it might cause large performance peaks in the mysql process on your server.
Open up the wp-content/plugins/ajax-search-pro/includes/search/search_indextable.class.php file and scroll to line 564, which should be this:
[code]$like_query = "asp_index.term LIKE ‘".$word."%’";[/code]
change that line to:
[code]$like_query = "asp_index.term LIKE ‘%".$word."%’";[/code]
and that’s it. The index table engine now should be returning results even if it matches words in the middle.
Hi!
The problem with comments is that they are not custom post types (like posts, pages, products and so on) therefore they are a bit more problematic.
Unfortunately it is not possible to show them by clicking on the “More results” link. That url redirects to the theme default search page, which can only display posts, pages or custom post types – but not comments, users, terms. It’s not the plugins fault, nor the themes fault, it’s simply how WordPress is constructed at the moment. I’m not aware of any method to make this possible at the right now.
As for the categories, that might be possible actually. Currently it’s not implemented as it was never requested, and to be honest I never thought of it. But I think I might be able to do something about it.
Let me make try to implement this on my test environment, and I will let you know which file to replace to make it work.Hi!
The logical dilemma here is that unchecked categories are treated as exclusions. Therefore if any of the results for “lättläst” matches any of the unchecked categories, then of course it’s excluded.
However I think there might be an option to help you. By default all the term selectors are connected with kind of an AND logic. Therefore the plugin will look for items matching each term (category) not counting the missing terms – in other words no result can have an unchecked or excluded category or term.
There is however a different logic (OR) built in – which is more “loose”. It allows unchecked categories, but at least 1 category must match from the non excluded ones.
To change that logic, go to the General Options -> Behavior and change the Category/Term logic option to OR: http://i.imgur.com/0tDOp2m.pngHi!
You have two options I recommend:
1. Export the search instance from the live server and import it on localhost
2. ..or create a new one instead.The old import data has missing options, but if you export the one from the live server, it should work 🙂
Hi!
It appears it is a bug when the If no image found option is set to Don’t show that result on the Theme Options -> Isotopic results panel.
I have changed that option to “Show default image instead” and now it shows 13 results (one with the default image). The page calculation was incorrect because of that hidden item 🙂 The script only displyed 12, when there was actually 13 and calculated with 13 – so 2 pages were generated.It’s possible to increase the margin, which is actually a transparent border, with custom CSS snippet. For example to give 4 pixel margin on each side:
[html].isotopic .results .item {
border: 4px solid transparent !important;
}[/html]Well, maybe with a custom code it might be possible. Try adding this to the footer of the site, before the closing body tag:
[html]<script>
jQuery(function($) {
$(".asp-try a").get(0).click();
});
</script>
[/html]..this will click on the first keyword from the suggested list, which is the “Alle”.
Hi!
It’s because of the font type. If I change the font-family then it suddenly appears black. The current font-family is set to “Raleway”, which I guess is a much thinner font type or something, and it appears less opaque.
You can try a custom CSS to increase the font-weight, but I’m not sure if it would change anything. Something like:
[html].ajaxsearchpro * {
font-weight: 900 !important;
}
[/html]that code will force a thicker font weight to all elements within ajax search pro.
However if you are not attached to the “Raleway” font too much, I suggest changin the fonts to “Open Sans” or “PT Sans” instead. Those google fonts have a great support across desktop and mobile devices.
Hi!
“search “123” shows 30+ posts but the first results only contain 1 match while the target post has more then 45 matches and is shown 17th in the list”
The issue with the regular engine is, that it cannot count matches. For example a result with 100 matches in the content, and another with only 1 match in the content gets the same relevance. There is no way around it. Implementing a counting mechanism is not an option, since it’s extremely performance heavy operation in this case.
I strongly suggest to consider using the Index Table engine. It basically generates a database table with all the words in all the matching posts and fields. The great thing is however, that this solves the counting problem. Because it is a list of indexed keywords, it stores the occurences of each keyword in each field – so the calculation of the relevance is very precise.
Another great thing is that you won’t need that custom code, as keywords extracted from content or custom fields are treated equally on the database level. In the latest version of the plugin (4.6) I’ve added a few new options to the relevance panel, where it is now possible to adjust the Index table relevance values separately. I’ve also implemented an adjustable primary and a secondary ordering, to clear the smoke around relevance-data ordering problems.
