Forum Replies Created
-
Posts
-
Hi!
The problem was, that the custom ajax handler was enabled. WPML is bound to load with specific back-end events (in some cases), and the custom ajax handler bypasses some of them, to achieve somewhat better performance. I’ve disabled it on the Compatibility settings panel, now the results will appear with the correct language.
Hi!
Most likely only by editing the corresponding theme part of the site (or by creating a child theme). Unfortunately each theme uses different ways of displaying the default search form, so there is no universal solution.
The search form used by your theme is usually in the searchform.php or search.php file in the theme directory. Try to place the php shortcode for the ajax search pro if you find the correct file.
You can include private details safely by editing your first post in this thread and filling out the proper form, or by uploading a txt file with the details. Both methods are safe and only visible for you (topic owner) and me (administrator).
Hi!
1. You have do deactivate the search in content, title, excerpt: https://i.imgur.com/gB6oRf0.png
2. Well, only with a modification to the code. The exact word match is implemented, but the “word beginning with” is not. So open up the wp-content/plugins/ajax-search-pro/includes/search/search_content.class.php file and go to lines 564-567 where you should see this:
[php] (".$pre_field.$wpdb->postmeta.".meta_value".$suf_field." LIKE $pre_like’% " . $word . " %’$suf_like
OR ".$pre_field.$wpdb->postmeta.".meta_value".$suf_field." LIKE $pre_like’" . $word . " %’$suf_like
OR ".$pre_field.$wpdb->postmeta.".meta_value".$suf_field." LIKE $pre_like’% " . $word . "’$suf_like
OR ".$pre_field.$wpdb->postmeta.".meta_value".$suf_field." = ‘" . $word . "’)";[/php]change those lines to this (so there is an extra line):
[php] (".$pre_field.$wpdb->postmeta.".meta_value".$suf_field." LIKE $pre_like’% " . $word . " %’$suf_like
OR ".$pre_field.$wpdb->postmeta.".meta_value".$suf_field." LIKE $pre_like’" . $word . " %’$suf_like
OR ".$pre_field.$wpdb->postmeta.".meta_value".$suf_field." LIKE $pre_like’% " . $word . "’$suf_like
OR ".$pre_field.$wpdb->postmeta.".meta_value".$suf_field." LIKE $pre_like’%" . $word . "’$suf_like
OR ".$pre_field.$wpdb->postmeta.".meta_value".$suf_field." = ‘" . $word . "’)";[/php]Then, you will have to change the search keyword logic to “Or with exact keyword matches” on the General Options -> Behavior panel: http://i.imgur.com/jvCImiI.png
Hi!
That’s how it should work by default. Was it working before or it didn’t work at all?
What type of content are you searching? (posts, pages, custom post types etc..?)Can you provide temporary ftp and admin access to check on this issue? I have no other reports of WPML issues, so I don’t know what could it be.
There is one known bug with the current version which affects a small percent of installations, but I don’t know if it could cause this. To make sure that bug is not present, please open up the Fulltext search options and save the settings without changing anything. Please let me know if it affects the problem in any ways.
Hi!
Make sure you copy pasted the code correctly, I don’t see an error in that code.
If you have temporary ftp and admin access to your site I can check the origin of the error if you want.
Hi!
The results page (redirected from the more results link) results count is a bit buggy right now. I have discovered a problem with pagination and result numbers.
The ajax results are limited to 10 by default, to maintain better performance, but the theme results page should display as many results as possible (which is right now not working correctly).
The new version is very close to a release, which will include a solution to this issue.
Hi!
I somehow missed your ticket entirely, I’m very sorry about that. I don’t have access to that theme unfortunately, but if you have a site url, I might be able to check the problem.
Based on your description I’m suspecting a padding issue. Try this custom CSS code, it might help:
[code].proinput input {
padding: 0 !important;
}[/code]Hi!
I think you are looking for this knowledgebase article: https://wp-dreams.com/knowledge-base/numbering-the-results/
Hi!
That’s what I needed to know. This is happening when the search parameter is parsed back to the input field if the “s” get variable is set.
Let me do some tests on how this is passed towards the database in this case. I’ll also suggest a temporary fix when I’m done.
Hi!
The fulltext search was enabled by accident, it doesn’t work with numbers. I’ve turned it off, it should show the associated posts as well now.
Hi!
You haven’t selected any taxonomies to return (in your case project categories). You can enable search in terms on the General Options -> Sources 2 panel, and select the taxonomy you would like to search as well.
For the recruitment I can’t see any published posts, only private ones. Private state is not a default in wordpress, thus the plugin does not recognize it. Do you also want to search in private posts as well?
Hi!
May I ask which wordpress version are you using? I’ve been testing the search for hundreds of cases of injection and XSS codes, but I wasn’t able to get anything.
I’ve tried the phrase you said, but it doesn’t do the same for me. All terms are filtered with the $wpdb->esc_like() call, so the query is passed on to the wordpress database layer for further checks.
Some previous (4.0) versions of wordpress had some troubles escaping these kind of statements, but as far as I know, there is no known security flaw in the current wp version.
All you did was entered was that snippet and the code just broke? Or did you enter this via the web inspector? Single or double quotes?
If you want I can check this on your server, maybe there is something different than on my test environment and demo servers. It looks like a front end issue due to the invalid input, which messes up the DOM tree. I couldn’t achieve it on chrome, maybe another browser. If you refresh the page then it’s gone, is it?
The database error is a good sign, it means that it’s not executed, thus the escaping was successful. It would be a bigger problem if this reached the statistics database un-escaped.
Let me know if I can check this on your server or the exact steps (including wp version, operating system, browser type and version) on how should I re-create the problem. I does not look like a security flaw, as the query is not executed, but it’s definitely worth investigating further.
Thank you for the notice!
Hi!
Thank you fro your kind words!
The first issue is related to the tabs javascript events. The plugin tries to calculate the correct width of the input field, but fails because it’s not visible by default. Luckily the fix is very easy. All you need to do is define a minimum width for the input fields with this custom CSS snippet:
[code].proinput {
min-width: 75% !important;
}
.proinput input {
min-width: 100%;
}[/code]That will solve the first issue immediately.
As for the second, the zip codes are custom taxonomy terms (not metadata) as I can see from the back-end. You selected to return these taxonomy terms as results. The reason why there is no image or description is because these taxonomies does not have any image or description – moreover it’s not supported by wordpress for taxonomy terms to have description or image.
I’m not sure if you want to return these taxonomy terms (zip codes) or the posts associated with these zip codes. But if you want to return zip codes, there won’t be any image or description, since it does not exist.If you want to return posts associated with these zip codes, you need to turn on the Search in terms? (categories, tags) option on the general options panel.
The layout is controlled by the theme. It’s basically a category (or tag) view, since the zip codes are terms. I’m not sure which theme part controls this layout exactly.
