Hi Ernest,
It’s good to hear from you, and I certainly would not have wanted you to work on your vacation! I very much appreciate that you take the time to review my lengthy lists of items and write back on them one by one. I know how much time this takes and it shows how much you care about your plugin and clients.
…..
Issue and Question Regarding the Search Results Caching Feature and /asp_upload/ Directory
This is available now within the latest release 4.13.4. Under the Cache settings submenu, you can choose the database as the cache location. It will use the wp_options table for query caching.
I’ve updated to the latest version of ASP and activated the DB caching feature. Thank you so much for adding this!
My question to you now is, how do I know the caching is actually working? Where in the database tables can I see the data? Also, do you believe that caching in the DB will improve search results time?
…..
Intermittent Bug With Number of Search Result Columns (Cards)
Thank you for the video, that looks really weird indeed, but at least I know what it looks like. Still, I have no clue why, to be honest – but I think there is hope. Usually, when I can’t find a cause of a problem, the best way is to bypass it somehow.
In this case, I think adding a min-width attribute via a custom CSS to the result elements will prevent the shrinking effect.
It was a good idea to try this, but unfortunately it did not work. There were a few problems. The first issue was that if you set a hard limit on the size of the search result cards they will start wrapping incorrectly to extra rows. This happened viewing additional search results if memory serves me. The problem is that the plugin normally calculates the size of the cards so that they perfectly fit in a row. When I tried setting a min-width it prevented this from working properly. The other issue was that this will not work on smaller devices. You would need to use media queries for every possible device size. Otherwise you end up with cards that are too large for small devices. Simply put, the card widths need to be automatically determined to fit properly.
So this sets us back to having to determine the cause again. I’m still amazed you don’t see anything like this on your end. Are there any particular tests or places to look at that may help us determine the cause?
…..
Lazy Loading Issue
Thank you for letting me know. I suspect that another script may have a different version of the lazy script loaded, and that may cause the problem. I will go through the script to see if there is a version check feature in it. I will probably rename a few functions to move them to a different scope, that will do the trick.
It’s possible that we had a script conflict, but I don’t know of any other place we are using lazy loading. I figured this didn’t work for us because we have so many custom scripts that modify what images you see in search results. Then again, there may indeed be a problem with this feature.
…..
Avatar Image Size Used for BuddyPress Activity Search Results
I will have to test this in more details with the isotopic view.
I am planning to implement a different isotopic view, where the image + title + description will be available at the same time, sort of a card-view. With the current view, the main issue is the space, and that it is centered around the image. I think, that a few minor changes to the activity results + this view will be a better output for these types of results. I will look into this for sure.
What I previously wrote:
Even if the activity results were labeled as activity, they would likely display in search results before the user result, making the user result difficult to find. More importantly, I realized that the activity results are completely undifferentiated from each other. This is really the biggest issue with them. All of the activity results for a single user are identical, displaying only the user avatar and name. There’s no meaningful difference between them and thus no reason to click one or another. The only way they would be usable is if they included the actual activity item text. I highly recommend this to you as an improvement, as without this you see endless identical search results.
Please do me a favor… whatever changes you make to the Isotopic results, please make sure that the current design/view options are maintained. I’m always in favor of new display options, so long as the original options are maintained. For the most part the isotopic design we have now is working very well for us, and I don’t want to disrupt that.
With that said, your idea above sounds interesting. I would considering adding back the activity search results, but only if they were clearly different than the user search results. My idea above about including the actual activity text was a good one. You would just need to limit the number of words. Then again, it may not be wise for me to add this back because we will have so many activity results on our site. Either way, I think this gives you some good ideas for improvements, even if I don’t need them.
…..
Date Filter Bug
I believe the post_date_gmt is to store the date in GMT timezone, to make WP Cron jobs and daylight savings calculations easier. Because of that, I am not sure if that is a problem or not, possibly not, if you are a few timezones away of GMT.
Now, I think you should try a few tests here. Try adjusting the post date filter so that a post should come up according to the date, then check the post_date column on that same post in the database. Now also check the post date in WordPress (maybe it is displayed in the editor?), and if there is a difference, then it is very likely that somehow the dates are adjusted by a certain value.
If there is a mismatch, then I’m guessing that there might be a variable I am not aware of – perhaps if the server timezone and the wordpress database timezone differ, wordpress may still store the post dates in the server timezone (as PHP will return that date), but then compensate it with the timezone difference when displaying. This way, the displayed date and the stored (post_date column) are different.
This is just a theory though.
I had a thought that may be a good workaround for this problem. What if you made it so that the date range for the current date could have an offset (like one day into the future). The date range in the settings (front-end) would display the current date, but on the back-end it would use the offset time. This way if there are problems associated with time differences (whatever the cause), they can be worked around. It’s kind of like a time buffer to ensure that today’s date includes all of today’s posts. In order to make this work you would add an additional option where the user can select an offset (buffer) time in hours. What do you think?
…..
Found a Spelling Mistake in the Plugin
I found a small spelling mistake in the plugin. If you go to the Relevance Options tab and then look at the button below, it says “estore Defaults” instead of “Restore Defaults”…
…..
Customizable Header in Settings Screen Date Filters
Just listing this here so it isn’t forgotten about… ?
…..
I just looked over all the items in the posts above, and I think this is basically everything left that we’ve been discussing. We’ve managed to get a lot of things accomplished thanks to you!
~ Michael