This website uses cookies to personalize your experience. By using this website you agree to our cookie policy.

Reply To: Continuation of Previous Thread Regarding New Features, Improvements, and Bugs

Home Forums Product Support Forums Ajax Search Pro for WordPress Support Continuation of Previous Thread Regarding New Features, Improvements, and Bugs Reply To: Continuation of Previous Thread Regarding New Features, Improvements, and Bugs

#17932
Michael SamsonMichael Samson
Participant

Hi Ernest,

I’m sure this won’t come as a surprise to you, but my last few weeks have been insanely busy. I’ve been wanting to get to this for a while now, but I had to focus my attention elsewhere for a while. We’re working on a number of large infrastructure and engineering projects over here. Suffice to say things are very busy but we’re making a lot of progress towards our launch.

I’ve installed the latest version of ASP and just fully tested it. You introduced some interesting new features. Most of these don’t apply to my use-case, but neat stuff none the less!

…..

Date Filter Bug

I was disappointed to discover that this problem is in fact not fixed. I tested it extremely carefully to be sure about this. The original problem remains. I’m using the “Relative Date” options for the From Date and To Date fields. In the From Date field it is set to exactly one year ago.In the To Date field it is set to today’s date by entering in “0” into all the fields.

To reiterate the problem, any posts that are posted on today’s date simply will not show up in search results. This is despite the fact the To Date field is set to include today’s date. The results only display through yesterday’s date.

This is a really insidious problem, as it tends to cause all sorts of other search problems. It makes it very difficult for me to test ASP because none of my test results show up until the following day.

To prove this was not corrected I disabled the To Date field, and after that the problem went away. I really hope you can get this fixed.

…..

Featured Image Source Size Not Working in All Situations

I do not believe you tried to fix this yet, but I did test for it. I found this problem remained. Here are my original notes on it below:

This is a new issue I haven’t told you about until now. We’ve been working here on customizing all of our image sizes site-wide, generating specific sizes for specific locations. For ASP we are creating a 300x375px image.

I set the Featured Image Source Size to use this specific image, but it’s not working across the board. What I found is that it only seems to work for normal post search results. The attachment results are displaying the full image size, and tag results are strangely displaying the thumbnail (small) size. For tag results (we call them subcategories) we have created functionality for the search to display the image from the first post in the subcategory. This is working beautifully, but it is using the incorrect image size. The problem with the tag images may be on our end in our script, and I have brought it to the attention of our developers.

…..

Attachment (Media) Images are Not Being Automatically Added to Index Table on Post Creation

I found this issue today while testing and paying attention to attachment search results. I have our index table set to automatically index content from any new posts on creation. This is working just fine for the posts, however, it is not indexing the attachments in those posts. I found that the attachments are only indexed if the index table itself is regenerated.

…..

Intermittent Bug With Number of Search Result Columns (Cards)

I also adjusted a bit the isotopic row calculation script, I’m not sure if that changes anything.

Unfortunately this had no effect. I do have one observation about this problem. I noticed that the thumbnail sizes only decreased if you completely closed the search field and ajax results followed by running another search on the same page. Every time you repeat that process the number of thumbnail columns increases. This does not occur if you run another search without closing the ajax results.

…..

The “See More Search Results” Button is Not Using Correct Font-Color Style on Mobile Devices When First Loaded

This is a weird little issue I noticed a long time ago. It is happening in the ajax results screen on the load more button (the button to load the next set of ajax results pages). I have custom stylized this button with css. I noticed that on mobile devices those styles do not properly apply to this button when the ajax screen first loads. The font-color displays incorrectly. But as soon as you press to go to the next ajax results page the css style works properly. This is a mobile-only issue, and I do not believe it’s related to my css. It must be a JS/AJAX problem.

…..

Linking Attachment Search Results to Parent (Linked) Posts (Core Integration)

Attachment to parent is not yet implemented, I postponed it to the upcoming minor/bugfix release.

Sounds good. Please let me know when this is integrated so I can remove the custom function we added in functions.php.

Btw, we finally got the other end of this working perfectly. All of our media items now automatically link to their parent-post pages in the media library. This is working beautifully with the function you previously provided for the search.

…..

Customizable Header in Settings Screen Date Filters

I know you postponed this one. I’m just listing it here for reference.

…..

Spelling Error for Synonyms Button

Just letting you know that the button/tab for the new synonyms functionality is misspelled. 😉

…..

QUESTIONS

A. I’m curious as to how the new synonyms functionality can be used to improve the search? What is its main purpose?

B. In your change-log you mentioned adding lazy-load functionality. Where was this added exactly? Does it apply to the ajax results? Is it activated by default?

…..

Issue and Question Regarding the Search Results Caching Feature and /asp_upload/ Directory

First the issue…

I noticed a few weeks ago that our search results cache was no longer writing files to /uploads/asp_upload/. This used to work, and I’m not sure why it stopped.

Now the question…

My understanding about this feature is that it caches common search results so that those results can be reloaded again without having to access the database. If this feature was turned off it would mean that every search would run a full query as if it were the first time, obviously utilizing the database.

We’ve run into an interesting engineering problem regarding this feature. Actually, it’s a problem common to all plugins that store dynamic data such as this in /uploads/. I mentioned earlier that we are doing a large engineering project here on our infrastructure. Part of that job has to do with segregating our static content from dynamic content. Our stack is based in AWS. A major objective of our project is to eliminate as many dynamic files as possible, as those files most be shared between all servers (it’s a load-balanced environment).

This particular feature for the search caching stores its files in /uploads/asp_upload/. In addition there is a dynamic css file stored in this folder (style.instances.css).

What I am trying to do is see if this information can be stored in the DB so that we can eliminate this folder completely. So long as this folder exists it must be shared between all servers, and while we can do this it is best not do for a variety of technical reasons.

I was wondering if perhaps the search results cache could instead be stored in the database. It would still have all the benefits of a cache, but it would avoid all these files needing to be stored in /uploads/. If this information were stored in the DB it would still avoid the need to run a fresh query for a search, therefore reducing DB usage.

I’m not as sure about the dynamic css file, but this too is a problem for the same reasons. I really need to get that over to either static file storage, or instead somehow have it store the data in the DB.

As I said, we can keep all of this if necessary in /uploads/, but it would be far better if we didn’t need to. This is why I am asking you about it, as I think changing this to the DB would benefit all ASP users. Avoiding use of /uploads/ is always beneficial.

I look forward to hearing your thoughts on this!

~ Michael