4 Unrelated Issues on a New Ajax Search Pro Integration

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 5 years, 10 months ago by  Michael Samson.
• This reply was modified 5 years, 10 months ago by  Michael Samson.

Hi Ernest,

Thank you again for the quick reply!

1. Filter Results by Content Type (or Grouping Ability) for Isotopic Search Results

I agree with you that implementing this as a results filter makes more sense. Using a filter will also keep the options in the settings area, and not clutter up the Isotopic UI with additional choices. Thank you for adding this to the feature requests. I hope you add it soon, and when you do please let me know so I can implement it! 😉

2. Post-Format Filter Missing Default Format (Article)

I’ve asked my partner who is managing the development team to point out the code for me so that I can send it over to you. I’m waiting for him to send it over. One thing to keep in mind is that we solved this filter issue in Essential Grid without actually modifying the plugin. All our scripts for this were external. You’ll be able to change this within the actual plugin, but I suspect the methodology will be the same as ours. I’ll send this over as soon as I have it.

3. Flicker Problem for Icon Overlay in Isotopic Search Results

I tested the page you sent and the problem does not occur there. But the ajax results on that test page are very small in width. My results container is set to 100% width of the screen, which is very wide on my monitor. Perhaps this has something to do with the problem. I’ll also try to pin down the cause more over here when I work on customizing that css (one of my next tasks).

4. Automatic Image Loading for Category and Tag Search Results

I’ll definitely keep you posted on this. It may be a little bit before our developers get to this task, as we’re working on a great many issues right now. But we’ll be doing this soon enough.

Question 1

Just to clarify, the caching that is occurring is the caching of these images in the bfi_thumbs directory, nothing more, right?

Question 2

Ok, this is interesting. So if we use a filter to display our own images for category and tag results, then those images would be used as-is, and would not be cropped or cached, right?

I think what you’re saying here is that when the plugin finds results with images (like a post), that’s the point at which it retrieves the image, crops, and caches it. The category and tag results have no images, so they would be displayed without images, and then the filter would kick in and display the images we want. So in effect, the cropping and caching never comes into play.

If that’s the case then I can indeed size these images to my own specifications, as I do for all category images. I would just need to make sure the images cover the container properly, as the aspect ratios are different (between the images and the results cards). But that shouldn’t be too difficult.

I’ll get back to you about how this all works out when we implement the filter. Let’s also please keep this thread open until everything is resolved.

Thanks again Ernest!

~ Michael

• This reply was modified 5 years, 10 months ago by  Michael Samson.

Hi Ernest,

3. Flicker Problem for Icon Overlay in Isotopic Search Results

I’ve been busy the past few days with other things, so I didn’t get to work on the css just yet. I’m going to try fixing this tomorrow, and I’ll get back to you with my results. I may indeed try something like you’ve suggested here.

Question 1

Thank you for clearing this up. I have both the image caching and search caching enabled, as we are expecting enormous numbers of searches once the platform grows. That’s interesting that the database has it’s own built-in caching (I did not realize that). But since you did include a separate caching feature here I wanted to make use of it.

I looked at the asp_upload directory and see the cached searches. Thank you for pointing this out to me.

I have three suggestions to help improve these features:

1. I would separate the search results cache from the css styles in the uploads directory. These really belong in separate folders (see my second suggestion on naming).

2. It would be good to rename these folders in the uploads directory so they are more apparent as to their purpose. Perhaps the following would work well:

asp_cache_images
asp_cache_results
asp_dynamic_css

3. The options in the Caching Options screen could be better named (and described) for clarity as well. I was actually confused by these options when first setting up the plugin. I think the main source of confusion is from the “Crop images for caching” option. When you describe this you talk about disabling the thumbnail generator, which is only what would happen if you turned this option off. The description should really describe what the option does when turned on (it’s counter-intuitive).

I would rename the regular caching option (for search results) to “Search Results Caching” and the image caching option to “Image Caching & Cropping”. I would also make it more clear in the description that the image caching and cropping functions are one and the same thing. If this option is turned off, then no caching or cropping of images occurs. This is really a combined feature (please correct me if I’m wrong).

2. Post-Format Filter Missing Default Format (Article)

As promised I am supplying below the code that we used to display the default post-format (Article) in the post-format filters for the Essential Grid plugin. Please keep in mind that this is for Essential Grid and that we had to do this from completely outside the plugin. But I think the general technique would be very similar to what you need to do for this to work within Ajax Search Pro.

I hope this helps you to include the default post format in the filter options (and also keep those default posts excluded when other formats are selected – this is equally important).

/* ############# Essential GRID add Article filter ############# */

/**
 * Function adds one more Essential Grid Filter.
 * @param array $settings
 * @return string
 */
function bbed_set_filter_settings_func( $settings ){
    
    // Prepend value in the begining.
    array_unshift( $settings['settings']['filter-selected'], 'post_format_STAN0');
    
    return $settings; 
}
add_filter('essgrid_set_filter_settings', 'bbed_set_filter_settings_func', 10, 1);


/**
 * Function adds custom filter additional information.
 * @param type $filter
 * @return int
 */
function bbed_set_filter_info_func( $filter ){
    
    $filter[ 'STAN0' ] = array(
        'name' => 'Article',
        'slug' => 'standard',
        'parent' => 0,
    );
    
    return $filter; 
}
add_filter('essgrid_set_filter', 'bbed_set_filter_info_func', 10, 1);


/**
 * Function used to add custom format class details.
 * @param type $terms
 * @param type $post_id
 * @return - Term Details.
 */
function bbed_add_standard_format_terms_details( $terms, $post_id ) {

    $c_terms = get_the_terms( $post_id, 'post_format' );
    if( empty( $c_terms ) ){
        $dummy_term_data = new BBEDArticleTermDetails();
        $terms[] = $dummy_term_data;
    }
    return $terms;
}
add_filter('essgrid_get_custom_taxonomies_by_post_id', 'bbed_add_standard_format_terms_details', 10, 2);


/**
 * Class returns hardcoded terms details.
 */
class BBEDArticleTermDetails{ var $name = 'Standard', $slug = 'standard', $parent = 0, $term_id = 'STAN0'; }

• This reply was modified 5 years, 10 months ago by  Michael Samson.

Hi Ernest,

I saw your message about being away until December 19th. Thanks for posting that so I knew what was going on. I wanted to drop you one more message here (in addition to the two above you have yet to see). I’ve been making a lot of progress here customizing the plugin (css work), and at this point it’s 99% done. I’m really looking forward to showing you this implementation once our site goes live (still a few months away).

I found three new small (but important) things I wanted to let you know about…

1. In the “Frontend Search Settings” under the “General” tab:

The “Generic Selectors” have no way to assign a header. This looks a little funny when you’re using a few filters, and only this one section has no header on top. It would be great to be able to enter one in here so things look consistent. I’m referring to the headers like “Filter by Categories” for example. The Generic Selectors need a header too (preferably one we can enter).

2. In the “General Options” under the “Attachments” tab:

The setting for “Link results to” needs an option to link to the parent post page. This is really critical to have on a site like ours which is made almost entirely of posts. I want to make use of the attachment search capabilities in your plugin because it’s capable of generating a lot more relevant results. But these attachments all are linked to posts on our site. It’s important that these results link back to their parent post page when clicked from the results. There’s no option for this right now.

3. In the “General Options” under the “Attachments” tab:

When setting “Search engine for attachments” to “index table engine” there appears to be a problem with generating results. I found that this option would not generate any attachment results at all. When I used the normal engine there was no problem.

…..

That’s it for now. Please remember I have three posts here for you to reply too… 😉

All my best,

~ Michael

Hi Ernest,

Sorry for the slight delay in me getting back to you. I’ve been pretty busy here that last two days working on a project.

I just read through all your responses. My compliments on not missing anything, as we are speaking about many features/issues simultaneously. Your level of support here really is fantastic, and I appreciate it very much!

Below I am outlining every single item that we’re working on as briefly as possible so we can track it all…

…..

Question 1 / Parts 1-3

After reading your comments on the advantages to having just one folder for the search cache and css, I agree, this makes more sense. I was thinking more about the organization, and not how efficient it was. I agree with you now on this.

Since there would just be the two folders, you could name them this way:

asp_cache_images (instead of bfi_thumb)
asp_cache_results (instead of asp_upload)

The css would still be stored in the same folder as search results, but I still think it makes sense to name the folder as a cache.

Please also take note of my recommendations for renaming settings in the Caching Options screen (it was Question 1 / Part 3)

Post-Format Filter Missing Default Format (Article)

I’m not surprised this was a more complex issue within the context of this particular plugin. With that said, thank you so much for tackling this issue head-on and getting it into the next release. This is going to make the post-format filters work the way they should. It’s just too bad that WordPress has made this difficult for us with the non-format post-format. 😉

Flicker Problem for Icon Overlay in Isotopic Search Results

You should be able to replicate this pretty easily by using a slightly larger SVG image than your default.

Feature to Disable the Isotopic Default Image

Thank you for creating a solution to this. I simply want to disable this image completely from displaying.

CSS Issue Tied to the “nav.asp_navigation” Element

I fixed this already on my end, but just a note to remind you about it.

Filter Results by Content Type (or Grouping Ability) for Isotopic Search Results

We’re in full agreement that a filter is the best approach to this problem. Please make sure when you create this filter that it has it’s own column and header in the settings screen. I’m assuming you’ll build in the ability to control exactly what filter options appear on the front-end.

Customizable Headers in Settings Screen for “Generic Selectors” and Date Filters

Just a reminder that this simple feature is needed. I just realized that the date filters column could also benefit from having a customizable header (something like “Filter by Date”). You could just use “Filter by Date” for the date column (not customizable), and make the generic selectors column customizable (since this is more open-ended as to what you would name it).

Linking Attachment Search Results to Parent Posts

This is kind of a make or break issue for us using attachments at all. We’re building a new social media platform which is largely based on user posts and media content. The attachments feature is great because it can bring up so many more relevant search results by looking only at the attachment names. I like this a lot! But those attachment results must link back to their source, which is the post pages in our case.

The question is, how is the search actually finding the attachments? It is looking only in the /uploads directory?

This in of itself may become an issue for us because we’re about to start pushing the user-based uploads to an S3 bucket. They won’t be stored in the actual /uploads folder any longer. We’re going to be using the WP Offload S3 plugin for this. It will be interesting to see how this affects the search ability for attachments.

Assuming this doesn’t cause problems, we still need to have these attachments link back to their parent post pages. Doesn’t WordPress associate the files in the media library with the post pages it comes from? I thought it did. If that’s the case it should be possible to have the attachments link back to their parent posts. Just so you know, our attachments are not on pages… only in posts. I hope we can make this work on our site. Otherwise we can’t display attachments at all in the search.

Attachments Not Displaying When Using the Index Table

I checked and we do indeed have “Attachments” added to the post-types. This appears to be a bug in this new feature. I’m sure you’ll get this fixed with more testing. In the meantime I’ll leave the attachments set to use the standard search method.

Automatic Image Loading for Category and Tag Search Results

We’re still working on this one. It’s one of many upcoming tasks that my developers will take care of.

……

That’s everything you and I are working on. Thank you again for providing such amazing support and being willing to take suggestions.

All my best,

~ Michael

• This reply was modified 5 years, 9 months ago by  Michael Samson.