Hi Ernest,
It’s great to hear from you! My responses below are long, but only because I copied in many of your responses (in italics) to make this easier to follow. I’ve also double checked this thread to make sure that every single item is listed here in this post, so there’s no need to look above. 😉
My apologies, I completely forgot to answer. I usually take regular shorter tickets first, and answer yours once I got the time to do so. Recently I got a bit more requests as usual + I had to migrate the server to a newer ubuntu distribution. Nevertheless, I should have been more careful checking which tickets were left unanwsered.
Don’t worry about it, though I appreciate the apology. I’ve been so busy these past few weeks that it honestly didn’t make any difference. This is the first time I’ve had since my last post to focus on ASP.
Your support is absolutely amazing, and always has been. Thank you for going through and responding to each and every issue as you always do. I’m hopeful that we can slim this list down and solve all the issues in the coming weeks.
…..
Avatar Image Size Used for BuddyPress Activity Search Results
I see, this should be fixed by core. Until then, can you please try this custom code:
I agree this issue should be fixed in core. If you could include it in the next release would be great. I tried your patch but it unfortunately didn’t work. Instead of seeing the full size avatars I’m now seeing no images at all.
…..
Date Filter Bug
Well, I honestly don’t know. Can you please check if there is any difference in the wp_posts table between the post_date and the post_date_gmt fields: https://i.imgur.com/AEWYG9b.png
I don’t know if that makes any difference though.
This was a good suggestion. I’ve attached here a screenshot from my posts table showing both the post_date and post_date_gmt columns. Not only are they showing different times, they are showing different dates. The post_date_gmt column is always one day ahead of the post_date column. This must be related to this problem. Any idea why these columns are different and what we can do to resolve this?
…..
Featured Image Source Size Not Working in All Situations (Attachment Results)
COMPLETED
The most recent update (4.13.2) adresses this issue. It should be hopefully fine now.
When I originally reported this it was related to the image size being used for attachments and tags, which was not using the image source size setting set in ASP. The tags issue has to do with our own custom script and we are taking care of this on our end. I just rechecked to see if the correct image size was now being used for attachments, and it is. The attachment images are now loading the image size set in the ASP settings. I just wanted to let you know that your fix worked for this. Thank you!
…..
Attachment (Media) Images are Not Being Automatically Added to Index Table on Post Creation
I recall addressing this issue as well. The biggest concern was, that the recent releases support file content indexing, which can be a difficult task, especially for large files. That combined with the file upload process is a disaster to handle, so I have decided to completely remove the automatic indexing upon file upload, and instead enabling a 5 minute cron job. That way, newly added files are indexed at a slower pace, keeping the server stable.
At the moment I can’t reliably test that normal posts are being automatically indexed because of the date filter problem I’m still having. If I go and add a new post right now it won’t display in search results until the following day (so I can’t be sure it was added on post-creation). This is something I want to re-test once the date filter problem is resolved.
Regarding the auto-indexing of attachments, I agree with you. This could especially be problematic on a site like ours, where we will have huge numbers of users all uploading media at the same time. We even have a gallery post-format where one post could have many images. If all this media were indexed on upload it would overwhelm the site I think.
I like that you added a periodic cron-job specifically to handle indexing of attachments. But I am wondering about that 5 minute interval. Our site is a social media site with lots of media upload functionality. We could have ultimately tens of thousands or more users all uploading media at the same time. I don’t know how the cron job works, but I think running it every 5 minutes on our site may be a bad idea. I really need you to tell me.
Perhaps you should consider making the cron frequency a setting (just like you can do for normal posts). So you could say to index attachments every hour, or any frequency that makes sense. Do you like this idea?
On this same subject, do you think we should even be auto-indexing posts? Keep in mind we are building an enormous site that will have huge numbers of new posts every hour and day. Is there a possibility that auto-indexing will cause problems for us? Should we only be relying upon cron for this?
…..
The “See More Search Results” Button is Not Using Correct Font-Color Style on Mobile Devices When First Loaded
Okay, I believe I see the problem here. The custom CSS you use, has an ID selector ‘#ajaxsearchprores1_1’. I am guessing, that on mobile devices this ID might be different, as in some cases themes use multiple boxes (especially in menus), and the plugin auto-detects duplicate
nodes, and tries to fix the IDs. In that case, the actual ID of the element becomes ajaxsearchprores1_2, thus not matching the CSS selector.
The reasoning behind this whole ID thing would be very complicated to explain.
Long story short, try this modified version of custom CSS instead:
The #ajaxsearchprores1_1 ID is not the cause of this problem. I have checked and the ID is present on both desktop and mobile devices. I also know this can’t be the cause because I use that ID on every single css selector I am customizing in ASP. If that ID were not present then none of my custom css would be functioning on mobile, and this is not the case.
I have a special diagnostic tool that allows me to look at the DOM on mobile devices. It’s actually an iOS app that I use in cases like this where the results on mobile don’t reflect what we see on desktop or when emulating mobile. I noticed something strange when looking at the load more button.
I’m seeing this:
a {
color: rgb(66, 139, 202)
}
As soon as I disabled this above the color of the text when back to my css settings. So I think this is related.
Whatever is causing this only affects the load more button text when there are more ajax results to be displayed, so another words where this is a number in parenthesis next to the button text. In cases where there are no additional results to display the button text is using the correct color.
This isn’t that important an issue, but there is something weird going on with this. The issue isn’t related to my css.
…..
Index Table Cron Options
I recommend setting this option below the frequency of new posts. So if you are adding a few new posts every day, then daily is sufficient. New posts are also automatically indexed (enabled by default), this option is mostly for redundancy in that case. In the recent update I also lowered the number of files to be indexed per request (to only 1 per request), when the file content indexing is enabled. In that case, the cron is automatically enabled, and set to 5 minutes interval (or not changed if it is lower).
One cron request usually only takes a few seconds with the default options, basically it is the same as one request when you generate the index table, so overlapping is not really possible. PHP also hard limits the request times, so that should not be an issue.
This relates to what I said in the other issue above about the attachment indexing. We are building a huge social media site that will ultimately have millions of users and enormous numbers of new posts every day. What do you recommend for us knowing that we will have huge numbers of posts? Should we disable the automatic indexing of new posts on creation? Should we set the cron job to a greater interval? Or is it good where it is set now (every hour)? I want to make sure that new posts make it into search as quickly as possible, but without overloading our database or servers. I really need your advice on all this.
You mentioned the php limits, which also raises a concern. How will the indexing perform when the database becomes huge? We can’t have it running into php execution time limits (we currently have that set to 5 minutes for single php requests). I would think you built into the indexing a chunking type process, so that it is made up into many small batches and can’t therefore run into php time limits.
…..
I’m curious as to how the new synonyms functionality can be used to improve the search? What is its main purpose?
I would say that for large databases this is useless, as I highly doubt there is missing information, rather there might be too much redundant information.
I think we fall into this category. Our site is going to be huge and the search is going to return a lot of results. Our focus later will likely turn to making the search more relevant.
…..
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?
I have added this feature, because multiple customers requested it, where they used the auto-populate feature with over 500 initial results, where loading over 500 images at once became an issue.
We’re using isotopic results as I think you know. We also have lots of images being displayed in the results. If the images are only being loaded when each ajax page loads this is a good thing. It will keep all the images from needing to load at once as you pointed out. So long as there aren’t any loading problems this is a good feature for reducing loading times. I’m glad you added it!
One thing you didn’t answer here was, is the lazy-loading activated by default? Or is this a setting I need to turn on?
…..
Issue and Question Regarding the Search Results Caching Feature and /asp_upload/ Directory
I like the idea of using the database as a cache method, but currently this may require major modifications on the cache wrapper class. It is one of the oldest features, and it is not ready for easy modifications via API.
It should not be a very hard feature to implement though. I will try to add an extra cache table with an index, and a simple switch to the cache page to choose the method. I have noted this for the upcoming release, so it should be there.
Firstly, you need to know that our search results caching doesn’t appear to be working at all. The only file I see in the /asp_upload/ directory is style.instances.css. There are no cached searches at all. This was what originally prompted me to write about this.
The other reason I wrote about this was to see if we could completely eliminate the need for the /asp_upload/ directory. If we didn’t need this it would be one less directory we need shared between all the servers. We’ve engineered all of this at AWS, but the fewer dynamic folders like this we have the better.
The problem is that in order to eliminate the folder we’d have to eliminate both style.instances.css and all the search cache results. Storing the cache in the database would solve the cache files part of this. But I don’t see how you could eliminate the dynamic css file.
Storing the cache in the database is frankly a great idea on its own, I think. I’m glad you liked the idea. It would be awesome to see this in the next release. And yes, there would have to be a choice in the settings as to which caching method to use, files or database. As I said above our cache isn’t working at all right now with the file method. I do hope that this new DB storage method will work for us.
…..
Database Character Set and Collation
It is left like that intentionally. It does not really matter in this case, as the tables are not used for any other purpose, it should be fine.
Ok, so long as you think it won’t cause us problems. We have a number of plugins that are using the latin collation instead of utf8mb4. I just wanted to make sure you were aware.
…..
Intermittent Bug With Number of Search Result Columns (Cards)
I will try to trigger this somehow, this information might actually help, as I know where exactly to look. I cannot replicate it though.
I just tried to replicate this issue and didn’t see it. I ran a number of consecutive searches without going to new pages and this time the cards remained the same size. I’ll keep an eye out for this problem and will let you know if I see it again.
…..
Customizable Header in Settings Screen Date Filters
Just listing this here so it isn’t forgotten about… 😉
…..
Linking Attachment Search Results to Parent (Linked) Posts (Core Integration)
COMPLETED
…..