- This topic has 7 replies, 2 voices, and was last updated 1 year ago by
.
-
Posts
-
Here’s my question in video form: https://somup.com/cTfv2bMVmK
Hopefully that makes some sense, basically wondering if there’s a way to integrate this into category/archive page templates in such a way that the filters and results will narrow down as someone navigates child categories, or if the search bar must always display ALL filters / results.
So here’s the top-level page: https://www.newageindustrial.com/resources/
And if someone were to visit the brochures category (https://www.newageindustrial.com/resource_category/brochures-flyers/) it would update to display only relevant child categories / results and/or would have the filtering options display in such a way that the results are relevant to that archive page.
Or I may be going about this all wrong, and if so just let me know. Just trying to replace our old-school product navigation with something faster but still retain your typical category URL structure.
I did delve into this page: https://documentation.ajaxsearchpro.com/behavior/results_page_live_loader
I tried configuring the archive live loader and specifying the DOM element as .et_pb_blog_grid and it looked like it was trying real hard to load filtered results into that element but it looks like the filtering options would remain the same even if it had worked.
Perhaps I need to simply use Ajax Search Pro on the main, broad level resources page and if someone starts drilling down just use a traditional list of categories on the left.
Hi,
Thanks for your kind words again!
The way I would handle that is similar to what we have on our demo. For example, this is the “General” category archive for the post type results.
As you can see, there is a search bar on the top right corner, which will automatically filter the results. You have it right, for that you need the results page live loader feature.I quickly looked at the archive source, and based on that I recommend using this DOM selector:
.main-archive-loopInstead of using the same search bar, I would create another one, without the filters. The reason is, that on the category archives when the archive live loading is enabled, the results are automatically restricted to the current category.
In my opinion the best practice is to use a search bar, without filters as the user already knows that they want to search only the given category archive.Excellent. This all makes sense. One issue I bumped into was that after I got it working (using your DOM selector provided above) it did load the results into the main grid as expected, but it loaded all of our “blog” posts and not any of the posts that the search instance is configured to index. Same search bar works okay when deployed without the archive “live load” functionality, loading the CPT “resources” which is the only one it is configured to display. But when the live load is enabled, it loads standard “blog” posts instead.
I may not go with this use case in the end, so please don’t put too much time to it, but if you have an easy answer for that please let me know so I can continue experimenting.
That blog post thing could be some sort of an overrid issue somewhere.
If you want, you can add back-end details and I can try to investigate it a bit further.
Thanks!
I have taken a closer look, did about an hour of debugging, but no luck. The override does trigger and the search does return the correct items, but they are not displayed as they should be.
I suspect it is due to how the Divi Machine addition works. I guess it has it’s own loop and it overrides the original, regardless what Ajax Search Pro does. I don’t think there is a way to override that, or at least I couldn’t find it. Some query variables were transfered, but most of them are overwritten, so my guess is that there is a hook beyond the search that’s being overwritten.As for the product tags, specifically search phrase “2448”: The way the index table gains significant performance is by executing specialized search queries. One of the main rules is, that the matching can not be within the words. So for example “2448” will match “2448HD” but will not match “22448BB5″ – because it does not start nor ends with the search phrase. This is a trade-off for performance and it can’t be avoided, otherwise a non-indexed query would be executed by the database server, which is basically what we want to avoid.
This is why there is a difference. If middle-word matches are very important to you, you should not use the index table engine. Queries on the taxonomy terms (tags) database table are fairly quick, as it has it’s own special index (of a different kind).
Thank you Ernest, that all makes sense regarding the live load. Divi Machine does seem to operate on query loops, I’ll be okay without that. As for the second explanation, I actually think I read about that (inability to match terms within words with index table engine) and must have forgotten, I am trying to learn the various aspects of the plugin as I go but it is pretty deep so I appreciate your patience. We will proceed without the functionality we have, as we are still leaps and bounds ahead of the old tools.
- You must be logged in to reply to this topic.