Hi Michael,
Avatar Image Size Used for BuddyPress Activity Search Results
Indeed, I have made a mistake in there, the $v variable should have been $r. This version should be okay now:
Date Filter Bug
I beleive 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.
Attachment (Media) Images are Not Being Automatically Added to Index Table on Post Creation
It should not be an issue, as the cron job is always using the index limit (25 by default), and 1 for attachment contents. This means, that no more than 25 posts and 1 file (only the content) are indexed at one execution. This can be even lowered here:
And if there are no items to index, then nothing happens. The plugin does not re-index items, that is done automatically, when a post is edited. So this cron index feature only applies to newly created items.
The “See More Search Results” Button is Not Using Correct Font-Color Style on Mobile Devices When First Loaded
That is a very generic rule, something that the theme would use as a default color, but in this case I hihgly doubt that. More interestingly, that rule should be immediately overwritten by the rule you have defined, as it is a much higher specificity CSS rule.
Is there a source file associated with that rule? Chrome mobile console has this feature which tells you where it comes from: https://i.imgur.com/D4raitd.png
With that, you should be able to pinpoint which file is adding that rule.
I find it more interesting, that it is applied after an action and that a different rule is in effect. The only possible explanation is, that a class/ID is changed after the first click, and because of that, your rules get ‘correct’, and apply. But that means, that the initial rules should be incorrect, which does not seem to be the case. And the classes does not change either, at least not by this plugin, that is for sure.
Anyways, I still recommend trying my version of the rules, you can even change the .asp_r class selector to .asp_r_1 if you want to only target the first search instance.
Because there are less specific rules, it might be easier to maintain, and since you have the !important modifier on all of them, they surely apply above the default plugin CSS rules.
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?
You can turn it on under the Compatibility & Other Settings -> CSS & JS Loading panel: https://i.imgur.com/tf1zRjg.png
Issue and Question Regarding the Search Results Caching Feature and /asp_upload/ Directory
It is very likely a permission/ownership issue, although the CSS files would not be there either, as those use the same WordPress file API for creation. I honestly don’t know why those files are missing.
There is an option on the back-end that forces the CSS files to be inline within the site header, in that case I believe nothing will be used from the asp_upload directory: https://i.imgur.com/Dt9Fazc.png
However you still need a cache solution that would get the inline CSS from the header and move them to it’s own CSS files. Most cache plugins do that, as far as I know.
Another possibility is, that once you finish styling the plugin, you simply lock down the directly, copy the CSS file contents to a custom CSS file, that is enqueued on the site.
Then using this custom code you just simply de-queue all the front-end styles of the plugin: