[Ernest Marcinko]

Hi!

1. Yes, it’s the argument passed to the database query. The lower, the better. Low limit usually speeds up the response.
2. Well, I would not recommend that either. Displaying so many things at once on one page is not a good idea, you would get similar problems with each layout.

For this task, I would consider some kind of infinite ajax scrolling and filtering plugin, if anything like that exists. Something like that would only display for example 20 products at once, and if the user clicks on the next page or “show more” button, it would dynamically load more. He could then paginate through all the 2000 products without crashing the browser – because only 20 is displayed at one time, and others are not.

I’m not sure if a plugin like this exists though.

The search was not exactly made for displaying large numbers of data, it’s rather an search engine to display quickly a few possible results for the user in real time.

[Ernest Marcinko]

Hi!

Sorry about the late response, I’ve missed your ticket by accident.

It’s only possible for the ajax results list. To achieve that, you have to exclude all other categories on the Advanced Options panel: http://i.imgur.com/Nb2YBaf.png

[Ernest Marcinko]

Hi!

The up-down arrows seem to work for me, but the Return key does not indeed. Can you confirm that the up-down arrow is working for you as well?

[Ernest Marcinko]

Hi!

It appears that the wp_footer() call is missing from the theme footer.php file, therefore the scripts are not loaded. I’ve changed the Load scripts in footer? option to NO on the compatibility options panel, so the scripts are loaded now in the site header: http://i.imgur.com/hdn7qc7.png

I recommend adding the wp_footer() call to your theme footer, other plugins might be using it as well 🙂

Plus I noticed on google cache that your site was previously using a layout from Yith woocommerce search, so I’ve quickly configured the search theme to a similar layout, in case you wanted that as well.

[Ernest Marcinko]

Thank you very much, it’s my pleasure helping my customers 🙂

Feel free to rate the plug-in on your codecanyon downloads page.

I just saw your awesome comment on codecanyon as well, I will leave a thank you note there as well.

Have a nice day!

[Ernest Marcinko]

Hi!

Thanks for the detailed description of you ticket. I will try to explain everything in as much details as possible.

I’ve actually found a bug in the OR logic, there was a wrong database prefix used, it should be working now. I will still explain a few things if you don’t mind 🙂

First thing you need to understand that on the database level, terms (such as product categories) are treated (stored) equivalently regardless of their taxonomy or level. Thus parent and child relations are non-existent until a certain point in the application – but not on database level.
Imagine a big list of ids and names, where one column determines the parent-child relations to each other, another a relation to a certain taxonomy ID, but no other difference.

Explanation of the logics

The logics were build based on the post points of view.

AND – displays posts or custom post types of which the exluded terms are not matching. Excluded terms in this case mean unchecked checkboxes, or excluded categories/taxonomies. More clearly – from the post/product point of view the post terms must be an exact sub-set of the selected terms, and not match any of excluded. If the post doesnt have a related terms, it’s displayed.

OR – displays posts or custom post types of which at least one remaining term is matching. Remaining terms are Available terms – Excluded terms – Unchecked terms. From the posts/product point of view it has to match at lease one of the selected terms.

1 – 2. As I explained in the previous section, from the posts point of view the results are correct, because all of them are exact sub-sets of the available terms.
You might ask, why is this logic called AND then? Well, it’s definitely not an OR, but not a fully restrictive AND from the users point of view. Let me give you a better example why is it preferred this way:

Imagine a webshop with 3 parent categories: t-shirts, toys, book. All of these categories have 5 sub-categories. Let’s assume every product in this shop belongs to a parent and at least one sub-category.

The user want’s to search specific items from the t-shirts category, so he selects t-shirts and some sub categories and gets some results. Then he also wants to show some books, so he selects books and some of the book sub-categories. And here is a dilemma. The OR logic is definitely off the table, as it would show everything from t-shirts to books, and the sub-categories are meaningless. The AND logic you described is no useful either, since no product is a t-shirt and a book, so nothing is displayed. However the implemented AND logic will check posts against the whole set of the selected categories – and each matching product must have all their categories in the selected sub-set.

Therefore it will display books and t-shirts matching the selected sub-categories.

3-4. I believe it should work as expected now that I’ve corrected the typing mistake within the code. I’m also fixing this for the upcoming update.

I find your insight very useful, and I believe I should make a correction and expansion on this part of the plugin. I decided to implement the more restrictive and logic you just described in the upcoming release, because others might find it useful as well. I’m going to re-name the logics to something more intuitive, and an extra chapter of documentation with explanations is incoming.

Let me know if you find anything strange!

[Ernest Marcinko]

Hi!

It should work. I just double checked the test environment and the demo servers, and it appears to be working for me.

If you have an issue, I gladly take a look if you want to.

[Ernest Marcinko]

Hi!

By default the plugin tries to generate the CSS into the wp-content/plugins/ajax-search-pro/css/style.instances.css file directory. If this directory has wrong permissions or not writeable, then as a fallback it has to load it into the header as inline CSS – it does NOT affect SEO as the inline CSS is valid as long as it’s presented in the head section of the HTML code.

To remove the inline CSS from the head, make sure that the wp-content/plugins/ajax-search-pro/css/ directory is writeable – by chmodding it to 755 or 775. If that does not help, then the www-data process might not have the ownership of the directory, and you will have to adjust it via SSH.

Also, make sure that the Force Inline Styles option is turned off on the Compatibility settings submenu: https://i.imgur.com/C1eQXuc.png

IMPORTANT: If you sucessfully changed the permissions, then save the Compatibility settings submenu, to have the stylesheets re-generated.

[Ernest Marcinko]

You are welcome!

I think it’s possible to add a similar dropdown. As a test I’ve added a drop-down to the settings list with “bay leaf” and “chili” in it, and it appears it’s filtering correctly: http://i.imgur.com/jljigjW.png

You can edit or remove this box on the Frontend search settings -> Custom fields panel: http://i.imgur.com/TMXy04c.png

I believe you can edit this box to add more ingredients you have. I don’t actually know how the recipe plugin stores the ingredients data, so it might not work 100% correctly, it might show more/less results as expected, but so far if I select “chili” from the ingredients and type in “spagetthi” then no spaggetthi is shown, but if I type in “chili” the Yum Yum chili comes up – so I’m guessing it’s correct.

Before you jump in, this is a very advanced feature, and I recommend reading the documentation on custom field filter selectors first to understand how it works. There is also a video tutorial available if you are interested. I’ve already configured yours, you just need to enter the additional ingredient values.

Also, please leave the first line untouched on the ingredients selector editor: http://i.imgur.com/nLstwmd.png
It’s neccessary, as it creates an empty filter, otherwise all results would be filtered by the first ingredient on the list – giving you incorrect results.

[Ernest Marcinko]

Hi!

It looks like you have discovered a few bugs, it appears 🙂

Thank you for the correct description and the login information, it made my work much faster.

1. You are right, it was not working correctly, the suggested words were incorrect. I’ve used the FTP account to do some debugging, and found a programming error, which resulted printing the incorrect word. The word should be relevant and correct now.

To get the autofilled text actually filled, you need to press the right arrow on your keyboard, and it finishes the suggestion. I know it’s strange, but when I built the engine, the google suggest used this same method, but now it’s different. I will try to work out a better, more convenient solution in the future for sure.

2. Another bug I discovered, that on the layout options panel, when the user login was selected as the user name field, the search did not go through as there was a typing error in the field value. Once I fixed that, it started working as configured. I’m definitely fixing this in the upcoming version, as I was not aware of this tiny issue 🙂

3. Same as the 2. issue, it should be working as well.

4. In this case you need the “Index table” engine. Posts and custom post types related to names can be indexed together, but comments not. So searching for a user name should give you the submitted posts, pages, recipes and q&a stuff which the user posted, but not the regular post comments (those are unfortunately stored differently in wordpress). I see you did configure the index table correctly for this task. I’ve switched to the index table engine on the search General Options panel to have this in effect.

Another reason to use the index table engine instead of the regular one is the fact that you have the “OR with exact keyword matches” search logic activated – which works far better with the index table engine, as there are no special characters involved in the index table, and therefore the word boundaries are recognized far efficiently. That means more relevant results.

Let me know if you need any more help!

[Ernest Marcinko]

Under final testing, it’s implemented. I’m uploading it in a few hours. Then it only depends on codecanyon 🙂

[Ernest Marcinko]

You are very welcome! I’m glad it’s resolved 🙂 I will incorporate some changes to the upcoming version so this issue should not appear again.

Thank you very much for the positive rating, I really appreciate it, you are awesome!

[Ernest Marcinko]

Hi!

Thank you for enabling the debug, I can already see the problem. I’m getting this error:

[code]Call to undefined function mb_strtolower() in ….[/code]

This means, that multibyte string functions are disabled on your server. I can suggest 2 possible solution to this issue:

1. Enabling multibyte string (mbstring) module – It’s widely used, many plugins are using these functions, and are very helpful. Especially in your case – whereas your language does indeed use multibyte strings. Here are some guides how you can enable mbstring in your php.ini file:

How to enable mbstring?

If you don’t know how to make these changes, please contact your server administrator.

2. Turning off the Display the description context? option on the Layout Options -> Results layout panel: http://i.imgur.com/HMNgVG1.png

This way you bypass the code conducting the error.

Let me know if any of this helped.

[Ernest Marcinko]

Hi!

The reason why you see those results is because the plugin re-directs to the default wordpress search page by default. The search cannot modify this page layout unfortunately because it’s a theme feature.

However, what you are seeking is to redirect to the woocommerce search page, which is different from the default one. It’s possible, and since you gave back-end details I made the change in the configuration, so now the search redirects to the correct woocommerce search page.

I’ve changed the Redirect to url? option on the General Options -> Behavior panel from

[code]?s={phrase}[/code]

to

[code]?s={phrase}&post_type=product[/code]

The additional parameter tells wordpress that you are seeking a product, and WooCommerce search takes the control automatically.

[Ernest Marcinko]

Hi!

Good, I’m hoping it helps.

I’ve flushed the cache and refreshed the page with CTRL + R and they are look the same now to me. If you use cahce don’t forget to flush it or disabling it until you finish with modifications. The search stylesheets are stored in one file for better performance, and the server was still serving the old one, where the second one does not existed, and it looked weird.

[Author]

Posts