Conversation
# Conflicts: # docs/guides/posts.md # docs/guides/terms.md # lib/Twig.php # tests/test-timber-twig-objects.php
I had the case where I needed to hide the last pages of pagination (the very oldest posts). I found the `end_step` (not documented anywhere) controlled how many pages are shown at either end of the pagination range. Additionally I was not able to set this to zero to hide the pages completely. My proposal is to allow zero pages to be shown at the ends of the list. Also to enable different values for the start and end. The start value defaults to the same as the end value for backwards compatibility.
2.x – Rename "Getting Started Theme" to "Learn Timber Theme"
Better control over Pagination stops
#2301 Keep Twig native `filter` parity
OK, done and merged in as part of this PR! They are inter-dependent, so one of them has to be done first. I figured I'd make that the smaller one. |
|
@gchtr @jarednova I'm calling this ready for review! |
|
Excellent, awesome to hear @acobster — I'll add to my queue for the week! |
There was a problem hiding this comment.
@acobster we've already been through this, so I didn't see much else but a few docs things for you to check out.
One last 🔧 /question is noticing the number of Image($image_id) that are now supposed to be called with Timber::get_post($image_id). I'm wondering if we should have a Timber::get_image() (or Timber::get_attachment()) for these. Forgive me if this has already been discussed/resolved and my brain is just melting. (If we do this, let's mark as a @todo and tackle in a seperate PR so we can move forward w the merge here)
@jarednova Yes, we discussed this in #2316 (comment) and previous as well as in #2178 (comment). My take is: Using |
Co-authored-by: Jared Novack <jarednova@upstatement.com>
Co-authored-by: Jared Novack <jarednova@upstatement.com>
|
I think as long as we say something like:
...in the docs for |
Yes, sure! |
…manually Favoring changes from 2.x-posts-api
2.x Update function signature for Term::posts()
|
@gchtr @jarednova OK, I believe that's all the bookkeeping stuff for this PR. Are we good to go? 😬 😅 |
|
Nothing but green checkmarks over here! |
These are just aliases of ::get_post(). See also discussion in #2316, specifically: #2316 (review)

Work in progress final port of the Posts API to use Factories under the hood.
::get_post[s]()API to use FactoriesTerm::posts()Post::build()methodPostQuery::__construct()to only accepting aWP_Queryinstance (with no wrapping it in an array)Post::__construct()protected, annotateWP_PostargTimber::get_attachment_by()wp_check_filetype()Attachment::__construct()has an option to pass an array like['ID' => 123]...are we good to drop support for this? Otherwise we would need to handle this special case inwe need to support this for ACF integration, so add a special case for this in::get_post().::get_post()(orPostFactory?)@expectedIncorrectUsageis failing randomly on those two tests...y tho.Attachment::get_pathinfo()andImage::get_pathinfo()and useAttachment::pathinfo()only to be in line with other post method names.merge_defaultoption in::get_post[s]()