Hi Ernest,
My thanks again for the detailed reply. Your plugin really is amazing, and the high praise is well-deserved! Thank you again for creating this plugin, as it’s going to be an important part of our new platform.
I’ll stick to the original numbers to keep this response clear:
1. Filter Results by Content Type (or Grouping Ability) for Isotopic Search Results
Indeed, I realize this cannot be accomplished outside of the plugin. This is really more of a feature request. The isotopic navigation is by far the most superior UI option in your plugin. But it does have a few short-comings, and this is one of them; the lack of ability to group. Having a filter that can act as a substitute grouping by type (ex. Posts, Categories, Tags, Users, etc.) would effectively solve this problem.
Another idea would be to build a grouping type feature into the Isotopic UI, perhaps above or underneath the page navigation. It could work similarly to a filter, and simply work with tabs to group the search results by type. So in other words, each group gets a tab in the results, and each tab has page navigation. Naturally this is a little more complex to implement (both in UI and code) than simply adding normal filters as I first suggested.
Either way, I think a solution is needed here so that we can use Isotopic results and still have grouping. On our platform this ability is particularly important, as we will have many search results in each content type.
2. Post-Format Filter Missing Default Format (Article)
You’re exactly correct when you said that standard posts (Articles) display no matter what filter you select because of the lack of format. Our development team ran into this exact problem when working with post-format filters in the Essential Grid plugin. We were able to create filters for all formats except the default format.
Luckily we found a way to write a script that added this filter without actually touching the plugin itself. If you’re interested in how our developers achieved this, I can ask them to show me the code so that perhaps you can integrate a similar solution into your filters. This is definitely something we need in Ajax Search Pro, and it would be far better if the solution was part of the core plugin. I’d be happy to share our Essential Grid solution with you so we can achieve this together. There is definitely a solution for this problem… because we solved it before! 😉
3. Flicker Problem for Icon Overlay in Isotopic Search Results
In answer to your question, I’m using Chrome on a Windows machine. I’m also using a very large monitor, which may have something to do with this. I just tested this in Firefox, and it is having the same problem.
Basically when you move your mouse over the search results (the thumbnails) in the Isotopic UI, the overlay with the icon doesn’t always know what item your mouse is over. The icon has a tendency to flicker to the search result next to the one your mouse is over. I’ve also just made a new observation that the flicker only happens when the mouse is over the inner circle that contains the icon. If the mouse is outside of that circle, the icon/circle stays in the center without a flicker.
I’m planning to customize this look and feel a bit, so this issue may not end up affecting me, but it’s definitely an issue in the plugin that should be solved. I’ll help any way I can.
4. Automatic Image Loading for Category and Tag Search Results
Thank you for providing this snippet. This looks very similar to the kind of solution we used in UberMenu (our menu system) for this same purpose. In our menu we had to add a filter so that any category items in the menu would automatically retrieve their assigned category image. We basically need to do the same thing here, except this must work for both categories and tags (we will have tag images as well).
I’m going to pass this code along to our developers so that we can customize it to work with our category images plugin, and also with our tags. The end result here should be that all these images load automatically in the search results. I’ll get back to you about this if we have any further difficulties.
…..
I have two quick additional questions about the caching system…
1. I have caching enabled, and also have the image cropping feature enabled. I’ve looked in the bfi_thumb folder, and see it’s cropping the images successfully (cool feature btw). Just to be clear, the bfi_thumb folder is the actual caching, and this means the only thing being cached is images (not search results). Am I correct?
2. As I was writing to our developers about integrating your snippet for the category images, something occurred to me. This snippet would allow us to have the category images provided from our plugin, using the file paths stored in our plugin. But because we’re using the caching in Ajax Search Pro, those images would be retrieved, cropped, and then stored in the bfi_thumb folder. This means that they would only be retrieved once from our plugin, and then never again.
Our category images plugin actually is broken down by image size. We create multiple size images for every category, and then those image sizes are used for specific features and sections of the site. I realized I would need to make a new image size series for the search results (probably 200px wide, as this is what I have the search results width set to). But if the images are being cropped and re-saved to a cache, it kind of renders my image work useless (at least for making a specific size).
I’m curious to hear what you think about this, and what you think the best course of action is. Should I just create an image size series at 200px wide, and let bfi_thumb do it’s thing? Or should we be bypassing the caching just for these images?
…..
Thank you again for your help Ernest. I feel like I’ve been lucky lately in selecting plugins with amazingly helpful and responsive authors!
~ Michael
-
This reply was modified 6 years, 5 months ago by
Michael Samson.
-
This reply was modified 6 years, 5 months ago by