Hi Ernest,
I’ve copied below most of your responses (in italics) to make this easier for you to respond to. So this is in fact shorter than it looks!
Addition of Post-Format Filter for Default Format
A.
My mistake, it should be the name attribute, not the title:
Thank you for that correction. Changing it to name made it work!
C.
I guess you have the results limit set to 10, as it is by default. So the live results list displays 10 results at most. Whenever the ‘Video’ is added, the video post format posts should be displayed as well. That does not mean however, that those will be appended to the end of the previous results list (image and gallery), as this is a completely new search process with a different configuration – thus if there are more relevant video post format posts, those will be displayed instead, based on the ordering.
Posts with the video post format extend the potential results list within the search query. The database query will first check the restrictions, then organize the set of results, group them, then order them, then cut them off at the limit.
….
You were completely right about all of this! I hadn’t really paid much attention to the limits settings, and I should have. As soon as I increased them I saw completely different results during my testing. It makes complete sense now. Why didn’t I think about relevancy before either? That’s an important function in this search, and I wasn’t even thinking about it. Between the low limits and relevancy of the search, that explains why I was seeing confusing results.
As we’re building a large informational type site where search is extremely important, it made sense to set the limits much higher. I set all the ajax limits to 50 and the search result pages to 100. This made an enormous difference when I started re-testing, in a good way! I was able to easily see that the post-format filters are now working, in any combination I chose. =)
My only question here is, do you think it’s a bad idea to have higher limits in the ajax results for any reason? (keep in mind we are using the search results caching feature) I’m a fan of the ajax results (for convenience) and prefer to see higher numbers in those results rather than having to go to the actual search result pages.
More results, Results counter
It may actually differ, for multiple reasons. There is a limit set on this number, so when this is set to load more results it does not flood the live results list. Also, during the post-processing some results may be removed and may differ in the actual count. If the counter was to show the actual expected number of results after post-processing, it would have to post process all the results, then return the count, which may crash the server in many cases. (I have actually tested this on a somewhat bigger database, it was very accurate, but horrible performance/crashed the server) This number is the raw count of rows that matched the full query, before the post processing, adjusted by an approximation of the potentially removed results. The results page may also have a separete query adjusting the final results count, that unfortunately can’t be affected.
…..
I was actually incorrect in my original question, as I said this number never matched the number in the ajax results. This is incorrect because the number in the more results button reflects the number of results on the search results page (not what’s in the ajax results). I also now understand that the limits are set differently between the ajax results and results pages (which would always make this number different from what’s in the ajax results). Am I correct?
Your explanation about how this number is generated is interesting. There’s a lot more going on here behind the scenes than I realized. Thank you for sharing this with me, as I like to have a general understanding of how everything works.
The part of your comments that stood out to me was the part about not wanting to crash the server. 😉 We’re building a very large platform here (a social media site) that will ultimately contains millions of posts and possible search results of every kind. I can easily see how the power of this search could quickly overwhelm a server. This is something I want to take measures to prevent.
We’re building our site over at AWS (Amazon Web Services), and the database is using RDS with Amazon Aurora. It’s a database cluster with one DB for reading and one for writing. The good thing about this setup is that we can increase the resources of the DB at any time. I believe we have a robust and flexible infrastructure, but I still want to be careful not to over-stress things (like overwhelming the DB with search queries). If you have any advice or tips for me along these lines please let me know.
Image Caching Not Functioning in Conjunction with WP Offload S3 Plugin
“I found this setting under General Options -> Image Options -> Featured Image Size Source”
This actually works both ways, if the image caching is turned off, it will simply return the image defined, otherwise it will pass this image to the crop algorithm.
I think you should simply turn off the Crop images for caching? under the Cache settings submenu. If the offload cache plugin has a filter activated on getting the attachments function, it should automatically overwrite the image urls, and return them that way.
…..
That’s interesting that the image source size setting works with or without the image caching. I didn’t realize that. Pretty neat!
I had actually already turned off the image caching last time. Most of what I wrote about this was explaining the reasoning behind it. Frankly, the most important reason for us not to use this is so that our images are served directly from S3 (this is an important part of our disk space saving strategy).
You’re correct about the image URLs. They are being overwritten by the WP Offload S3 plugin and the search is indeed using those URLs. This is exactly what we need it to do.
I just tested the Featured Image Size Source setting, as I wanted to see if it would work with S3. I’m happy to say that it is working! Whatever image size I select is being loaded in search, and it is retrieving it properly from S3. I even found this setting was working with the filters we’re using for returning images for categories and tags (we wrote a custom script for this, it returns the image from the most recent post in the subcategory or tag archive).
So it looks like we’re in good shape on this one!
Linking Attachment Search Results to Parent Posts
Thank you for the feedback, I will definitely add this to the core as an option. I will think about the fallback feature as well.
…..
It’s my pleasure Ernest. You’ve been so amazing working with me on issue after issue. I really appreciate it, and am glad you’ve also found my feedback and suggestions useful.
I’ll watch for when you add this feature to core, and then I’ll just remove the custom filter from functions.php.
Attachments Not Displaying When Using the Index Table
I believe I know why. Someone else reported a similar problem with some debug information. There is some sort of issue with the table aliases whenever the attachments are selected. It appears to affect some database versions/configurations only, as it worked on my end for some reason, but it actually should not, as the table alias is indeed incorrect in the code. This will be corrected as well in the next release.
…..
Well, that is good news that you found the source of the original problem I reported. I definitely want to use the index table for returning attachment search results. It’s more efficient and should greatly decrease the number of DB queries.
Unfortunately I cannot get the attachment results working at all any more! I’m not sure if you realized this from my previous message. At this moment I cannot generate attachment search results whether using the normal search engine or the index table. I think the problem may be related to our use of WP Offload S3. Perhaps it is somehow preventing the search from being able to find the attachments.
If I go into our search right now and limit it to only display attachments (we call it media), there are no results at all. This used to be working for us, and suddenly stopped working. The only thing I can think of that changed recently is that we started to use WP Offload S3. This must be the source of the problem.
Can you help me to troubleshoot this? It’s pretty easy to test with the WP Offload S3 plugin. You just need an S3 bucket to test with, and they are free for small amounts of data. You could easily test this on your end and see if it’s the problem.
I definitely need to get the attachments working. I hope we can figure it out together.
…..
Thank you again for your continued help. You’ve seriously been amazing!
~ Michael
-
This reply was modified 6 years, 2 months ago by
Michael Samson.