[Ernest Marcinko]

Hi!

This time I needed to change one file in the search plugin directory. I don’t know what caused this exactly, but it’s fixed. You should see the search bar now as before.

[Ernest Marcinko]

Hi!

There is a guide in the knowledge base for safe upgrading, as well as in the documentation:

https://wp-dreams.com/knowledge-base/updating-from-older-versions/

http://wp-dreams.com/demo/wp-ajax-search-pro3/docs/#important_upgrade_notes

I believe you missed one step. The cache options have changed in the new version, so there is a possibility of database inconsistency. Since you give me access I did solve this for you, by simply saving the cache options without change. It should be working now correctly.

[Ernest Marcinko]

No problem at all.

This makes it a bit more difficult, as the tags search is a bit simplified, because it can make the search really really slow if someone has got a bigger database. So in this case changing the keyword logic won’t help you, simply because it’s not implemented to the tags search.

I made however a quick modification to the search code, but I cannot guarantee a proper speed, but in your case it might just work fine.

Do the following:
0. Make a backup copy of the wp-content/plugins/ajax-search-pro/ directory, just in case.
1. Open up the wp-content/plugins/ajax-search-pro/includes/search_content.class.php file and replace it’s contents with this: http://pastebin.com/raw.php?i=SRD34HnM
2. turn OFF the “Show exact matches only?” option on the General Options->Sources panel (at the bottom), this is very important
3. Change the keyword logic to “AND” or “AND with exact word matches” (if you want more strict results) on the General Options->Behavior tab

Now the keyword logic will respect the terms search (in your case woocommerce tags) as well.

[Ernest Marcinko]

Hi!

I just activated the plugin and it works for me. I got the results in under a second, which is extremely good: http://i.imgur.com/TUGiRGf.png

I could not test this on mobile, because the widget area does not show up there, so I can’t tell if it works or not on my devices. Try to put the search elswhere, maybe the theme has widget positions for mobile screen sizes. Your theme is responsive and it hides the sidebar on mobile screen width, which contains the search.

The geolocation search depends on how the geo data is stored for each post. If it’s a custom field, then it should be all right. All you will need to do is to select the custom field which contains the gelocation data. Here is a quick info about custom fields from the documentation: http://wp-dreams.com/demo/wp-ajax-search-pro3/docs/#general_options_search_in_custom_fields

[Ernest Marcinko]

Hi!

Thanks for the detailed ticket and the login details. I just logged in to your site to try, and it worked for me. Maybe it’s a browser issue on the backend? I’m using chrome on windows 8.1 currently, but it should work for other browsers as well.

Anyways I dragged the latest news and the tracks category to the excluded list, it should work all right now.

[Ernest Marcinko]

Hi!

In the latest version I implemented selectable search logic, which is exactly for solving these kind of issues.

Here is an explanation on them: https://wp-dreams.com/knowledge-base/search-logic-explained/

In your case I would suggest to select the “AND” search logic on the General Options->Behavior tab. This way the search will look for partial matches, but every word must match the result.

So if the post title is “Canon PIXMA MX300” then the “Canon MX300” will definitely be a relevant match. For even more relevant matches you can choose the “AND with exact word matches” option.

Also, make sure to turn OFF the “Show exact matches only?” option on the General Options->Sources panel (at the bottom) if you change the search logic, as it will only match the exactly typed partial or full matches, which is not the desired way in most cases.

[Ernest Marcinko]

I guess because the first or the second instance has the “Show the plugin under content” option enabled. That way the plugin is automatically placed under the content.

Here is a detailed explanation of it in the documentation: http://wp-relatedpostspro.demo.wp-dreams.com/docs/#getting_started_placing_the_instance_to_the_frontend

If you turn this option off then it will be visible only on pages where the shortcode is placed.

There are also chapters about how to override the visibility with metaboxes. Please go through quickly the documentation, it has answers to most of the questions you posted.

[Ernest Marcinko]

1. The first one is Minimal grey transparent and the second looks like Pinteresting. Try to select the Minimal grey transparent on the second one again, wait 10 seconds and save it. Clear the site cache and it should be exactly the same.

2. Have you turned off the “Return pages” option on the content options panel?

[Ernest Marcinko]

Is that the new instance you created? If you have two instances now, then you should disable/replace the old one’s shortcode. From the source all I can see, that this is the first instance. So unless you deleted the old one, then you should replace the shortcode.

[Ernest Marcinko]

If you want it to look like the other one, then you should make everything exactly the same.

[Ernest Marcinko]

When you create a new one, it uses the default settings, it does not copy the other one. You need to configure that one as well.

In the upcoming version I will add an option to make a copy, it had been requested a few times before.

[Ernest Marcinko]

I think so. If the protfolio is a custom post type (which I guess it is).

You can select it on the content options panel. Here is it in the documentation: http://wp-relatedpostspro.demo.wp-dreams.com/docs/#content_options

Turn off the “Return posts” and “Return pages” options and drag the portfolio (or whatever it’s called) custom post type from the right column to the left.

[Ernest Marcinko]

If you turn that off it might help, or maybe the memory runs out later on rendering, it’s really hard to tell. If the limit is set to a low value, then it won’t help much. It would be a much better solution to increase the memory to 1024MB or at least 512 if possible. Under heavy traffic it’s a good thing to have 😀

I’m running this site and all the demo sites + test sites + another site on a 2048MB VPN, that’s like 10 wordpress installs and it’s doing all right. At most I had like 800MB consumed, but it was under very heavy traffic spike. So I definitely recommend increasing the memory to at least 1024MB, that will cover a single wordpress install for enormous traffic spikes with a proper caching.

No problem, feel free to ask me anything related the plugin. I usually answer within 24 hours.

[Ernest Marcinko]

Okays, you can switch it back, I got it.

It looks like the site is running out of memory even before it reaches the related posts plugin.

The error messages on the top are fine, those are some notices only, the issue is the following:

Warning: Invalid argument supplied for foreach() in /hermes/bosnaweb06a/b1072/ipg.blueverticalstudio1/ezine/wp-content/plugins/wp-slimstat/wp-slimstat.php on line 683 Warning: Invalid argument supplied for foreach() in /hermes/bosnaweb06a/b1072/ipg.blueverticalstudio1/ezine/wp-content/plugins/wp-slimstat/wp-slimstat.php on line 683 Fatal error: Allowed memory size of 41943040 bytes exhausted (tried to allocate 2857795 bytes) in /hermes/bosnaweb06a/b1072/ipg.blueverticalstudio1/ezine/wp-includes/wp-db.php on line 104

So while the slimstat plugin is reached the memory runs out. I’m not sure what is the memory limit on the server but you should definitely check that. Anything below 512MB is critically low for a wordpress installation with several plugins.

You can try to increase the memory limit programatically by adding the following lines to the wp-config.php file, but it might not work, if it’s restricted on server side:

ini_set('memory_limit', '1024M');

[Ernest Marcinko]

Okay. Then I think you should turn on error reporting for a while, to see if there is anything informative.

You can do that by editing the wp-config.php file on your server, arount line 82 you should see this:

define('WP_DEBUG', false);

change it temporary to:

define('WP_DEBUG', true);

then let’s hope that some error messages will pop up, that would be the best.

[Author]

Posts