Howdy_McGee

Hmm, weird. urirank comes back as some kind of Traffic Ranker. Who knows what kind of stuff those botnets are trying to sniff out / info to harvest.

Botnets, the Rogue Wave of the internet.

As opposed to a cronjob the update the option every day. I also tried to explain a bit of autoloading and the difference between Options and Transients.

I made a note about Transients though as that is an alternative vs him mentioning a cronjob. Either is going to be saved to the options table anyway, but I feel like Transients would be way less of a pain than a cronjob. Plus the docs suggest Transients are optimized for object caching, but as you mentioned the performance boon is almost certainly negligible.

I did update the answer to put a bit more emphasis on just using WP_Query. It's always difficult to balance answering the question vs addressing the underlying symptoms. I know when I ask questions I usually abstract it to condense the issue of what I'm acutally doing. I'm still not sure about timezones though.

Sounds like you got the output buffering working

Are you still running into issues with the script?

Also, I mentioned this in my answer as well, but I wouldn't save the output for flexibility sake and just process the output based on the post ID or post object during the page request.

@BlueDogRanch Are you planning any 3rd party object caching like Redis or something?

I do see your point about it being a micro-optimization.

I'll see if I can edit it later today for clarify, but I do think the WP_Query would be inefficient given the infrequency of it's need (I guess?)

Finally, it's not as if the cached post would need to be updated multiple times either. A post a year ago is a post a year ago.

Calling get_post() on the post_id should also use the modern object cache just as well.

It looks like wp_date() does account for timezones though by default.

That being said, I'm terrible with dates and timezones so I did not account for that.

One of the core problems is that they don't necessarily want the exact "one year ago" post, because that may not exist, which increases the actual request query.

You're right, I added the ingredients as to not bake the whole cake, that's why I put the cache section close to the section that does the post check - but it could use an edit to make that more clear. Otherwise, I would need to group everything so that if the cache is invalid, it does the query etc.

The nice thing about breaking it out of a normal WP_Query loop is you would be able to put the bulk of the functionality into it's own callback so you can separate business logic and display logic. Whereas setup_postdata() will grab the cached post if it's in cache, or it will cache it since there's only 1 post to display.

@TomJNowell I see that I'm not doing a conditional check in my answer (to check for a cache), but caching the post object is not going to invalidate it after midnight. A standard query at every load when trying to determine X posts back just seems inefficient instead of doing it once and caching the result

Good luck w/ it and take care!

Well, unfortunately I gotta hop off for a bit but I'll be back on tomorrow if you're still having issues with it.

You should be able to use it like ob_start() to begin "tracking" output and $foo = ob_get_clean() to get the tracked output in a variable.

It's all volunteer run too, so participants come and go.

Hopefully, in time, and as you do more programming it will make more sense but we're here if you ever have questions too. We try to be a helpful bunch, but this chat is less active than say the official web irc or some of the slack instances.

The WP_Query pulls X posts (posts_per_page value) before the provided date. Where the dateDiff is the piece that actually narrows the results to 1 post within 7 days.

Well, the WP_Query pulls in more posts than it should. That's why the $dateDiff portion of the code exists.

Now that you have the one post, you don't need to loop or query any more posts, you just need to setup that one post so you can use template tags such as the_title().

Try this -> hastebin.com/share/abukiqesar.scss

The loop from your question edit?

So, you're using $query in the foreach(), so the $query = WP_Query just needs to exist above that.

You'd just need to define $query, as the WP_Query object, above where you're using it. PHP works from top to bottom like a book.

I did run and test the code in my answer, so it should work "out of the box" so to speak. You would just need to update how you're saving and displaying the results.

I do wish this chat had an easier way to share blocks of code - multiline :/

get_posts() uses WP_Query just as well behind the scenes - so it's practically the same thing.

I mean, you could if you wanted to. I'd use the loop from my answer but clearly I'm bias :)

I think so, you don't want to do anything if $post_to_display is NULL, and if( NULL ) is false, so it should skip that entire section if $post_to_display is null.

So, you do need a WP_Query somewhere. If you have a WP_Query and you didn't add it into your question today, you would var_dump() the $query variable after the WP_Query call

In the code you've edited into your question today, it's missing a WP_Query

wordpress.stackexchange.com/a/428153/7355 at the top $query is the result of WP_Query

You do need to use the WP_Query at the top of my answer, or modify the WP_Query

O

Where's your WP_Query?

If you use someting like this, it will print and format the query variable so it's easily readable: printf( '<pre>%s</pre>', print_r( $query, 1 ) );

Does the WP_Query in your code reflect that?

Or whatever date is being requested

In theory, your WP_Query output request property should look something like this wp_posts.post_date < '2024-01-18 00:00:00'

Brings us back to $query, or the found posts, being possible issues

That makes sense. If the loop couldn't find a post to work with, it would be NULL

Remember that you're also in a loop too - so if you're die() or exit() it may not be running the full loop when you're debugging this issue.

It's either that or the provided date formats are invalid