Problem statement

Currently, [BlogIndexPage] and [LocationsIndexPage] load all of their child pages at once and pass them to the template without pagination. [BreadsIndexPage] does have pagination, but the logic is explicitly written out inside the models [get_context] and [paginate]methods.
As part of the Demo website redesign GSoC project goals, one of the requirements is to provide "Capabilities to test Wagtail with large amounts of content" (e.g., 50+ pages per section).
If we scale the demo to 50+ or 500+ blog posts or locations, the current index pages will suffer from performance issues and break the UI layout by loading everything on a single page.

Proposed solution

I propose implementing a DRY pagination architecture for the index pages:

1. Extract the existing pagination logic from [BreadsIndexPage] into a reusable [PaginatedIndexMixin]in [base/models.py].
2. Apply this [PaginatedIndexMixin]to [BreadsIndexPage], [BlogIndexPage]), and [LocationsIndexPage].
3. Update [blog_index_page.html] and [locations_index_page.html] to include the existing Wagtail [includes/pagination.html]snippet, making the frontend rendering consistent.
   This strictly follows DRY principles, removes duplicated code, and ensures the demo site can safely render large amounts of generated content without breaking.

Alternative solutions

No response

Additional context

I have already explored the codebase and have a working local implementation of this modular approach. If the maintainers agree this is a useful addition for the GSoC redesign goals, I would love to open a Pull Request with these changes!

Working on this

Contribute to the discussion to help this move forward. Explain your use cases, discuss possible solutions, research how to adapt existing code, or compatibility concerns.

Once others agree with the proposed changes, anyone can contribute to this. View our contributing guidelines. Add a comment to the issue to explain what approach you are taking.