Hi Michael,
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.
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.
Featured Image Source Size Not Working in All Situations
The most recent update (4.13.2) adresses this issue. It should be hopefully fine now.
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.
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:
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.
I’m curious as to how the new synonyms functionality can be used to improve the search? What is its main purpose?
It is mostly aimed at cases, where the ‘thing’ the user is looking for may not contain all the information (from the search perspective), and it repetitively happens for most results. There is a feature to add ‘additional keywords’, but it only works for each post/result. This feature is global for all indexed posts.
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.
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?
It applies to isotopic results as well. Yes, images on subsequent pages are not loaded until the page is activated. Also, if the result list
extends beyond the viewport, then it also activates automatically.
Unless you have the number of live results per request set to a high number (like above 50), there is not much difference. 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.
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.
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:
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 🙂