Conversation
|
@gchtr I know you're going to scream, but having just spent time with #2160 and #2167, I'm thinking of
... ? I realize that's piggy-backing on the corresponding WordPress function that isn't matched by Posts. Had you given that any thought? |
@jarednova Naaah, that’s fine 😄. To be honest, I didn’t think of this at all yet. But I like it! Let’s get @acobster’s opinion, before I’m going to change this. |
|
@jarednova @gchtr I like it! It's more consistent and keeps the surface area smaller. |
acobster
left a comment
There was a problem hiding this comment.
Main thing left to do is to convert consolidate both methods to ::get_post_by(). Also just need to make sure we take the new/correct return value into account.
jarednova
left a comment
There was a problem hiding this comment.
@gchtr looking good! There's a discrepancy between the test results and what I think we're expecting. Right now the behavior with multiple results is ...
get_post_by('slug'=> returns the newest post based on WP's default sort behaviorget_post_by('title'=> returns the oldest post based on the behavior inget_post_by_title
I think these should be consistent in their behavior (lowest ID? oldest? newest?). Standard use case I imagine to be that a dev is trying to get something like privacy-policy. You could imagine another author (for some stupid reason) using this as a slug or title for a future post which would then break the linkage. Therefore, I'd think it makes sense to always return the oldest match.
Happy to take a whack at this, but wanted to run that by you first
|
@jarednova Yeah, I remember reading that in the function description, but then the tests ran successfully, so I thought it’s fine like it is. Apparently it isn’t and I must have missed something. Thank you for catching this! I’d be happy if you could take over to solve this 👍. |
|
np! will take care of this in the next couple days |
|
@gchtr this is now ready for your final review! |
When we check for the date, the ID of the post we expect to be returned needs be higher than the ones that should be ignored in order for the test to run correctly
This makes it possible to order by anything we want
|
Thanks @jarednova for working on this! Your changes actually pointed me in the right direction and made me rethink how we should handle cases when multiple posts are found. I created another pull request in #2195 that we need to discuss first. |
2.x Improve Timber::get_post_by()
# Conflicts: # tests/test-timber.php
# Conflicts: # docs/v2/upgrade-guides/2.0.md
This comment was marked as outdated.
This comment was marked as outdated.
@jarednova Yes, this one’s ready! |
|
We're good here! The test failures are related to static analysis and a failure in an unrelated issue in the 2.x branch |
Ticket: #2152
Issue
See #2152.
Solution
AddTimber::get_post_by_slug()andTimber::get_post_by_title().Add
Timber::get_post_by().I chose
post_exists()when searching for any post type andget_page_by_title()when searching for specific post types as the functions to retrieve a post by post title, because they seem to be the most direct and performant ones.Impact
Closes a gap in what
Timber::get_post()can’t (and shouldn’t be able) to do in Timber 2.0.Usage Changes
Instead of
Timber::get_post()with a post title or post slug, developers should use one of the two new functions.Considerations
The two functions always run database queries to get post IDs, which got me thinking about performance. When we use
::build()to create an object, could we eventually usewp_cache_get()andwp_cache_add()in the future to create an internal object cache for Timber objects?Testing
Yes.