Forum Replies Created
-
Posts
-
Hi!
What do you mean by “only returning the term id”? Can you make a few screenshots how the results look like currently?
Are there any error messages visible by any chance?I have no idea where the problem is, the code looks fine to me. There must be something I’m not noticing.
Hi!
The more results problem was a simple misconfiguration. On the Layout Options -> Results Laoyut panel the ‘ Show more results..’ url option was set incorrectly, so I changed it to the default. It should display the correct ones now.
As for the search, I’m guessing you are talking about this one? http://i.imgur.com/kSPOkaV.png
In this case, the wrong widget is selected on the widgets area: http://i.imgur.com/qcCzcka.png
If you replace that with ajax search pro, then on every page where this widget area is active the ajax search pro should be visible.Hi!
Thanks for the feedback!
Based on your description it’s possible 2 things causing the problem:
1. The plugin is malfunctioning at some point and getting perhaps incorrect post IDs (or something related)
2. Or/And the theme search.php or some hook does some filtering of the results – which causes the empty pages and the pages with less than four results.Unfortunately it’s impossible for me to tell where the problem is exactly without debugging through the search code first and checking the theme search.php file as well. If you can add FTP access I will gladly take a look and suggest a fix if it’s possible.
Hi!
Please update to the latest version available (4.5.5) and try again. It should solve the problem.
Hi!
The reason why the plugin is not visible on other pages is because the shortcode is used only on that one page. The plugin cannot automatically place itself on pages, wordpress does not allow that yet.
I can recommend 2 possible solutions:
1. Use the Ajax search pro widget in the footer. Your theme most likely have footer widgetized areas. These widgetized areas are visible on the whole website usually. Use the search widget on one of these areas and it should be visible on the whole site.
2. Placing the search PHP shortcode directly to the active themes footer.php file. This solution works better, but it requires a bit of programming knowledge. On the demo page the compact shortcode is placed into the theme footer.php file just before the closing body tag: https://i.imgur.com/k7pzeXJ.png
In either cases, don’t forget to clear the cache and remove the shortcode from the baumkind.com/suche page editor, as it will be no longer required there.
Hi!
I still cannot find any FTP details provided though. I cannot check the code without FTP details.
The original thread url is this: https://wp-dreams.com/forums/topic/related-post-pro-and-ajax-search-pro-stopped-working/
You should get an email every time I’m posting information, if you click on the url in the email, it should take you to the correct page 🙂
I’m closing this ticket here, and we can continue the conversation in the original.
Thank you!
At least I see no errors, but the HAVING clause is what I think is the cause of the problem here (and maybe the number of keywords as well).
The term exclusion unfortunately has to do a left join, which breaks the indexing (wordpress is built this way).I’m working on 2 plugin updates right now, one is Ajax Search pro and one is Related Posts pro. I’m completely re-working this query structure to a much more optimized one based off of ajax search pro. I’m probably finishing ajax search pro today, it’s under final testing, then I’m continuing with related posts pro.
Right now, there is not much I can do, as not an error is causing the problem but the query structure. I’m going to inform you as soon as I get an optimization ready on this plugin and upload a pre-release version for further testing.
After the planned optimizations the query execution time should be reduced greatly. Once the queries are fully optimized we can see how it’s working and if any further configuration tweaks are needed.
That’s probably the problem there, it’s an extremely high amount to search for.
I would rather recommend using the Index Table engine for this purpose instead of the regular one: index table documentation
Even if you can make it work with the regular engine, the search query is going to be insanely big and it’s going to take forever to execute. (or might not be executed at all) It’s completely fine with a few custom fields, but for hundreds it’s not recommended.
The index table engine however takes care of this issue by pre-indexing the configured fields, so the final search queries are super fast and very efficient.
How many custom fields do you add? Maybe the field becomes too large.
It’s almost impossible to tell, because the error message does not tell the source of the issue. Let me know if you can somehow give me access to a test environment, and I gladly take a look.
Hi!
Make sure that the correct shortcode is used (with the correct search ID). Also, try re-saving the search options. The error might indicate missing options, but I’m not sure.
Can you provide temporary admin and FTP access so I can check on the issue?
Hi!
The plugin Flickr Set slideshows is causing the problem. It triggers the following error:
Uncaught TypeError: Cannot read property ‘length’ of undefined
in the following file: http://dev.tramasolutions.com/paliativos/wp-content/plugins/flickr-set-slideshows/flickr-set-slideshows.js?ver=4.3.1
line 82:
if ( $( ‘select[name=photoset] option:selected’ ).attr( ‘value’ ).length …
This code is executed on all of the back-end pages, so it might cause further issues as well. Unfortunately there is nothing I can do to ajax search pro to prevent this issue, it’s entirely caused by Flicker set slideshows.
Try temporary deactivating the slideshow plugin until you configure the search, but I recommend notifying the slideshow developer about this problem, as it may cause issues with other plugins/themes which use select drop-down boxes.
Hi!
Yes, that should fixed the https issue. The cause was the fact that when you save the search options, the CSS files are dynamically generated and the actual plugins_url() function result is used. At that time it returned the “http:” version. The site url was changed afterwards, but the stylesheets remained the old version. Once you de-activated the plugin these stylesheets are automatically re-generated. In case of any change it’s enough to save the search options, and the CSS files will be re-generated with the actual URL 🙂
What I noticed right now is that a blue hovering stuff appears when I focus the search input. It seems like the CSS fix I recommended is not sufficient. I’ve done some debugging and this worked for me:
[code]
.fixfixed {
position: static !important;
}
[/code]I’ve also noticed an independent javascript error which blocks further JS execution in one of your files, namely: https://naturalhealthchoices.com.au/wp-content/plugins/social-marketing/js/twitter.js
The line twttr.events.bind(‘tweet’, wdsm_twitter_callback); is causing a fatal error, the console reports that the twttr variable is not defined:
Uncaught ReferenceError: twttr is not defined
I recommend changing that line to:
[html]if (typeof twttr != "undefined")
twttr.events.bind(‘tweet’, wdsm_twitter_callback);[/html]Hi!
No problem, I’ve found the previous topic and fixed it again 🙂 For future reference, the following code was added to your theme functions.php file:
[php]if (!function_exists("parse_tpl_image")) {
add_filter( "asp_results", "parse_tpl_image", 1, 1 );function parse_tpl_image($results) {
foreach ($results as $k => $result) {
if ($result->image == null || $result->image == "") {
$m = bdw_get_images_plugin($result->id, ‘directory-single-thumb’);
if (is_array($m) && isset($m[0][‘file’])) {
$results[$k]->image = $m[0][‘file’];
}
}
}
return $results;
}
}
[/php]
