Next and previous paginator buttons #58
Replies: 4 comments 4 replies
-
|
Thank you for bringing up this topic - I agree it makes sense to add first/last and previous/next buttons to the pagination. Reading over the prior discussion and looking at the example code, I see there are several aspects to consider:
There's a kind of hidden aspect to this also, because the pagination elements are handled by a script on the frontend, which doesn't have any templating capability - so that can limit what kind of template syntax is possible. The rendered pagination should be fairly simple and static, so that the script doesn't need to know how to loop and dynamically re-render parts of the pagination. Or at least, nothing too complex. So far, I think all of the above can be achieved. ..OK, I'll look into this, starting with the simplest features and build up to the advanced ones. Oh, there's already an issue I started on this topic: I'll update that overview, and let you know when things are ready for testing and feedback. |
Beta Was this translation helpful? Give feedback.
-
|
I think you've nicely mapped out the main new functionalities we'd want to support with a revamped pagination system. Thanks for condensing that brain dump! I was going to add a few notes to prompt your development but it turned into a new brain dump. Sorry! 😅 As far as syntax execution, I had a couple of thoughts on this today:
Considering all that, I decided to revise my syntax brain dump: <!-- Defining a unique loop name for pagination (and maybe other things eventually?) to reference -->
<Loop type=post paged=5 loop_name=my_loop>
Loop contents
</Loop>
<!-- Display types of pagination buttons. Note that all of these would output the same thing -->
<Paginate name=my_loop> <!-- Manual approach -->
<PaginateButton name=first_page />
<PaginateButton name=previous_pages count="1" separator="..." />
<PaginateButton name=current_page />
<PaginateButton name=next_pages count="1" separator="..." />
<PaginateButton name=last_page />
</Paginate>
<Paginate my_loop> <!-- New recommended shorthand default -->
<PaginateButton default />
</Paginate>
<PaginateButtons /> <!-- Deprecated -->
<!-- "Looping" through all pages. Note both of these would display the same thing -->
<Paginate my_loop>
<PaginateButton all_pages />
</Paginate>
<Paginate my_loop>
<PaginateButton previous_pages />
<PaginateButton current_page />
<PaginateButton next_pages />
</Paginate>
<!-- Changing the content within pagination button -->
<Paginate my_loop>
<PaginateButton previous_button>
<i class="chevron-left"></i> Previous Page
</PaginateButton>
<PaginateButton all_pages>
Page <Get loop=current_page /> (Or just <Field page_number /> though it's not really a field)
</PaginateButton>
<PaginateButton next_button>
<i class="chevron-right"></i> Next Page
</PaginateButton>
</Paginate>
<!-- Some funky chunky use cases by a guy who doesn't know frontend stuff yet -->
<Paginate name=my_loop>
G
<PaginateButton name=previous_pages count=5>o</PaginateButton>
<PaginateButton name=current_page><strong>o</strong></PaginateButton>
<PaginateButton name=next_pages count=5>o</PaginateButton>
gle
</Paginate>
<Paginate my_loop>
<PaginateButton previous_button />
<PaginateButton previous_pages count="3">
<span class="gallery-pagination">•</span>
</PaginateButton>
<PaginateButton current_page>
<span class="gallery-pagination active">•</span>
</PaginateButton>
<PaginateButton next_pages count="3">
<span class="gallery-pagination">•</span>
</PaginateButton>
<PaginateButton next_button />
</Paginate>
<!-- A load-more button -->
<Paginate my_loop>
<PaginateButton load_more />
</Paginate>Couple ideas I had that differed from what Julia and I had thought about in 2022:
The one thing I haven't figured out in this approach is how we'd put wrapper tags around pagination items as Julia seemed to suggest with this: <Loop type=paginate_pages>
<li><PaginateButton type=page>Page <Get loop=count /></PaginateButton><li>
</Loop>Anyway, there are some architectural thoughts for you to use or not use as you please. I'm already rethinking the ideas (we probably don't need the |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for your thoughts. I think I need to get started with the basic functionality and re-familiarize myself with how the pagination works on the server side and the frontend, to understand better what is possible to support, and how to implement it so that the syntax is intuitive for the user and not too complex internally. Also, we'll need to maintain backward compatibility while adding new features - or deprecate the old way entirely. One thing I realized while reading your comment, it might be tricky to support pagination before a loop because at that point the number of pages is unknown. Internally, it could render a placeholder (in PHP), then come back and fill it in later (in JavaScript) after the loop is created. ..I was thinking the JS side would need to understand how to render all the pagination parts, which seems difficult, but actually the PHP side could render it the same way after the loop, then pass the whole thing to the JS side. OK, that sounds do-able.
What makes it tricky is that the pagination is rendered on the server side initially by PHP; then some parts of it get re-rendered on the frontend by JavaScript. Within the latter parts, no dynamic tags are supported unless we implement them on JS side. For example, the Well, I'm glad for your brainstorming and writing down as many features as you can think of. To be able to support many of these ideas, I think the whole pagination feature needs to be re-structured on both server side and frontend. A possible solution is to pass the pagination template(s) to the frontend, then whenever the current page changes, the JavaScript side can send them back to the server along with the AJAX request to render a new page, so that the pagination can be re-rendered by PHP. That way, dynamic tags like Ideally, what I'd like to do is to cook these ideas down to their "primitives", so that I don't have to implement all the features specifically - and instead let the user build their own variations. Eventually, I hope we can provide general-purpose dynamic behaviors (like htmx and alpine), so that users can build their own pagination entirely, or load more, infinite scroll, etc. But I digress.. OK, so this is turning out to be a bigger endeavor than simply adding previous/next buttons. If there's a high priority need for these, what we could do is to extend the current implementation to add these for now, while the new paginator is being developed. |
Beta Was this translation helpful? Give feedback.
-
Yeah, having our single-format pagination buttons just include first/previous/next/last buttons by default might be the easiest short-term solution. Devs could easily hide the buttons they don't want.
If we want to get really primitive, a sequence of pagination buttons is not that different in terms of interface from a button group control. If our long-term dream is to extend these controls beyond just the page builder, then the big-picture approach to pagination might take some inspiration from that control syntax, or at least consider how to integrate with it. |
Beta Was this translation helpful? Give feedback.
-
Sounds good, I'll try that as a short-term solution. I'm sure it will give me a better understanding of how to achieve the long-term goal, a much more flexible pagination as we're discussing. Good point, pagination is fundamentally a button group. A difficulty with the current implementation of Tangible Fields module is that all fields' scripts and styles are bundled together (~888K and ~44K respectively), which makes me hesitate to load on the frontend. On the other hand, generating a separate bundle for each field might be complicated to achieve. (There will likely be a shared "core" bundle, and field-specific bundles.) But I like the direction you're thinking. Sooner or later, we will probably bring the Fields module into the Template System. I'm thinking of how to do that without disturbing Nicolas and others who are working on it, and also if/how to preserve the Git history (not that important but would be nice). About the "primitives", and general-purpose dynamic behaviors, I've mentioned before there's some interesting and experimental work going on in WordPress core: Proposal: The Interactivity API – A better developer experience in building interactive blocks
From the code examples, it looks like we might be able to re-purpose it for L&L templates. The difficulty is that it's currently too much of a moving target, as they're still deciding on the public interface. Lots of related discussion happening in the Gutenberg repo: https://github.com/WordPress/gutenberg/discussions/categories/interactivity-api |
Beta Was this translation helpful? Give feedback.
-
|
Hi @eliot-akira, Julia just let me know that she put together some example styles and layouts for loop pagination that might inform the direction we take with the syntax. These fit the overall simple but modern interface aesthetic we seem to be going for across all our plugins at the moment. Notably, these designs include some additional pagination interfaces such as a (presumably editable) page number text box and a page number dropdown.
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks, I've added the screenshot to the overview for reference. |
Beta Was this translation helpful? Give feedback.
-
|
OK, finally, some progress on new pagination features. These are steps toward a more flexible Pager module (#21), which will gradually replace the current one ("Paginator v1"). For a while I had to spend time just reading over the existing implementation, figuring out how it works, thinking about the ideas we've brainstormed here, and considering how to approach it. What I've learned is that the current paginator uses a specific kind of algorithm, whose main advantage is that the number of pagination buttons stays the same no matter how many pages there are. It's good for what it does, but there are drawbacks: it's not easy to extend, and not suitable for creating variations from it like in the design prototypes above. We'll need to take apart some of what exists, so we can provide simpler building blocks ("build your own pagination"); and a way to re-render such user-written pagination templates during navigation. What I've added so far:
First I created 100 posts for testing. for ($i = 1; $i <= 100; $i++) {
wp_insert_post([
'post_title' => 'Test ' . $i,
'post_content' => 'Hello from post ' . $i,
'post_status' => 'publish',
]);
}It'd be nice if there was a way to do things like this using L&L templates. Next, the main loop to display paged items. <ul>
<Loop type=post paged=5 loop_id=1>
<li><Field title /></li>
</Loop>
</ul>The A disadvantage of having this wrapper element is that it doesn't work when used inside a Loop IDA new attribute The concept of Loop ID will likely be useful for purposes other than pagination. Pager fieldsA new tag <PagerFields loop_id=1>
Page <Field current_page /> of <Field total_pages />
</PagerFields>The The Pager buttonsThe <PagerButtons loop_id=1 />For backward compatibility, it uses the current pagination style by default ("equal number of pager buttons"), but other types can be added in the future. To show how it works by default:
It's a bit unintuitive how the active page moves, particularly when it's in the center. Also, some pages are not easy to reach, for example, to go from page 1 to 15. (But the same is true for most other types of pagination.) First/last and previous/nextFor the <PagerButtons loop_id=1 first="«" prev="‹" next="›" last="»" />
<PagerButtons loop_id=1 first_last=true prev_next=true />
<PagerButtons loop_id=1 first=First last=Last prev=Previous next=Next />Here's how they look:
By default it uses angle brackets Currently this doesn't support replacing the button content with icons, for example, because passing HTML in a tag attribute is still an unsolved question. Technically it might be possible, like Future directionFor "build your own pagination", I'll be exploring what we can do with a new The most flexible solution will be to support user-written pagination templates, which subscribe to pager change events and re-render on the server side, at the same time as rendering the paginated loop. This will let users build variations, like deciding when to abbreviate the list |
Beta Was this translation helpful? Give feedback.
-
@eliot-akira Any chance we could get next and previous buttons for pagination? I'm unearthing some feature requests from 2022 since I need this for a project, and since it doesn't exist yet I'm going to have to find some weird workarounds:
Back then @BenTangible and I discussed our ideas for optimally flexible markup to support this sort of functionality, and I came up with the following:
See discussion here
Beta Was this translation helpful? Give feedback.
All reactions